Surgient Success

I have prepped a Windows 2003 clean image using the surgient prep tool (Surgient_Image_Tool.iso).

 This attaches the ISO and installs the various scripts and such. 

 When launched in an Application config, i get the following error which causes the deployment to deprovision.

There are actually 2 VM's,  

1.) Launch

2.) Launch2

 This error happens whenever any of the server config remote access has "Has Agent" enabled.

 Also something to note is, though we hard code the IP address into the VM, it always comes up at a 169(dhcp failure) IP.

We have set the IP during the server config to teh IP we want as well as boot up the VM and set the IP. 

 any help would be great!

thanks! 

Hi Darryl,

It sounds like the NIC that's configured in the image is of a different type (e.g. vmxnet/vlance/e1000) than what the server configuration is setup as. This would result in the image PnP detecting a new NIC, and unsuccessfully attempting to get DHCP address (the default IP config for new NICs). Double check the network adapter type in the server config, give it another try, and let us know how it goes.

Cheers,

Ezra 

Hi Darryl -

If the image is prepped, the Surgient agent should be installed, and by checking the "hasAgent" box, Surgient is expecting to communicate with the agent.  If you are having networking issues, such as it appears, then that would prevent this from happening and cause the agent. 

 If you have set the IP in the VM and the same IP in the server config, yet your image is booting with another IP, it sounds like another NIC is appearing.  Do you have a way to confirm that the NIC you are setting is the NIC that is being used (such as by the name of the NIC)?

Once this issue is fixed, you are likely to see happier results.

 Thanks,

 Jackie.

Ok, weird,  setting it to Vlance kept the IP's (kind of weird, i figured we were using vmxnet, though i was not the one who set most of this up).  Unfortunately this does not solve the Agent connection issue.

 I suspect i know why, and its something i doubt we are going to be able to change.

simply put, the deployed VM's will never have direct access to VCS, and by the sounds of the error, thats exactly what it seems like its trying to do.  I always thought that it would go through the NAIL server.  this may be the case, becuase the Nail servers are on a different VLAN then the VCS server, so theres a chance of firewall rules in place.

Is this how the Agent works?  bounces through the NAIL server, then to VCS? or does it try to go from the Agent directly to the VCS?

 thanks!

There must be a communication path between the VCS and the agents.  The agents provide the VCS with information about who they are and confirm that they are available for use.  You cannot use any connection mechanism other then console, without an agent, unfortunately, because the VCS needs to know the IP information that is sent back from the agent.

The agent will initiate communication with the VCS over port 80, but the VCS communicates back to the agent over 4277/4728.  Those are the only ports that need to be open between the two.

NAIL does handle the traffic from a NATing perspective, but NAIL generally sits on the same VLAN as the images.

Hrm,  when did 4728 get added to the list?

i was under the impression it was just 80 then 4277.   currently 4728 is not allowed through the firewall between vlans.

I apologize - it was a typo.  That should read 4277/4278.

Their VCS runs on VLAN 160.  Their VLAN pool range is 2000-2100 (or something like that).  Are they going to have to set rules on the physical switch to allow 2000-2100 access to VLAN 160 in order to have agent communication with the VCS? 

Guest agent communication requires TCP connectivity so traffic from the guest VM's public subnet and VLANs must be routed to the default network or the VLAN the VCS is on.

The deployed VM doesn't need direct access to the VCS; the NAIL server (which in your case is on 160 or 168, I forget which) has a route to or is on the same network as the VCS. Assuming the server configs properly reflect the IP configuration of the images, the NAIL server will act as their default gateway, and forward traffic out to the default network connection. Your NAIL server can obviously talk to your VCS (it's pooled, and is accepting commands), so it sounds like you've got either a problem on the backend where some of your trunked traffic isn't being seen, or more likely, there's a problem w/ your server config's network adapter setup (e.g. wrong subnet). I'll follow up w/ someone on your project on our side tomorrow to see if they can help verify the config.