Surgient Success

One way I have done this in the past is to attach a blank floppy image, write to that, then move it to a machine with connectivity.

For larger amounts of data, you can attach another virtual hard drive, write what you need and then move that file to a staging (out side Surgient) machine with connectivity.

Matt, from what you have described I think that you are encountering the Surgient NAIL driver blocking your traffic in and out of the VM once you have changed the IP address. Once you have changed the IP address to your local network for the VM you will want to also make sure that you do not have Surgient NAIL checked in the Connection Properties dialogue under "This connection uses the following items:"

Thanks Guys.<br>I will be try this again in the next day or two.  I will try to change the IP and remember to uncheck the NAIL option in the TCP/IP settings.  However, at times, when I change an IP address on a VM it asks me for a reboot.  I will try this and ignore the reboot to see if that works.

Thanks

-Matt

Normally Windows does not prompt you to reboot simply on an IP address change.  To prevent being prompted you may want to temporarily disable the Local Area Connection before changing the properties of TCP/IP.  You can right-click on Local Area Connection in the Control Panel > Network Connections, click on Local Area Connection and choose disable.

Like Scott says above, in order to use a static IP addressing on your LAN without NAT, you'll want to uncheck the binding for Surgient NAIL.  Upon changing the IP address, reenable Local Area Connection.  You can then try to ping the TCP/IP gateway to ensure connectivity.  If you don't have any extra addresses than those you have pooled for Surgient, you can "borrow" a pooled IP address by making an exception entry in the pool resources that the host belongs to.

When you were being asked to reboot, how were you doing that?  Allowing WIndows to reboot from inside the VM or using the Surgient Management Console?

Thank you. I will try to disable the NIC prior to making the IP address changes as well as uncheck NAIL in the TCP/IP properties. 

<bR>While we have a deployed VM, we have to choose "no" to the reboot request since the reboot would cause our changes to be lost.  I will try your suggestions either later today or tomorrow.  The main purpose for us to transfer data from a deployed VM back to produciton is to capture logs for troubleshooting.  I think this will help

Thank you

-Matt

We installed Vitual server SP1 and can not attached the virtual hard drives from the virtual servers to the physical VM host and capture data that way.  Thank you all for your help

-Matt

If you're trying to mount the virtual hard disk on the host, try looking at Vhdmount in C:\Program Files\Microsoft Virtual Server\Vhdmount.  This is a tool in Virtual Server 2005 R2 SP1 that lets you map any Microsoft .vhd file on the host to a drive letter.  Or a simpler GUI tool is a third-party tool named WinImage

Matt I mentioned this during my trip but here are the details on getting data live out of a VM:

Copying Files out of a live running VM
First thing you would do is bundle up everything you want to transfer out of the VM into one zip file, e.g. export.zip.  Next using the Microsoft Virtual Server Web Admin, find the VM in your deployment. In the VM's property menu click on Edit Configuration > COM Ports.   Attach COM1 to a "text file" named c:\export.zip.  (Virtual Server will force a .txt extension on this file so the name on the host will be export.zip.txt).  Go back into the VM and locate the ZIP file you want to export.  Using a command window (Start > Run > cmd), in the same directory as the zip, type "copy /B export.zip com1:". Now on the host in C:\, you will have a file named export.zip.txt of the same size. 

Important: make a copy of export.txt.zip and rename it to "export.zip". 

Back in the in the Virtual Server Web Admin "reset" the COM1 port setting to "None."  You should now be able to open your copy of export.zip on the Host with files that came out of the VM.  It is important to toggle the setting between the COM port mapped to a filename and back to None, because this resets the com port, i.e. rewrites the file.  A virtual com port is an "append" device such that if you issue more than one copy from the VM this will corrupt the binary ZIP format.  You can repeat these steps for each VM you want to export, so this is managable if you target just a few VMs.

Thank you,  We will be using Windows Virtual Server R2 Sp1