You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@vcl.apache.org by "Hartl, Gerhard L." <GH...@odu.edu> on 2010/04/29 17:34:44 UTC

route delete 0.0.0.0 breaks networking on VM

Hey everyone,

I'm running into an issue regarding loading a base WinXP image to a vm.  When I try to reload a VM with a base image, the process always stops at the "route delete 0.0.0.0".  When I look at the VM that it is configuring, the private and public interfaces lose their default gateway and are not able to communicate with the VCL management server.  After searching through the list I found a troubleshooting step of running the command from the management server with verbose and serveraliveinterval enabled.  The following are the results.  (Below the results are the snippet of the vcld.log where route delete is run)


/------------------------------------      route delete run manually from management server (start) ----------------------------------------------/
[root@kelly etc]# ssh -v -o ServerAliveInterval=15 -i /etc/vcl/vcl.key -l root -p 22 -x vcl1 'route delete 0.0.0.0'
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for vcl*
debug1: Applying options for *
debug1: Connecting to vcl1 [192.168.130.16] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /etc/vcl/vcl.key type 1
debug1: identity file /etc/vcl/vcl.key type 1
debug1: identity file 192.168.129.24 type -1
debug1: loaded 3 keys
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1
debug1: match: OpenSSH_5.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
Warning: Permanently added 'vcl1,192.168.130.16' (RSA) to the list of known hosts.
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /etc/vcl/vcl.key
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending command: route delete 0.0.0.0
Disconnecting: Timeout, server not responding.

/------------------------------------      route delete run manually from management server (end) ----------------------------------------------/





/------------------------------------      vcld.log snippet (start) ----------------------------------------------/
2010-04-27 10:44:02|2418|90:164|reload|Windows.pm:get_network_configuration(4713)|returning data for public interface: Local Area Connection 2 (128.82.130.16)
2010-04-27 10:44:02|2418|90:164|reload|Windows.pm:get_public_default_gateway(4895)|returning default gateway currently in use on vcl1: 128.82.130.1
2010-04-27 10:44:02|2418|90:164|reload|utils.pm:run_ssh_command(5820)|executing SSH command on vcl1:
|2418|90:164|reload| /usr/bin/ssh -i /etc/vcl/vcl.key  -l root -p 22 -x vcl1 'route delete 0.0.0.0' 2>&1
2010-04-27 10:44:09|546|vcld:main(164)|lastcheckin time updated for management node 1: 2010-04-27 10:44:09
/------------------------------------      vcld.log snippet (end) ----------------------------------------------/

Gerhard Hartl
Office of Computing and Communications Services
Old Dominion University | ODU


Re: Privileges page not responsive

Posted by Josh Thompson <jo...@ncsu.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gerhard,

It took me a while to remember the workaround on this one.  There was a bug in 
Dojo that caused this issue.  It's been fixed in more recent versions of Dojo, 
which will be supported in VCL 2.2.

Until VCL 2.2 is released, you can either just use Firefox, or perform this 
workaround.

- -go to the Privileges page
- -click one of the Add buttons that pops up a window that doesn't correctly 
show the buttons
- -move the window enough to see the tree at the top
- -click on a different node
- -the buttons should now be visible, and you can click back on the original 
node to add something there

Josh

On Friday May 07, 2010, Hartl, Gerhard L. wrote:
> I just went ahead and reloaded the portal and yes you are correct, I used
>  the svn before.  I am experiencing a lot less issues now however I still
>  notice an issue on the priv page when you click add group, add resource
>  group, or add user, the button for submit (ie submit new user) and cancel
>  do not show up in IE 7.  It seems to be showing up fine in Firefox 3.6.  I
>  am using dojo 1.1.0 and dojoAjax 0.4.0 as stipulated in the vcl frontend
>  instructions.
> 
> Attached: screenshot
> 
> - Gerhard
> 757.683.6980 | ghartl@odu.edu | occs.odu.edu
> 
> -----Original Message-----
> From: Josh Thompson [mailto:josh_thompson@ncsu.edu]
> Sent: Friday, May 07, 2010 3:36 PM
> To: vcl-dev@incubator.apache.org
> Subject: Re: Privileges page not responsive
> 
> Gerhard,
> 
> It sounds like you are using the code from subversion instead of VCL 2.1.
> That may be somewhat buggy because it hasn't been well tested.
> 
> In what browsers are you seeing the problem?  What version of the Dojo
>  Toolkit did you install?
> 
> Josh
> 
> On Thursday May 06, 2010, Hartl, Gerhard L. wrote:
> > Hey everyone,
> >
> > I'm running into an issue with the priviledges page on my web front end. 
> > I can't for the life of me figure out what is not working properly.  When
> > I go to add a user or resource group, I get the window and I can make the
> > proper selections, but
> >
> > 1.      They don't make any actual changes to the database
> > 2.      I receive a message that:
> >
> > Line: 469
> > Char: 2
> > Error: 'lastFocused.item' is null or not an object
> > Code:0
> > URL:  https://andrews.vcls.priv.odu.edu/vcl/index.php?mode=viewNodes
> >
> > I have rebuilt the entire server and reinstalled all required php
> >  extensions, but get the same results.  Is there anywhere in particular I
> >  should be looking?
> >
> > - Gerhard
> > 757.683.6980 | ghartl@odu.edu<ma...@odu.edu> | occs.odu.edu
> 
- -- 
- -------------------------------
Josh Thompson
Systems Programmer
Advanced Computing | VCL Developer
North Carolina State University

Josh_Thompson@ncsu.edu
919-515-5323

my GPG/PGP key can be found at pgp.mit.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAkvodG0ACgkQV/LQcNdtPQOcwACZAW8e/AZDYYD7sPwD0eVMe/hS
wKwAn16vpCg6mUY/klF3eRT3MZx7MKVD
=2xEo
-----END PGP SIGNATURE-----

RE: Privileges page not responsive

Posted by "Hartl, Gerhard L." <GH...@odu.edu>.
I just went ahead and reloaded the portal and yes you are correct, I used the svn before.  I am experiencing a lot less issues now however I still notice an issue on the priv page when you click add group, add resource group, or add user, the button for submit (ie submit new user) and cancel do not show up in IE 7.  It seems to be showing up fine in Firefox 3.6.  I am using dojo 1.1.0 and dojoAjax 0.4.0 as stipulated in the vcl frontend instructions.  

Attached: screenshot

- Gerhard
757.683.6980 | ghartl@odu.edu | occs.odu.edu 

-----Original Message-----
From: Josh Thompson [mailto:josh_thompson@ncsu.edu] 
Sent: Friday, May 07, 2010 3:36 PM
To: vcl-dev@incubator.apache.org
Subject: Re: Privileges page not responsive

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gerhard,

It sounds like you are using the code from subversion instead of VCL 2.1.  
That may be somewhat buggy because it hasn't been well tested.

In what browsers are you seeing the problem?  What version of the Dojo Toolkit 
did you install?

Josh

On Thursday May 06, 2010, Hartl, Gerhard L. wrote:
> Hey everyone,
> 
> I'm running into an issue with the priviledges page on my web front end.  I
>  can't for the life of me figure out what is not working properly.  When I
>  go to add a user or resource group, I get the window and I can make the
>  proper selections, but
> 
> 1.      They don't make any actual changes to the database
> 2.      I receive a message that:
> 
> Line: 469
> Char: 2
> Error: 'lastFocused.item' is null or not an object
> Code:0
> URL:  https://andrews.vcls.priv.odu.edu/vcl/index.php?mode=viewNodes
> 
> I have rebuilt the entire server and reinstalled all required php
>  extensions, but get the same results.  Is there anywhere in particular I
>  should be looking?
> 
> - Gerhard
> 757.683.6980 | ghartl@odu.edu<ma...@odu.edu> | occs.odu.edu
> 
- -- 
- -------------------------------
Josh Thompson
Systems Programmer
Advanced Computing | VCL Developer
North Carolina State University

Josh_Thompson@ncsu.edu
919-515-5323

my GPG/PGP key can be found at pgp.mit.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAkvka4UACgkQV/LQcNdtPQOU3QCeMomenqEt+85fZEk3hFfbDD0D
zPIAn3uxILhlJdc5/nuS0HoKZn65zWS/
=egLs
-----END PGP SIGNATURE-----

Re: Privileges page not responsive

Posted by Josh Thompson <jo...@ncsu.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gerhard,

It sounds like you are using the code from subversion instead of VCL 2.1.  
That may be somewhat buggy because it hasn't been well tested.

In what browsers are you seeing the problem?  What version of the Dojo Toolkit 
did you install?

Josh

On Thursday May 06, 2010, Hartl, Gerhard L. wrote:
> Hey everyone,
> 
> I'm running into an issue with the priviledges page on my web front end.  I
>  can't for the life of me figure out what is not working properly.  When I
>  go to add a user or resource group, I get the window and I can make the
>  proper selections, but
> 
> 1.      They don't make any actual changes to the database
> 2.      I receive a message that:
> 
> Line: 469
> Char: 2
> Error: 'lastFocused.item' is null or not an object
> Code:0
> URL:  https://andrews.vcls.priv.odu.edu/vcl/index.php?mode=viewNodes
> 
> I have rebuilt the entire server and reinstalled all required php
>  extensions, but get the same results.  Is there anywhere in particular I
>  should be looking?
> 
> - Gerhard
> 757.683.6980 | ghartl@odu.edu<ma...@odu.edu> | occs.odu.edu
> 
- -- 
- -------------------------------
Josh Thompson
Systems Programmer
Advanced Computing | VCL Developer
North Carolina State University

Josh_Thompson@ncsu.edu
919-515-5323

my GPG/PGP key can be found at pgp.mit.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAkvka4UACgkQV/LQcNdtPQOU3QCeMomenqEt+85fZEk3hFfbDD0D
zPIAn3uxILhlJdc5/nuS0HoKZn65zWS/
=egLs
-----END PGP SIGNATURE-----

Privileges page not responsive

Posted by "Hartl, Gerhard L." <GH...@odu.edu>.
Hey everyone,

I'm running into an issue with the priviledges page on my web front end.  I can't for the life of me figure out what is not working properly.  When I go to add a user or resource group, I get the window and I can make the proper selections, but

1.      They don't make any actual changes to the database
2.      I receive a message that:

Line: 469
Char: 2
Error: 'lastFocused.item' is null or not an object
Code:0
URL:  https://andrews.vcls.priv.odu.edu/vcl/index.php?mode=viewNodes

I have rebuilt the entire server and reinstalled all required php extensions, but get the same results.  Is there anywhere in particular I should be looking?

- Gerhard
757.683.6980 | ghartl@odu.edu<ma...@odu.edu> | occs.odu.edu


Re: route delete 0.0.0.0 breaks networking on VM

Posted by Aaron Peeler <aa...@ncsu.edu>.
Yes, it is assumed the management node and the vms are on the same 
private network. Also we've noticed that in win2003,vista and win7 that 
two gateways are not allowed and overtime the gateway on the secondary 
nic gets dropped. Andy can confirm but I think in some cases the gateway 
on the private network does not get set for these OS's.

Aaron


On 4/29/10 2:57 PM, Hartl, Gerhard L. wrote:
> I just realized why this doesn't work.  My management server is on another subnet than the vm's.  When the route is deleted, the vm doesn't not know how to contact the server on the different subnet.  If they were on the same subnet, they would not need routing so they could still communicate.  Is having the management server and the vm's on the same subnet a necessity?
>
> - Gerhard
> 757.683.6980 | ghartl@odu.edu | occs.odu.edu
>
>
> -----Original Message-----
> From: Hartl, Gerhard L. [mailto:GHartl@odu.edu]
> Sent: Thursday, April 29, 2010 11:35 AM
> To: 'vcl-dev@incubator.apache.org'
> Subject: route delete 0.0.0.0 breaks networking on VM
>
> Hey everyone,
>
> I'm running into an issue regarding loading a base WinXP image to a vm.  When I try to reload a VM with a base image, the process always stops at the "route delete 0.0.0.0".  When I look at the VM that it is configuring, the private and public interfaces lose their default gateway and are not able to communicate with the VCL management server.  After searching through the list I found a troubleshooting step of running the command from the management server with verbose and serveraliveinterval enabled.  The following are the results.  (Below the results are the snippet of the vcld.log where route delete is run)
>
>
> /------------------------------------      route delete run manually from management server (start) ----------------------------------------------/
> [root@kelly etc]# ssh -v -o ServerAliveInterval=15 -i /etc/vcl/vcl.key -l root -p 22 -x vcl1 'route delete 0.0.0.0'
> OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: Applying options for vcl*
> debug1: Applying options for *
> debug1: Connecting to vcl1 [192.168.130.16] port 22.
> debug1: Connection established.
> debug1: permanently_set_uid: 0/0
> debug1: identity file /etc/vcl/vcl.key type 1
> debug1: identity file /etc/vcl/vcl.key type 1
> debug1: identity file 192.168.129.24 type -1
> debug1: loaded 3 keys
> debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1
> debug1: match: OpenSSH_5.1 pat OpenSSH*
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_4.3
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug1: kex: server->client aes128-cbc hmac-md5 none
> debug1: kex: client->server aes128-cbc hmac-md5 none
> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
> debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
> debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
> debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
> Warning: Permanently added 'vcl1,192.168.130.16' (RSA) to the list of known hosts.
> debug1: ssh_rsa_verify: signature correct
> debug1: SSH2_MSG_NEWKEYS sent
> debug1: expecting SSH2_MSG_NEWKEYS
> debug1: SSH2_MSG_NEWKEYS received
> debug1: SSH2_MSG_SERVICE_REQUEST sent
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug1: Authentications that can continue: publickey,keyboard-interactive
> debug1: Next authentication method: publickey
> debug1: Offering public key: /etc/vcl/vcl.key
> debug1: Server accepts key: pkalg ssh-rsa blen 149
> debug1: read PEM private key done: type RSA
> debug1: Authentication succeeded (publickey).
> debug1: channel 0: new [client-session]
> debug1: Entering interactive session.
> debug1: Sending environment.
> debug1: Sending env LANG = en_US.UTF-8
> debug1: Sending command: route delete 0.0.0.0
> Disconnecting: Timeout, server not responding.
>
> /------------------------------------      route delete run manually from management server (end) ----------------------------------------------/
>
>
>
>
>
> /------------------------------------      vcld.log snippet (start) ----------------------------------------------/
> 2010-04-27 10:44:02|2418|90:164|reload|Windows.pm:get_network_configuration(4713)|returning data for public interface: Local Area Connection 2 (128.82.130.16)
> 2010-04-27 10:44:02|2418|90:164|reload|Windows.pm:get_public_default_gateway(4895)|returning default gateway currently in use on vcl1: 128.82.130.1
> 2010-04-27 10:44:02|2418|90:164|reload|utils.pm:run_ssh_command(5820)|executing SSH command on vcl1:
> |2418|90:164|reload| /usr/bin/ssh -i /etc/vcl/vcl.key  -l root -p 22 -x vcl1 'route delete 0.0.0.0' 2>&1
> 2010-04-27 10:44:09|546|vcld:main(164)|lastcheckin time updated for management node 1: 2010-04-27 10:44:09
> /------------------------------------      vcld.log snippet (end) ----------------------------------------------/
>
> Gerhard Hartl
> Office of Computing and Communications Services
> Old Dominion University | ODU
>
>    


-- 

Aaron Peeler
Program Manager
Virtual Computing Lab
NC State University
aaron_peeler@ncsu.edu
919-513-4571


Re: route delete 0.0.0.0 breaks networking on VM

Posted by Josh Thompson <jo...@ncsu.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

You should be able to configure your dhcp server to give the VM a routing 
entry specifically for the network that your management node is on instead of 
using a default route entry to access it.  Then, your VMs would be able to 
access the management node that is on a different subnet and the route delete 
0.0.0.0 would not mess things up.

Josh

On Friday April 30, 2010, Aaron Peeler wrote:
> Yes, it is assumed the management node and the vms are on the same
> private network. Also we've noticed that in win2003,vista and win7 that
> two gateways are not allowed and overtime the gateway on the secondary
> nic gets dropped. Andy can confirm but I think in some cases the gateway
> on the private network does not get set for these OS's.
> 
> Aaron
> 
> On 4/29/10 2:57 PM, Hartl, Gerhard L. wrote:
> > I just realized why this doesn't work.  My management server is on
> > another subnet than the vm's.  When the route is deleted, the vm doesn't
> > not know how to contact the server on the different subnet.  If they were
> > on the same subnet, they would not need routing so they could still
> > communicate.  Is having the management server and the vm's on the same
> > subnet a necessity?
> >
> > - Gerhard
> > 757.683.6980 | ghartl@odu.edu | occs.odu.edu
> >
> >
> > -----Original Message-----
> > From: Hartl, Gerhard L. [mailto:GHartl@odu.edu]
> > Sent: Thursday, April 29, 2010 11:35 AM
> > To: 'vcl-dev@incubator.apache.org'
> > Subject: route delete 0.0.0.0 breaks networking on VM
> >
> > Hey everyone,
> >
> > I'm running into an issue regarding loading a base WinXP image to a vm. 
> > When I try to reload a VM with a base image, the process always stops at
> > the "route delete 0.0.0.0".  When I look at the VM that it is
> > configuring, the private and public interfaces lose their default gateway
> > and are not able to communicate with the VCL management server.  After
> > searching through the list I found a troubleshooting step of running the
> > command from the management server with verbose and serveraliveinterval
> > enabled.  The following are the results.  (Below the results are the
> > snippet of the vcld.log where route delete is run)
> >
> >
> > /------------------------------------      route delete run manually from
> > management server (start) ----------------------------------------------/
> > [root@kelly etc]# ssh -v -o ServerAliveInterval=15 -i /etc/vcl/vcl.key -l
> > root -p 22 -x vcl1 'route delete 0.0.0.0' OpenSSH_4.3p2, OpenSSL
> > 0.9.8e-fips-rhel5 01 Jul 2008
> > debug1: Reading configuration data /etc/ssh/ssh_config
> > debug1: Applying options for vcl*
> > debug1: Applying options for *
> > debug1: Connecting to vcl1 [192.168.130.16] port 22.
> > debug1: Connection established.
> > debug1: permanently_set_uid: 0/0
> > debug1: identity file /etc/vcl/vcl.key type 1
> > debug1: identity file /etc/vcl/vcl.key type 1
> > debug1: identity file 192.168.129.24 type -1
> > debug1: loaded 3 keys
> > debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1
> > debug1: match: OpenSSH_5.1 pat OpenSSH*
> > debug1: Enabling compatibility mode for protocol 2.0
> > debug1: Local version string SSH-2.0-OpenSSH_4.3
> > debug1: SSH2_MSG_KEXINIT sent
> > debug1: SSH2_MSG_KEXINIT received
> > debug1: kex: server->client aes128-cbc hmac-md5 none
> > debug1: kex: client->server aes128-cbc hmac-md5 none
> > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
> > debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
> > debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
> > debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
> > Warning: Permanently added 'vcl1,192.168.130.16' (RSA) to the list of
> > known hosts. debug1: ssh_rsa_verify: signature correct
> > debug1: SSH2_MSG_NEWKEYS sent
> > debug1: expecting SSH2_MSG_NEWKEYS
> > debug1: SSH2_MSG_NEWKEYS received
> > debug1: SSH2_MSG_SERVICE_REQUEST sent
> > debug1: SSH2_MSG_SERVICE_ACCEPT received
> > debug1: Authentications that can continue: publickey,keyboard-interactive
> > debug1: Next authentication method: publickey
> > debug1: Offering public key: /etc/vcl/vcl.key
> > debug1: Server accepts key: pkalg ssh-rsa blen 149
> > debug1: read PEM private key done: type RSA
> > debug1: Authentication succeeded (publickey).
> > debug1: channel 0: new [client-session]
> > debug1: Entering interactive session.
> > debug1: Sending environment.
> > debug1: Sending env LANG = en_US.UTF-8
> > debug1: Sending command: route delete 0.0.0.0
> > Disconnecting: Timeout, server not responding.
> >
> > /------------------------------------      route delete run manually from
> > management server (end) ----------------------------------------------/
> >
> >
> >
> >
> >
> > /------------------------------------      vcld.log snippet (start)
> > ----------------------------------------------/ 2010-04-27
> > 10:44:02|2418|90:164|reload|Windows.pm:get_network_configuration(4713)|re
> >turning data for public interface: Local Area Connection 2 (128.82.130.16)
> > 2010-04-27
> > 10:44:02|2418|90:164|reload|Windows.pm:get_public_default_gateway(4895)|r
> >eturning default gateway currently in use on vcl1: 128.82.130.1
> >
> > 2010-04-27 10:44:02|2418|90:164|reload|utils.pm:run_ssh_command(5820)|
executing SSH command on vcl1:
> > |2418|90:164|reload| /usr/bin/ssh -i /etc/vcl/vcl.key  -l root -p 22 -x
> > | vcl1 'route delete 0.0.0.0' 2>&1
> >
> > 2010-04-27 10:44:09|546|vcld:main(164)|lastcheckin time updated for
> > management node 1: 2010-04-27 10:44:09
> > /------------------------------------      vcld.log snippet (end)
> > ----------------------------------------------/
> >
> > Gerhard Hartl
> > Office of Computing and Communications Services
> > Old Dominion University | ODU
> 
- -- 
- -------------------------------
Josh Thompson
Systems Programmer
Advanced Computing | VCL Developer
North Carolina State University

Josh_Thompson@ncsu.edu
919-515-5323

my GPG/PGP key can be found at pgp.mit.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAkva5aIACgkQV/LQcNdtPQNsFwCdENJFdP8jEXC9L7cUGEChNiPV
maYAn2Y/wPK+bCV50N0kOV1BXOuWxmBT
=wps1
-----END PGP SIGNATURE-----

RE: route delete 0.0.0.0 breaks networking on VM

Posted by "Hartl, Gerhard L." <GH...@odu.edu>.
I just realized why this doesn't work.  My management server is on another subnet than the vm's.  When the route is deleted, the vm doesn't not know how to contact the server on the different subnet.  If they were on the same subnet, they would not need routing so they could still communicate.  Is having the management server and the vm's on the same subnet a necessity?

- Gerhard
757.683.6980 | ghartl@odu.edu | occs.odu.edu 


-----Original Message-----
From: Hartl, Gerhard L. [mailto:GHartl@odu.edu] 
Sent: Thursday, April 29, 2010 11:35 AM
To: 'vcl-dev@incubator.apache.org'
Subject: route delete 0.0.0.0 breaks networking on VM

Hey everyone,

I'm running into an issue regarding loading a base WinXP image to a vm.  When I try to reload a VM with a base image, the process always stops at the "route delete 0.0.0.0".  When I look at the VM that it is configuring, the private and public interfaces lose their default gateway and are not able to communicate with the VCL management server.  After searching through the list I found a troubleshooting step of running the command from the management server with verbose and serveraliveinterval enabled.  The following are the results.  (Below the results are the snippet of the vcld.log where route delete is run)


/------------------------------------      route delete run manually from management server (start) ----------------------------------------------/
[root@kelly etc]# ssh -v -o ServerAliveInterval=15 -i /etc/vcl/vcl.key -l root -p 22 -x vcl1 'route delete 0.0.0.0'
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for vcl*
debug1: Applying options for *
debug1: Connecting to vcl1 [192.168.130.16] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /etc/vcl/vcl.key type 1
debug1: identity file /etc/vcl/vcl.key type 1
debug1: identity file 192.168.129.24 type -1
debug1: loaded 3 keys
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1
debug1: match: OpenSSH_5.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
Warning: Permanently added 'vcl1,192.168.130.16' (RSA) to the list of known hosts.
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /etc/vcl/vcl.key
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending command: route delete 0.0.0.0
Disconnecting: Timeout, server not responding.

/------------------------------------      route delete run manually from management server (end) ----------------------------------------------/





/------------------------------------      vcld.log snippet (start) ----------------------------------------------/
2010-04-27 10:44:02|2418|90:164|reload|Windows.pm:get_network_configuration(4713)|returning data for public interface: Local Area Connection 2 (128.82.130.16)
2010-04-27 10:44:02|2418|90:164|reload|Windows.pm:get_public_default_gateway(4895)|returning default gateway currently in use on vcl1: 128.82.130.1
2010-04-27 10:44:02|2418|90:164|reload|utils.pm:run_ssh_command(5820)|executing SSH command on vcl1:
|2418|90:164|reload| /usr/bin/ssh -i /etc/vcl/vcl.key  -l root -p 22 -x vcl1 'route delete 0.0.0.0' 2>&1
2010-04-27 10:44:09|546|vcld:main(164)|lastcheckin time updated for management node 1: 2010-04-27 10:44:09
/------------------------------------      vcld.log snippet (end) ----------------------------------------------/

Gerhard Hartl
Office of Computing and Communications Services
Old Dominion University | ODU