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 just read 4277.

 (Correction: Removed port 4278.  That port is not used from 5.0 onward.)

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.

Hi All,

I am finding exactly the same problem in our setup. What are the latest updates on this issue? I tried with a single NIC and with all nic types (vmxnet, vlance, e1000) etc.

After deployment it waits for 600 secs and then throws the same error message as above and starts deprovisioning. After system came up,  network configuration which had worked earlier,  was lost. 

Any inputs?

Anil

 Anil,

The guest agent failing to check in generally indicates the need to modify the networking within the image, but can also be caused if the Surgient agent is not successfully starting within the vm.  A good basic first pass to troubleshoot would be:

1. Modify the server config so that 'Has Agent' is off.  This will Disable RDP, but allow us to console in and check the image without it automatically tearing down.

2. Deploy the image and connect to the vm using ESX console

3. Once connnected, check to make sure that the Surgient agent service starts automatically

4. If that service is started, open a web browser in the image to the url http://<VCSipAddress>/ingress/Mailbox.aspx and see if an xml page returns

If the service is not started, there are some log files we can look at to determine the source.  If the agent does start, but the web page does not display, there is probably some networking changes we can make within the image to resolve it.

ps - might want to launch a new thread on this as the original is a bit old and might not apply at this point. 

Hi Kevin,

I was able to do it. Thanks. I got my first deployment with network and agent connectivity and first deployment I could see on the VQMS screen.

The reason as you said was the agent not getting started. The reason for that was mount of the agent iso did not happen. The reason for that was the NIC did not connect while booting up. I ensured to check the connect check boxes. But some how it did not connect.

Thanks for the help.

Anil