Windows Virtual PC

Windows Virtual PC and Windows XP Mode no longer require HAV processors

vinodata — Fri, 19 Mar 2010 12:17:07 GMT

The Virtual PC team is thrilled to announce the availability of KB977206 which allows our customers to use Windows Virtual PC and Windows XP Mode on non-HAV (Hardware-Assisted Virtualization) machines. Windows XP Mode continues to use hardware virtualization such as Intel Virtualization Technology (Intel® VT) or the AMD-V™ chipset when available but it no longer requires them. A number of our customers and partners have been asking us to support a wider range of PC’s including those without HAV capability and we have delivered this software patch to address their needs. We believe that this change simplifies the customer experience and makes this benefit accessible to many more PCs.

Download the software update for 32-bit host operating systems from here and for 64-bit host operating systems from here.

The KB article describes the various scenarios under which the software update must be installed. Ensure that Windows Virtual PC is installed before applying this fix.

Some FAQ’s around this update:

Q: How do I check the HAV capability of my machine?

A: Download and run the Microsoft Hardware-Assisted Virtualization Detection Tool. Go through the user guide for detailed description of the result.

Q: I have a machine with a HAV enabled processor, which has Windows Virtual PC and Windows XP Mode running. Do I need to apply this fix?

A: Short Answer – No

Long Answer – The fix is primarily targeted for non-HAV machines. If you have a functioning setup, then you can opt to not apply this fix. However please note that this update contains the fix for the power state issue seen (with Windows Virtual PC installed) on Intel® Clarkdale/Arrandale processor (http://support.microsoft.com/kb/977632) and it is recommended that you apply this update on that specific hardware. If you are an IT Administrator with a heterogeneous mixture of machines (HAV plus non-HAV machines), you can deploy this fix on all the machines. The user experience and performance on a HAV enabled machine before and after applying this fix will continue to be the same.

Q: I have a machine with a HAV capable processor (i.e the HAV setting is not enabled in the BIOS yet). Do I need to apply this fix?

A: For Windows XP Mode (or any Windows XP SP3 guest OS) users, we expect the performance to be comparable on HAV and non-HAV processors, however if you are planning to use any other guest OS we recommend that you enable the HAV setting in the BIOS rather than applying the patch.

Q: I have a non-HAV box and I wish to use a Windows Vista/Windows 7 VM using Windows Virtual PC. Is it possible?

A: This fix is primarily targeted towards users who need to run their productivity applications in Windows XP Mode (or any Windows XP SP3 virtual machine) on non-HAV machines. Hence you would need a HAV capable processor if you need to run a Windows Vista or Windows 7 virtual machine on Windows Virtual PC with acceptable performance.

Praveen Vijayaraghavan

Program Manager, Microsoft Virtualization Team

Folder Sharing between Windows 7 and VM

TechNet Archive — Tue, 22 Dec 2009 04:39:07 GMT

Virtual PC 2007® SP1 allowed users to share a particular folder with the Virtual Machine (VM). In Windows® Virtual PC, users can enable sharing at drive level only.

Sharing a Folder on Windows 7 Desktop with a VM

To share a particular folder with the VM, follow steps as below

Shutdown or Hibernate the VM (assuming you have Integration features enabled)
Open command prompt on Windows7 host. Let’s say you want to share folder C:\MySharedFolder with the VM.
subst S: C:\MySharedFolder. This subst command will create a virtual drive “S:” which is mapped to C:\MySharedFolder. Make sure the drive letter is free for use.
Open settings for the VM and make sure “S:” is ticked in the drive selection as shown below:

Fig. 1. Sharing a folder on Windows 7 host with a VM using the Setting User Interface

This is all you need to do to share a particular folder between host and VM. To remove the virtual drive use subst S: /d command.

Sending a File from a VM to a Windows 7 Folder

Let’s add little more fun by making it easier to send files to Windows7 host from a VM.

Open Windows Explorer in the VM
For XP VM open folder %userprofile%\SendTo. For a Vista or Windows7 VM, in the Explorer bar type shell:SendTo
In this folder create a shortcut “Windows7 Host,” pointing to “S:” drive as shown below:

Fig. 2. Creating a shortcut to send files from a VM to the Windows 7 host

It is that simple and now by using right click menu for any file or folder you can use “Send To” menu to easily copy files to the Windows 7 desktop (Figure 3).

Fig. 3. Using the right click menu to select the ‘Send To’ folder receiving the copied file from the VM

Technorati Tags: Windows Virtual PC,Windows XP Mode,Tips n Tricks

Vinod Atal

SDE

Microsoft Virtualization Team

USB Architecture in Windows Virtual PC

TechNet Archive — Mon, 14 Dec 2009 07:36:36 GMT

Some old legacy devices may not have driver support for newer operating systems (Windows® Vista and beyond). Windows® Virtual PC (WVPC) makes it possible to use these devices in Windows® 7, using Windows® XP Mode. Users can, at the same time, utilize the benefits of newer and secure features of Windows® 7. In this article, we will describe the USB architecture in WVPC. Typical USB devices used in a Virtual Machine (VM) are:

Printers
Flash memory sticks
External hard disks
Webcams and Digital cameras
Smartcards

Figure 1a: USB Menu on a Virtual Machine’s Tool Bar

Figure 1b: Manage USB Devices for Virtual Applications

Details on using these devices with the VM can be found in an earlier post.

WVPC uses the Redirection Policy Manager (RPM) of the Windows to provide the USB redirection in a Virtual Machine. It loads an alternate driver in the lieu of the original driver to redirect the device to a Virtual machine. WVPC creates a virtualized host controller in the Virtual Machine that is being offered using a VPCBus Channel. For more details, please refer to earlier post.

USB Architecture

The overall USB architecture is shown in Figure 2.

Figure 2: USB Architecture showing a USB Device in VM

USB architecture consists of a server side component running in Host OS and a client side component running in Virtual Machine. The server side involves a Connector driver to manage USB devices and a Stub instance for every USB Device. The client side implements a VPCBus enumerated virtual host controller that supports the subset of the USB driver interfaces that are necessary for compatibility with the supported devices. The redirection process also triggers the connector driver to send commands to the guest to create the PDO for the redirected device. After this the Stub driver, Connector driver and the Virtual bus/hub driver work in unison to enable communication of commands, responses and data between physical USB device and the redirected USB device. Component details are described below:

Server Side (Host OS)

A channel is created by Virtual PC host process (VPC.exe) through the Connector Driver using VPCBus whenever a VM boots up. Also, a server side hub instance is created internally by the Connector with this channel for every VM. There are two drivers on the server side as below:

The Connector driver provides services regardless of the devices that are currently connected.
The USB Stub driver is the alternate driver loaded by the USB stack instead of the vendor supplied or system supplied driver for the device using RPM. Please refer Figure 2. The Stub driver just forwards requests from the Connector driver to the PDO created by the hub driver.

A total of up to 8 USB devices can be assigned to a VM at a time. HID and Hub Class Devices cannot be assigned to the VM. The USB devices in VM can be safely removed just like in Host OS whenever the USB device driver supports.

Client Side (Virtual Machine)

The virtual host controller is a VPCBus enumerated bus driver (USB Virtualization Bus Driver) that takes the place of normal host controller driver. It is exposed to the system as two devices – a host controller and a root-hub device.

The virtual hub (USB Virtualization Hub Driver) creates the PDOs that mirror virtualized devices in the parent partition. The PNP manager loads the Client USB device drivers (or stacks of drivers) for the device. The virtual hub driver handles the IOCTLs either locally or sends the same to the USB device using Connector Driver. Please refer Figure 3 showing the Device Manager of Guest and Host.

Figure 3: A USB Device assigned to a Virtual Machine

Power State Changes of Host and Virtual Machine

USB Device assigned to a Virtual Machine reacts to the power state changes of the host OS as well as Virtual Machine. The changes are described below:

Virtual Machine Power State Changes

A USB device gets automatically assigned to host OS whenever a Virtual machine is shutdown, restarted, turned off or saved. The device remains within the VM whenever a VM is put to ‘Sleep’ state.

Host Power State Changes

USB Device gets assigned to host OS on host restart/shutdown/logoff. It remains within the VM on host sleep/hibernate.

Device Sharing vs. USB Device Redirection

Devices like printers, smart cards and USB external/flash drives are shared with Virtual Machine in Integration Features Enabled mode by the (Remote Desktop Protocol) RDP. These devices can be used with host OS as well as the Virtual Machine(s) at the same time. More details about this can be found in an earlier post.

Assigning a USB Device to a VM removes the device from host OS. It is only visible to the Virtual machine it is attached to and an application running on the host OS cannot access the device.

Prevent Device Redirection using Group Policy

Group policy can be used to prevent the redirection of selected USB devices to a Virtual Machine, for security or compliance reasons for example. This can be done at per device/device-class level. Also, all USB devices can be prevented to be used inside a VM. These settings are helpful in an organization where users are not allowed to use these devices in the physical machine as well.

These Group policy settings can be found under Computer Configuration -> Administrative Templates -> System->Device Redirection -> Device Redirection Restrictions as shown below (Figure 4).

Figure 4: Group Policy Settings for USB Device restrictions

There are two group policy settings for the Device Redirection Restrictions as described below:

Preventing redirection of devices that match any of these Device IDs

Enabling this policy setting will prevent the redirection of specific USB devices on a machine that matches the criteria specified in the Value field. For example, to block all USB Audio class devices (USB Class Code 01) for the redirection, the policy needs to be configured with Class_01 as shown below (Figure 5).

Figure 5: Group Policy setting for redirection of specific USB devices restrictions

Preventing redirection of USB devices

Enabling this policy setting will prevent the redirection of all USB devices on a machine.

More details about these policy settings can be found on MSDN here.

Implementation and Code examples

WVPC provides COM support to manage USB devices. The APIs are documented on MSDN at http://msdn.microsoft.com/en-us/library/dd796758(VS.85).aspx. Let’s take a look few scenarios for using these APIs to manage USB devices. A user wants to assign a USB Device whenever a VM is started. Another scenario is that an IT admin wants to restrict the USB Device Redirection feature due to some piracy/security concerns. In these scenarios, a developer can write scripts in VB/powershell or a code in any COM capable language to achieve this. Some samples are provided below:

Assign a USB Device

A developer can use AttachUSBDevice method of IVMVirtualMachine interface to assign a USB device to the VM. A sample C++ code is shown below:

        1: // Steps to Assign a Device

       2: // Step 1: Get the Virtual PC object

       3: // Step 2: Get the Virtual Machine Object

       4: // Step 3: Start the Virtual Machine if it's not running

       5: // Step 3: Get the USB Device Collection

       6: // Step 4: Get the USB Device Object to be assigned based on Device String

       7: // Step 5: Assign the Device

       8:  

       9:  

#define CHECK_NULL_RELEASE(obj) if(obj) \

                    {\

                    obj->Release();\

                    obj = NULL;\

                    }

  

int __cdecl main(int , char* )

{

    IVMVirtualMachine*      pVM                     = NULL;

    IVMVirtualPC*           pIVPC                   = NULL;

    HRESULT                 hr                      = S_OK;

    BSTR                    bName                   = NULL;

    VMVMState               vmState                 = vmVMState_Invalid;

    IVMTask*                pIVMTask                = NULL;

    IVMUSBDeviceCollection* pUSBDeviceCollection    = NULL;

    long                    usbDeviceCount          = 0;

    IVMUSBDevice*           pUsbDevice              = NULL;

    long                    index                   = 0;

    BSTR                    bDeviceString           = NULL;

    bool                    bDeviceFound            = FALSE;

  

    // Change the VM name as needed 

    LPWSTR                  lVMNameToBeAssigned     = L"Windows XP Mode";

  

    // Change the Device String as needed 

    LPWSTR                  lUsbDeviceString        = L"Cruzer Micro"; //L"Mass Storage Device";

  

    // Initialize VPC COM interfaces.

    hr = InitVPCComInterfaces(&pIVPC);

    if (hr != S_OK)

    {

        goto Cleanup;

    }

  

    // Allocate the Memory for the Virtual Machine Name

    // on which Device needs to be assigned.

    bName = SysAllocString(lVMNameToBeAssigned);

    if (bName == NULL) // Unable to allocate the Memory for VM Name String

    {

        hr = HRESULT_FROM_WIN32(ERROR_OUTOFMEMORY);

        goto Cleanup;

    }

  

    // Get the Virtual Machine object of the provided VMNAME

    hr = pIVPC->FindVirtualMachine(bName, &pVM);

    if (hr != S_OK)

    {

        goto Cleanup;

    }

  

    // Start the Virtual Machine if it's not running

    hr = pVM->get_State(&vmState);

    if (hr != S_OK)

    {

        goto Cleanup;

    }

  

    if(vmState == vmVMState_Running)

    {

        // VM is already Running

    }

    else

    {

        hr = pVM->Startup(&pIVMTask);

        if (hr !=S_OK)

        {

            goto Cleanup;

        }

  

        // Wait till the VM boots up

        hr = pIVMTask->WaitForCompletion(-1);

        if (hr != S_OK)

        {

            goto Cleanup;

        }        

    }

  

    // Get the USB Device Collection

    hr = pIVPC->get_USBDeviceCollection(&pUSBDeviceCollection);

    if (hr != S_OK)

    {

        goto Cleanup;

    }

  

    // Get the USB Device Collection Count

    hr = pUSBDeviceCollection->get_Count(&usbDeviceCount);

    if (hr != S_OK)

    {

        goto Cleanup;

    }

  

    if (usbDeviceCount == 0)

        goto Cleanup;

  

    // Iterate through the USB Device Collection for the Device to be Assigned

    for ( index = 1; index <= usbDeviceCount; index++)

    {

        hr = pUSBDeviceCollection->get_Item(index, &pUsbDevice);

        if (hr != S_OK)

            goto Cleanup;

                

        // Get the Device Name or Manufacturer String 

        hr = pUsbDevice->get_DeviceString(&bDeviceString); 

        if (hr != S_OK)

            goto Cleanup;

  

        // Check the Device String for the Match

        if (_wcsicmp(bDeviceString, lUsbDeviceString) == 0 )

        {

            // Device is Found

            bDeviceFound = TRUE;

            break;

        }

    }

  

    if (bDeviceFound == TRUE)

    {

        // Device was found above.

        // Assign the Device to the VM

        hr = pVM->AttachUSBDevice(pUsbDevice);

        if (hr != S_OK)

            goto Cleanup;

    }

  

Cleanup:

    CHECK_NULL_RELEASE(pIVPC);

    CHECK_NULL_RELEASE(pVM);

    CHECK_NULL_RELEASE(pUSBDeviceCollection); 

    CHECK_NULL_RELEASE(pUsbDevice); 

    CHECK_NULL_RELEASE(pIVMTask);

    SysFreeString(bName);

    SysFreeString(bDeviceString);

  

    return 0;

}

  

HRESULT 

InitVPCComInterfaces(

            __inout IVMVirtualPC** ppIVPC

    )

{

    HRESULT     hr      = S_OK;

    BSTR        bVer    = NULL;

    

    // Initialize COM

  

    hr = CoInitializeEx(NULL, COINIT_APARTMENTTHREADED);

    if (hr !=  S_OK) 

        return hr;

  

    REFCLSID classID = _uuidof(VMVirtualPC);

  

    // Get the VPC object

    hr = CoCreateInstance(classID, 

                          NULL, 

                          CLSCTX_ALL, 

                          IID_IVMVirtualPC, 

                          (LPVOID*)ppIVPC);

  

    if (SUCCEEDED(hr) && (*ppIVPC != NULL))

    {       

        // Make a call to the VPC interface and see if it works.

        hr = (*ppIVPC)->get_Version(&bVer);

    }

  

    SysFreeString(bVer);

    return hr;

}

Release a USB Device

Similarly, a developer can use DetachUSBDevice method of IVMVirtualMachine interface to release a USB device from the VM. A sample C++ code is shown below:

       1: // Steps to Release a Device

       2: // Step 1: Get the Virtual PC object

       3: // Step 2: Get the Virtual Machine Object

       4: // Step 3: Get the USB Device Collection

       5: // Step 4: Get the USB Device Object to be assigned based on Device String

       6: // Step 5: Verify the Device is attached to the VM

       7: // Step 6: Release the USB Device

       8:  

       9: #define SAFE_RELEASE(obj) if(obj) \

                    {\

                    obj->Release();\

                    obj = NULL;\

                    }

  

int __cdecl main(int , char* )

{

    IVMVirtualMachine*      pVM                     = NULL;

    IVMVirtualPC*           pIVPC                   = NULL;

    HRESULT                 hr                      = S_OK;

    BSTR                    bName                   = NULL;

    BSTR                    bVmNameAttachedTo       = NULL;

    VMVMState               vmState                 = vmVMState_Invalid;

    IVMUSBDeviceCollection* pUSBDeviceCollection    = NULL;

    long                    usbDeviceCount          = 0;

    IVMUSBDevice*           pUsbDevice              = NULL;

    long                    index                   = 0;

    BSTR                    bDeviceString           = NULL;

    bool                    bDeviceFound            = FALSE;

  

    // Change the VM name as needed 

    LPWSTR                  lVMNameToBeAssigned     = L"Windows XP Mode";

  

    // Change the Device String as needed 

    LPWSTR                  lUsbDeviceString        = L"Mass Storage Device";

  

    // Initialize VPC COM interfaces.

    hr = InitVPCComInterfaces(&pIVPC);

    if (hr != S_OK)

    {

        goto Cleanup;

    }

  

    // Allocate the Memory for the Virtual Machine Name

    // on which Device needs to be assigned.

    bName = SysAllocString(lVMNameToBeAssigned);

    if (bName == NULL) // Unable to allocate the Memory for VM Name String

    {

        hr = HRESULT_FROM_WIN32(ERROR_OUTOFMEMORY);

        goto Cleanup;

    }

  

    // Get the Virtual Machine object of the provided VMNAME

    hr = pIVPC->FindVirtualMachine(bName, &pVM);

    if (hr != S_OK)

    {

        goto Cleanup;

    }

  

    // Check the Virtual Machine State for Running

    hr = pVM->get_State(&vmState);

    if (hr != S_OK)

    {

        goto Cleanup;

    }

  

    if(vmState == vmVMState_Running)

    {

        // VM is Running

    }

    else 

    {

        // VM is not Running

        goto Cleanup;

    }

  

    // Get the USB Device Collection

    hr = pIVPC->get_USBDeviceCollection(&pUSBDeviceCollection);

    if (hr != S_OK)

    {

        goto Cleanup;

    }

  

    // Get the USB Device Collection Count

    hr = pUSBDeviceCollection->get_Count(&usbDeviceCount);

    if (hr != S_OK)

    {

        goto Cleanup;

    }

  

    if (usbDeviceCount == 0) // No USB Devices Connected to the Machine

        goto Cleanup;

        

    // Iterate through the USB Device Collection for the Device to be Assigned

    for ( index = 1; index <= usbDeviceCount; index++)

    {

        hr = pUSBDeviceCollection->get_Item(index, &pUsbDevice);

        if (hr != S_OK)

            goto Cleanup;

                

        // Get the Device Name or Manufacturer String 

        hr = pUsbDevice->get_DeviceString(&bDeviceString); 

        if (hr != S_OK)

            goto Cleanup;

  

        // Check the Device String for the Match

        if (_wcsicmp(bDeviceString, lUsbDeviceString) == 0 )

        {

            // Verify that the Device is attached to this VM

            hr = pUsbDevice->get_AttachedToVM(&bVmNameAttachedTo); 

            if (hr != S_OK)

                goto Cleanup;

  

            if (_wcsicmp(bVmNameAttachedTo, bName) == 0 )

            {

                // Device is Found attached to this VM

                bDeviceFound = TRUE;

                break;

            }

        }

    }

  

    if (bDeviceFound == TRUE)

    {

        // Device was found above.

        // Assign the Device to the VM

        hr = pVM->DetachUSBDevice(pUsbDevice);

        if (hr != S_OK)

            goto Cleanup;

    }

  

Cleanup:

    SAFE_RELEASE(pIVPC);

    SAFE_RELEASE(pVM);

    SAFE_RELEASE(pUSBDeviceCollection); 

    SAFE_RELEASE(pUsbDevice); 

    SysFreeString(bName);

    SysFreeString(bDeviceString);

    SysFreeString(bVmNameAttachedTo);

    

    return 0;

}

  

HRESULT 

InitVPCComInterfaces(

            __inout IVMVirtualPC** ppIVPC

    )

{

    HRESULT     hr      = S_OK;

    BSTR        bVer    = NULL;

    

    // Initialize COM

  

    hr = CoInitializeEx(NULL, COINIT_APARTMENTTHREADED);

    if (hr !=  S_OK) 

        return hr;

  

    REFCLSID classID = _uuidof(VMVirtualPC);    

  

    // Get the VPC object

    hr = CoCreateInstance(classID, 

                          NULL, 

                          CLSCTX_ALL, 

                          IID_IVMVirtualPC, 

                          (LPVOID*)ppIVPC);

  

    if (SUCCEEDED(hr) && (*ppIVPC != NULL))

    {       

        // Make a call to the VPC interface and see if it works.

        hr = (*ppIVPC)->get_Version(&bVer);

    }

  

    SysFreeString(bVer);

    return hr;

}

Using Group Policy Objects to restrict USB Devices

In Windows 7, GP objects can be managed using Powershell or using COM scripts. These can be extended to restrict USB Devices in Virtual Machines.

Create own applications on top of these APIs

A device gets assigned to host OS whenever the VM is hibernated, shutdown/restarted. WVPC doesn’t provide a direct option to assign a USB device automatically in these scenarios. However, a developer can create their own applications using the above APIs.

Conclusion

Managing USB devices of Windows XP Mode and WVPC is very simple and straightforward. USB devices can be shared or even assigned to a VM. COM APIs can be used to assign-release devices or even creating applications for their own customized scenarios. We hope this information is useful to you.

Technorati Tags: Windows 7,Windows Virtual PC,Windows XP Mode,Networking,Application Compatibility,Windows Upgrade,VPC,VM,Virtual Machine,Virtualization,USB,Device Redirection

Rahul Rajwanshi

SDET

Microsoft Virtualization Team

Networking in Windows Virtual PC

TechNet Archive — Mon, 07 Dec 2009 00:46:20 GMT

This article will briefly explain how Networking works and the configuration options for Networking in Windows® Virtual PC (WVPC).

The Virtual PC host application emulates Intel DEC 21140A network cards. Each Virtual Machine (VM) can have up to four such emulated network cards. The ‘Create Virtual Machine wizard’ in WVPC attaches by default one or two network adapters to connect to one wired and one wireless host network adapter (Fig. 1). Each emulated network adapter is assigned a unique MAC address in the range 00-03-ff-XX-XX-XX. The last three octets are calculated using the host network adapter MAC address. Each network card optionally connects to the various networking options described below.

Fig 1: Setting Dialog box to configure VM network adapters.

Windows^® XP Mode is by default connected to the Shared Networking or NAT, which is one of the four network connection options WVPC provides.

Network Connection Options in Windows Virtual PC

Each of the network adapters can be configured to connect to the virtual network as explained below. Fig. 1 shows the Setting dialog box and each network card can optionally connect to the network using the following options:

1. Not Connected: This option leaves the card unconnected to any network and will show that the network cable is disconnected inside the virtual machine.

2. Host Adapter: This option, called the ‘Bridge Mode’, is used to connect to the external network using the host network adapters. When the VM is connected using this option, the virtual card has a unique presence on the network. This option requires the Virtual PC Network Filter driver to be installed in the host networking stack. This driver gets installed during the WVPC installation and also binds to all the 802.3/802.11 based network adapters. In the diagram below you can see that Virtual PC Network filter driver is bound to one of the host adapter. To open this dialog, open Windows Start menu, type Network and Sharing Center. In the left click on Change Adapter settings. Select the required Adapter and right click to open properties which will show you this dialog.

Fig 2: WVPC network filter driver bound to the host, while using Bridge Mode.

Brief Architecture of Bridge Mode Networking in Windows Virtual PC

This driver is a NDIS 6 Filter driver and sits above the miniport layer in the NDIS stack. It maintains a 1:1 mapping between the protocol and miniport layers of NDIS. It is designed to handle Ethernet packets which makes it protocol agnostic and thus can support protocols other than TCP/IP. The above diagram shows that the Virtual PC Network Filter driver is bound to the Host Ethernet adapter and Guests can use this adapter to connect to the external network.

Fig 3: High Level Architecture of Bridge Mode Networking

Fig 3 shows the high level architecture of the bridge mode networking. In this diagram, the left side shows the host networking stack in which WVPC network driver vpcnfltr.sys is installed. The block on the right hand side represents the WVPC application which emulates the network card, connects it to the virtual network which in turn can connect to the vpcnfltr driver. This driver is a filter driver which intercepts the packets, inspects them and does basic level Ethernet switching to route it to its destination. When the packet is sent from the guest, it checks the MAC address destination and if it is meant for the host it injects into the higher level host NDIS stack. If the packet is meant for another guest, it indicates to them internally and remaining packets are sent to the external network through the host adapter.

The host Ethernet adapter generally accepts only those packets which are destined for its own MAC address. To receive other packets which could be destined for the guests, it puts the adapter in promiscuous mode (only for 802.3) which will make the host adapter start accepting all packets. The driver on receive from the adapter checks for the MAC address and if it matches for any of the guest registered with the driver, it sends it to the guest. Also if the packets are directed then it is not sent to the host upper layers. Similarly packets meant for the host are not sent to any other guest and is indicated to the higher level NDIS stack for further processing.

3. Shared Networking: Shared Networking or Network Address Translation (NAT) is another way that the guest can connect to the external network. The main difference between this and the bridge mode is that the guest is behind the NAT and it does not have a unique identity in the external network. It supports all connections which uses TCP/IP. Connecting using the bridge mode networking requires separate IP Address for the guest, thus in situations where there is a shortage of IP addresses, connecting using NAT is a valuable option. This option should also be used in cases when you don’t want to directly connect to an external network and remain behind this NAT. This acts as a strong firewall which protects the guest from outside attacks.

There are certain limitations while connecting using NAT. If the payload contains the source IP Address, then it may break as the IP address is replaced with the host but the payload will still contain the guest IP address. Also connecting via VPN from inside the guest is not supported. Some VPN requires raw sockets to be opened, which needs admin privileges to successfully open these sockets, whereas WVPC application runs in the user context. Applications using TCP/IP like Internet Browsing, messenger, shared access, etc. will work when connected using NAT. It is recommended to connect using the bridge mode when the guest needs to use VPN.

4. Internal Network: This option is used to connect two or more guests together for an isolated network. When the guest is using this option, it can only connect to the other guests on the same physical machine. WVPC application internally has a software switch which forwards the packets meant for the destination guest without connecting to the external world. This is useful for cases where you want to connect to two or more machines completely isolated from the network. The internal network also maintains the DHCP server and provides the DHCP addresses in the range of 169.254.0.16 to 169.254.10.254. If another guest is acting as DHCP Server, you would need to disable the DHCP server so that DHCP packets can reach to that guest.

In Closing

There are multiple options to connect VMs created using WVPC to internal and external networks. We hope this information is useful to you. Check out Windows® XP Mode today, and let us know what you think, either via the comments section here, or sharing your feedback on the WVPC and Windows XP Mode Forum on TechNet here.

Technorati Tags: Windows 7,Windows Virtual PC,Windows XP Mode,Networking,Application Compatibility,Windows Upgrade,VPC,VHD,VM,Virtual Machine,Virtualization,NAT

Vrijesh Kothari

SDE

Microsoft Virtualization Team

Various File Types for Virtual Machine Backup in Windows Virtual PC

TechNet Archive — Wed, 02 Dec 2009 06:27:43 GMT

File Types

Following are the various file types registered on a user’s machine when Windows® Virtual PC is installed:

File extension	Description	Should back up?
.VMC (Virtual Machine Configuration)	Contains Virtual Machine (VM) configuration like RAM, hard disk, network settings and undo disk settings. This file is associated with vmwindow.exe.	Yes
.VHD (Virtual Hard Disk)	This is the hard disk of VM and most important file to back up. This is a large file and it should be created on disk volume with enough free space. All data for the VM including the operating system data are stored in this file. Refer this article for more details for understanding disk types.	Yes
.VUD (Virtual Undo Disk)	Undo disk for the VM. When undo disk option is enabled all changes to VM are stored in this file. This file is generated at the same path as the .VMC file. So, if you keep undo disk enabled for long time, make sure there is enough free disk space in the volume.	Yes
.VSV (Virtual machine Saved-State)	Dump of virtual machine RAM. Helps to restore VM quickly. Size of this file is the same as amount of RAM assigned to the VM	No
.VFD (Virtual Floppy Disk)	Floppy disk image. There is no UI to attach VFD to VM since usage of floppy is obsolete. User can still use COM API to attach vfd to VM	Yes
.VMCX (vmc eXtended)	This is used by VPC for internal usage only. Explorer shell uses this file to display virtual machine information to the user	No
. vpcbackup	Internal use only. Keeps backed up .vmc file	No

How to backup a virtual machine

Now with the understanding of various file types, it should be clear that .VHD is the most important file to save when you want to back up a VM. Follow the steps as below:

Shutdown the VM. This is important since saved state files (.VSV) are not compatible across machines. Save state stores VM system state and is processor dependent. Moving it to another machine may not boot the VM.
If VM has undo disk enabled, commit or discard the changes. If you want to keep the undo disk for future use, you need to backup .VUD file also. VUD file is created at same path as of .VMC file.
At this time, also backup .VHD and its parent disk (you can find the parent disk by using settings of VM). Backup .VUD file if undo disk is still present.
Backup .VMC file.
A differencing disk (.vhd) keeps pointer of parent disk as absolute and relative path. So when you backup make sure relative path is in same order.

Illustration with Windows XP Mode VM

Let’s walk through an example for backing up a VM created in Windows® XP Mode:

Shutdown the VM. By default, Windows XP Mode goes to save state. For details on VM shutdown, please refer to this post
Open settings for VM. Select “Hard disk 1” page. Here, take note of the disk type. For Windows XP Mode VHD, the disk type is differencing disk. As such, you need backup differencing disk and its parent disk. It is very important to backup the parent disk, without which the differencing disk will not work.

Figure 1. Specifying the Hard Disk location in Windows XP Mode Settings UI

3. Check Undo disks settings. If this is enabled, open directory of .VHD as shown in hard disk page. Here you can find the .vud file

4. The .VMC file is stored at %localappdata%\Microsoft\Windows Virtual PC. You can find the path of .VMC file in “Virtual Machines” folder. Refer “Configuration file” column in this folder

5. Copy .VMC, .VHD, .VUD file to backup virtual machine. Make sure you keep the relative path same for diff disk VHD and parent VHD. A typical out of box installation of Windows XP Mode VM involves the following files to backup

%localappdata%\Microsoft\Windows Virtual PC\Virtual Machines\Windows XP Mode.vhd (Diff disk)

C:\Program Files\Windows XP Mode\Windows XP Mode base.vhd (Parent disk)

%localappdata%\Microsoft\Windows Virtual PC\Virtual Machines\Windows XP Mode.vmc (Configuration file)

How to restore a backed up VM

There are various ways to back up the VM files. You may be using Windows® backup for complete system backup or making volume back up using VSS or you may use simple copy to save VM files. The important point is to backup all required files (.VHD, .VUD, .VMC) and restore them using same toolset.

Technorati Tags: Windows 7,Windows Virtual PC,Windows XP Mode,Application Compatibility,Windows Upgrade,VPC,VHD,VM,Virtual Machine,Virtualization,VFD,VMCX,VSV,Backup

Vinod Atal

SDE

Microsoft Virtualization Team

Virtual Hard Disks (VHDs) in Windows Virtual PC

TechNet Archive — Tue, 24 Nov 2009 05:01:36 GMT

What are VHDs?

Virtual Hard Disks (abbreviated to VHDs) are files on the physical machine that store the hard disk contents of a Virtual Machine (VM). Each VHD file is treated as a separate hard disk by Windows® Virtual PC (WVPC).

The Virtual Hard Disk file format is an open standard. For the curious, the specifications of VHD file format can be found here: http://technet.microsoft.com/en-us/virtualserver/bb676673.aspx. As can be seen, the format is quite straightforward and is completely agnostic to the virtualization technology in use and to the host and guest operating systems.

WVPC, Windows® XP Mode, Microsoft Hyper-V®, Virtual PC 2007® and other Microsoft’s virtualization solutions use the VHD format.

Types of VHDs

There are three types of Virtual Hard Disks: fixed disks, dynamically expanding disks and differencing disks.

Fixed disks take up all the space that the VHD is allowed to have up front. For instance, if you create a fixed disk of size 64GB, the VHD file will occupy 64GB of hard disk space right from the time of creation, and its size will never vary.

Dynamically expanding disks (also called sparse disks) increase in size to take up space as required. The size specified when creating a dynamically expanding disk indicates the maximum size that the disk is allowed to grow to. For instance, if you create a dynamically expanding disk of size 64GB, the VHD file might initially occupy only a few KB. It will slowly grow upon usage to occupy up to the maximum size specified (64GB). Note however, that the guest operating system will be made to believe it has the full 64GB right from the start.

Differencing disks are a little different. They merely save the changes to the VHD relative to a base disk. Differencing disks are always linked to a dynamically expanding disk or a fixed disk, either directly or through one or more other differencing disks. To understand differencing disks, let us say you create a fixed disk with Windows® XP installed on it. Now if you create a differencing disk and install Microsoft Office® on this, the differencing disk will contain mainly* the content of the hard disk locations changed by the installation of Microsoft Office®, which will be the locations containing the new files and any modifications to existing files.

* I say “mainly” since the operating system will make changes to the hard disk too, as part of its regular operation (writing to the page file, for instance).

To illustrate this point, take a look at the figure below. There are two VMs using two differencing disks that branch from the same base disk.

Figure 1. Two VMs on a single host with their Differencing disks sharing the same Base disk

The changes made by VM#1 are saved in its differencing disk (depicted as orange blocks) and the changes made by VM#2 are saved in VM#2’s differencing disk (depicted as green blocks). Wherever there is no data in the differencing disk (i.e., a blank space between the orange blocks), the data will be automatically fetched from the base disk. Thus, VM#1 will see the resultant hard disk as a mix of orange and blue blocks. Neither VM#1 nor VM#2 will be able to see the changes made by the other since these changes are on different differencing disks, and both think they have their own copy of the base disk.

The base reference disk is called the “parent” of the differencing disk, and the differencing disk is called its “child”. As you might have guessed, a differencing disk is unusable without the parent disk. What’s more, any change made to the parent will potentially invalidate the child since the reference file is now different. This is why it is recommended to choose a base parent disk and mark it “read-only” for good.

And what’s the size of the differencing disk, you ask? Well, the differencing disk grows in size as required, and inherits the maximum size from its parent disk.

Using VHDs

Needless to say, all types of VHDs will have the “.vhd” extension. The maximum size of the VHDs supported by Windows Virtual PC is 127GB.

Dynamically expanding disks and differencing disks are by far the most commonly used VHD types.

The biggest advantage of differencing disks is that you can have as many child disks as you like from a single parent disk. So if you need 5 virtual machines with Windows® XP with each configured differently, you can simply create a single sparse/fixed VHD with Windows® XP installed on it and then create 5 differencing disks from this. So that’s saving 4 times the space needed to install Windows® XP!

Indeed, this is the approach used in Windows® XP Mode! Well, let me explain that in detail.

VHDs and Windows XP Mode

When a user installs the Windows® XP Mode package, a dynamically expanding VHD is placed on the system. This is the base VHD, which contains a sys-prepped copy of Windows XP SP3®. The base VHD has already been marked read-only, and what’s more, it’s permissions have been set in such a way that only TrustedInstaller can make changes to it (and the only change TrustedInstaller will make is to remove the file on uninstall). This takes care of having a pristine base VHD that won’t be modified (Figure 2).

When you click on the “Windows XP Mode” link on the start menu after installing the VHD, VPC detects that the VHD has been installed and launches a wizard that takes basic information needed to create the VM. As you can see, this wizard is different from the wizard used to create a VM – for starters, this wizard has already decided to create a differencing disk with the Windows XP Mode VHD as the parent; it merely asks you where you want to place the differencing disk.

Each user on the computer will be shown this wizard and will have a new differencing disk created for them. This way, every user has access to their personal copy of Windows XP without taking up extra space for the Windows XP install.

Figure 2. Different VMs sharing the same parent VHD in Windows® XP Mode

This above example is a typical use-case for differencing disks. You can have a similar setup on your machine(s) with Windows® Vista and/or Windows® 7 VMs too. Of course, it is strongly advised that you optimize the base VHD before calling it pristine and marking it read-only. Ah, we haven’t discussed VHD optimizations yet, have we? Well, considering that topic is big enough to merit its own post, I’ll save that for another day. Stay tuned for more on VHDs!

Technorati Tags: Windows 7,Windows Virtual PC,Windows XP Mode,Application Compatibility,Windows Upgrade,VPC,VHD,VM,Virtual Machine,Virtualization,Parent Disk,Differencing Disk

Thayu Ramaiah

SDET

Microsoft Virtualization Team

Using Scripting API for Advanced Operations in Windows Virtual PC

TechNet Archive — Mon, 16 Nov 2009 04:27:12 GMT

Windows^® Virtual PC (WVPC) brings for the first time scriptable API to a Microsoft client virtualization product. These APIs are a very powerful tool in the hands of power users and administrator to do some very cool things and achieve functionality which is not obvious or possible from the normal user interface. We present here a few examples of how to use these API in Windows PowerShell^®.

Deleting a Virtual Machine completely

Windows virtual PC provides a new and unique console view for Virtual Machine (VM) management. Here, VMs are represented as files (.vmcx) in the Virtual Machines folder. The Virtual Machines folder is present at (%systemdrive%\Users\<user name>\Virtual Machines). Here you can see how many VMs are registered on your system, their state and create new VMs. Removing a VM is just deleting the .vmcx file. But this does not remove the VM completely. Rather, it just unregisters the VM, and the virtual machine files are still present on your system (in the folder %localappdata%\Microsoft\Windows Virtual PC\Virtual Machines\) which you can bring back very easily by just double-clicking on the .vmc file. But this would create a lot of clutter on your system over time if you create a lot of VMs.

Using the following PowerShell script you can easily remove a VM completely. Please replace “My VM” with the name of your virtual machine. Be very careful while using this script as it would remove all the files related to your virtual machine including VHDs.

        1: $vpc = New-Object -ComObject "virtualpc.application"

       2:  

       3: $vm = $vpc.FindVirtualMachine("My VM")

       4:  

       5: if ( $vm )

       6:  

       7: {

       8:  

       9: if ($vm.state -eq 5) # check for running state

  

{

  

echo "cannot delete a running VM"

  

}

  

else 

  

{

  

if ($vm.state -eq 2) # check for saved state

  

{

  

echo "Discarding saved state"

  

$vm.DiscardSavedState()

  

}

  

if ($vm.undoable -eq $true)

  

{

  

echo "discarding undo disks"

  

$vm.DiscardUndoDisks()

  

}

  

foreach ($hdc in $vm.HardDiskConnections)

  

{

  

echo "deleting vhd file"

  

$hd = $hdc.HardDisk ;

  

$vm.RemoveHardDiskConnection($hdc) ;

  

del $hd.File ;

  

}

  

echo "deleting virtual machine"

  

$vpc.DeleteVirtualMachine($vm)

  

}

  

}

  

else

  

{

  

echo "VM does not exists"

  

}

Moving the parent of a VM’s hard disk to some other location

Moving a VM is easy. Just copy all the virtual machine files (.vmc, .vhd, .vsv etc) to a different location and double-click on the .vmc file to start the VM from there. What if your virtual machine has a differencing disk? If the parent VHD is located in the same folder as the child then you just need to move all the files together for relocating you VM. But if your VM’s parent is in some other folder, then you cannot change the location of the parent, otherwise your VHD chain would break and you would not be able to start your VM. Let us see, with the help of an example, how you can use the VPC COM APIs to get over this limitation.

Suppose the parent disk (parent.vhd) is present at c:\vhdstore.

Your other VM files are present in the usual location (%localappdata%\Microsoft\Windows Virtual PC\Virtual Machines\) and you want to move these files to the D: drive as you want to format your C: drive. You place the parent VHD in the location D:\VHDStore and all the other files at D:\VMs. Now your VM won’t start as you parent location would not match with the one that is present in the child VHD.

Run the following commands on the PowerShell to restore the new path of the parent VHD and make the VM operational again. It’s assumed that your VM name is “My VM” and the new parent location is “D:\VHDStore\parent.vhd”

       1: $vpc = New-Object -ComObject "virtualpc.application"

       2:  

       3: $vm = $vpc.FindVirtualMachine("My VM")

       4:  

       5: $hd = $vpc.GetHardDisk("D:\VHDStore\parent.vhd")

       6:  

       7: $vm.HardDiskConnections.Item(1).harddisk.parent = $hd

Now you should be able to start your VM from the new location.

You can use this trick even if you just want to change the location of your parent VHD and not move the other files.

Disabling Time Sync between the host and guest

Windows virtual PC periodically syncs the time of the guest to that of the host to keep both of them in sync. But if you do not want that to happen then you can disable time sync totally using the following script. Please remember that the Virtual Machine should be in the turned off state before running this script.

       1: $vpc = New-Object -ComObject "virtualpc.application"

       2:  

       3: $vm = $vpc.FindVirtualMachine("My VM")

       4:  

       5: $vm.SetConfigurationValue("hardware/bios/time_sync_at_boot",$false)

       6:  

       7: $guest = $vm.GuestOS

       8:  

       9: $guest.IsHostTimeSyncEnabled = $false

In closing…

Using the COM APIs provided with WVPC, you can achieve some of the things that seem to be not possible using the conventional user interface. Keep a watch on this blog space for more such tips and tricks. And you can check out the WVPC COM APIs here http://msdn.microsoft.com/en-us/library/dd796756(VS.85).aspx, and see the vast set of APIs provided to help with your VM management tasks.

Technorati Tags: Windows 7,Windows Virtual PC,Windows XP Mode,VPC,VHD,VM,Virtual Machine,Virtualization,VM scripts,Time Sync,Move VHD,Delete VM

Palash Kar

SDE

Microsoft Virtualization Team

Auto-Start and Close Options for Windows Virtual PC

TechNet Archive — Mon, 09 Nov 2009 03:49:00 GMT

In Windows® Virtual PC (WVPC), Virtual Machine (VM) start-up and close behavior can be configured to have a customized user experience. Few start-up options can actually lead to perceivably faster launching of Virtual Applications. In this blog, we will discuss these options and settings along with their pros and cons. This should be helpful for you to understand the best performance tweaks that can be done with WVPC VM and the kind of impact it can have on your machines.

Once a VM is created, it can be started in Desktop mode from the Windows® Virtual PC Center. However Windows® XP Mode VM can be directly started from the Start Menu.

Figure 1: Windows® Virtual PC Center to create or launch a VM

If Integration Components (IC) are installed (recommended), then by default the VM tries to enable Integration Features (IF) on VM start-up. This behavior can be changed through VPC Settings -> Integration Features -> Uncheck ‘Enable at startup’. However the user always has the option to manually enable/disable Integration Features while VM is running, from the tools menu as well. The same can also be accomplished through script #1.

Start-up time of a VM may be reduced if this setting is disabled but Integration Features like Clipboard (copy/paste), Drive, Printer and Smart Card redirection will not be available. Also the POST screen of the VM booting would be visible.

This may be the ideal usage setting where VM needs to be used in isolation from the host or is only remotely accessed through Remote Desktop Connection etc.

Figure 2(a): WVPC Settings to change Auto-Enable Integration Features Figure 2(b): Manually disabling Integration Features

Script #1: Disable Integration Features at Start-up

        1: Option Explicit   ' Force explicit variable declaration.

       2:  

       3: Dim defaultVMTag, defaultVM, objArgs, objVPC, vmName  

       4: Set objArgs = WScript.Arguments

       5: Set objVPC = CreateObject("VirtualPC.Application")

       6:  

       7: defaultVMTag = "default_vm"

       8: defaultVM = objVPC.GetConfigurationValue(defaultVMTag)

       9:      

if objArgs.Count < 1 Then

WScript.Echo "Syntax: cscript <scriptname>.vbs <”VMName”>"

     WScript.Echo "Considering default VM."     

     vmName  = defaultVM

Else

     vmName  = objArgs(0)        

End if

  

DisableIF()

 

Sub DisableIF()

    Dim vmcTag, objVM

    vmcTag = "ui_options/use_enhancedmode"

    Set objVM = objVPC.FindVirtualMachine(vmName)

    

if objVM is Nothing Then

WScript.Echo "VM not found: """ + vmName + """" 

Else

WScript.Echo "Disabling Integration Features at Startup for the VM: """ + vmName + """"

objVM.SetConfigurationValue vmcTag, False

    WScript.Echo "Integration Features at start-up disabled successfully"        

End if

End Sub

This script will disable Integration Features for the default VM (or the specified VM, if <VMName> is passed as an argument to the script).

Similarly, a Virtual application can also be launched from Windows® 7 Host start menu once the application has been published from the VM. All published applications of a VM are listed under, Programs -> Windows Virtual PC -> <VMName> Application* in Windows® 7 Start Menu.

PS: Scripting provides a useful means to perform a number of operations on VMs such as Creating, deleting, changing VM configuration, states and tracking VM state, health and other information about it. PowerShell is another powerful medium to interact with the VM. The blog uses VBScript for code snippets. These code snippets can be saved as <ScriptName>.vbs file and executed in Windows® 7 command prompt with the following syntax: cscript <Scriptname>.vbs arg1

Starting a headless VM

Sometimes, you might want to start a VM in the back ground without any User Interface. This can be of great use for IT Administrators/Professionals, Developers & testers. For example if you want to reduce the latency of Virtual Applications start-up time, remotely use the VM through Remote Desktop Connections or execute some tests in isolation without any user interference.

This is referred as a Headless VM configuration.

Here is a sample VB script to start the VM in Headless mode.

Script #2: Starting a VM in Headless Mode

       1: Option Explicit   ' Force explicit variable declaration.

       2:  

       3: Dim defaultVMTag, defaultVM, objArgs, objVPC, vmName  

       4: Set objArgs = WScript.Arguments

       5: Set objVPC = CreateObject("VirtualPC.Application")

       6:  

       7: defaultVMTag = "default_vm"

       8: defaultVM = objVPC.GetConfigurationValue(defaultVMTag)

       9:      

if objArgs.Count < 1 Then

WScript.Echo "Syntax: cscript <scriptname>.vbs <”VMName”>"

     WScript.Echo "Considering default VM."     

     vmName  = defaultVM

Else

     vmName  = objArgs(0)        

End if

  

WScript.Echo "Starting VM: """ + vmName + """"

StartHeadlessVM()

 

   Sub StartHeadlessVM()

    Dim objVM

    Set objVM = objVPC.FindVirtualMachine(vmName)

    if objVM is Nothing Then

        WScript.Echo "VM not found: """ + vmName + """"          

    Else

Dim objVMTask

        Set objVMTask = objVM.Startup()

        'Set objVMTask = objVM.TurnOff() 'Immediately Turns Off/Powers Down the VM

        'Set objVMTask = objVM.Save()    'Hibernate the VM

        'Set objVMTask = objVM.GuestOS.Shutdown(0) 'Controlled Shutdown

        'Set objVMTask = objVM.GuestOS.Shutdown(1) 'Forced Shutdown

        objVMTask.WaitForCompletion -1

        WScript.Echo "VM Started : """ + vmName + ""        

    End if

   End Sub

When host logoff, shutdown or restart is initiated, each running headless VM is first hibernated. This may cause some delay in host logoff, shutdown or restart. Also Integration Features cannot be enabled for headless VM. Additionally, user also has to keep a track of headless VMs as they run behind the scene i.e. without any User Interface.

Auto Start a VM

A VM can be configured to start at Windows® 7 start-up. When a VM is setup to start on Windows 7 Start up, it drastically reduces the time required for first time launch of Virtual Application. However, with this configuration, the VPC.exe will keep running, holding the resources like RAM allocated to the VM and speed up battery drainage on laptops. However in case of desktops the following configuration can help is faster launching of Virtual Application. Since the VM would be started immediately after login into Windows 7, there might be some impact on the responsiveness of the host for couple of seconds.

Auto Start a Virtual Application:

Copy the shortcut of the Virtual Application to start-up folder of Windows 7 that needs to be started on Windows 7 start-up. In this example, Virtual Application-Internet Explorer 6 has been set to auto start with Windows 7 start-up.

Location:

Virtual Application: %appdata%\Microsoft\Windows\Start Menu\Programs\Windows Virtual PC\<VMName> Applications*

Windows 7 Start-up Folder: %appdata%\Microsoft\Windows\Start Menu\Programs\Startup

Auto Start VM in Headless mode

Create a shortcut of script #2 under Windows® 7 start-up folder with the following target: cscript <pathoftheScript>\<scriptname>.vbs <”VMName”>

Figure 3: Set a Virtual Application to Auto-Start

Auto Start VM in Desktop Mode

VM can also be set to auto start with Windows® 7 start-up in desktop mode. This can be easily accomplished by adding the shortcut of the <VMName> .vmcx file (vmcx file is located in Windows® Virtual PC Center) in start-up folder.

Figure 4: Set VM to Auto-Start in Desktop Mode

Close a VM

A VM in Desktop Mode can be manually closed by the user, either from the user Interface (Figure - 5) or through scripts (refer script #3 for details). Notice that there are 4 options for ‘Closing’ a VM. Each option has its own benefits and use case.

Figure 5: Close VM options.

Hibernate: This is very similar to hibernate of a physical machine. The VM is initially set to Pause/sleep state and then VM memory is purged to a save state file (<VMName>.vsv). The difference in VM hibernate as appose to a Physical machine is that VM is unaware about hibernation or resume thereafter. Unlike the physical machine where the machine itself initiates hibernation/resume, here the Host does it for the VM. Hence, this operation doesn’t require ICs to be installed. This mechanism offers benefits like quick shutdown and resume, no data loss. This is the default close setting for XP Mode VM. This setting can be modified either through VPCSettings -> Close.

It is not recommended to migrate a VM in hibernate state as difference in processor architecture of the two host machines can render the save state useless. In such case, deleting the save state file would allow the VM to boot up, but may lead to data loss.

Alternatively VM can be hibernated through scripts. Script #2 can be easily modified to accommodate the same.

Shutdown: This would initiate a graceful shutdown of the VM. Since this is done by Guest OS it requires ICs to be installed in the VM. Here the scripts provide an additional option to force shutdown the VM. Shutdown of a VM is absolutely identical to a physical machine.

Turn Off: This is very similar to Powering off the machine. It is not recommended as it may lead to data loss or corruption of Guest OS.

Turn Off and discard changes: This option appears only when ‘Undo Disks’ is enabled. It will delete all data in the undo disk (.vud file). This option should be used with caution as it may lead to data loss.

Figure 6: Default close VM setting for XP Mode

Script #3: Enable prompt while closing the VM

       1: Option Explicit   ' Force explicit variable declaration.

       2:  

       3: Dim defaultVMTag, defaultVM, objArgs, objVPC, vmName  

       4: Set objArgs = WScript.Arguments

       5: Set objVPC = CreateObject("VirtualPC.Application")

       6:  

       7: defaultVMTag = "default_vm"

       8: defaultVM = objVPC.GetConfigurationValue(defaultVMTag)

       9:      

if objArgs.Count < 1 Then

WScript.Echo "Syntax: cscript <scriptname>.vbs <”VMName”>"

     WScript.Echo "Considering default VM."     

     vmName  = defaultVM

Else

     vmName  = objArgs(0)        

End if

  

PromptAtClose()

 

   Sub PromptAtClose()

Dim vmcTag, objVM

    vmcTag = "ui_options/onclose_showmessage"

    Set objVM = objVPC.FindVirtualMachine(vmName)

    if objVM is Nothing Then

        WScript.Echo "VM not found: """ + vmName + """"          

    Else

WScript.Echo "Enable prompt on VM close: """ + vmName + """"

        'This will enable prompt at close. User can then choose the close method

        objVM.SetConfigurationValue vmcTag, True

        'To set the default behaviour at VM close. No prompt will be thrown in this case

'and default action can also be set

        'objVM.SetConfigurationValue vmcTag, False

'objVM.SetConfigurationValue "ui_options/onclose_defaultaction", "save" 'save/shutdown/turnoff

        WScript.Echo "Close option set successfully"        

    End if

   End Sub

However, shutdown in case of a Virtual Application does not involve any explicit User Interface. Let’s look at the VM state transitions that take place when a user interacts with Virtual Applications:

VM will be started if it is not already running when the first Virtual Application is launched.
When the last Virtual Application (launched by the user) is closed and none of the other Virtual Application’s window is opened, the VM hibernates after 5 minutes. Script #4 can be modified to set the value of the VMC tag: ‘ui_options/seconds_to_save’ to the desired time duration).
While Virtual Applications are running and Windows® 7 host is logged off or shutdown, graceful (controlled) shutdown of VM is initiated.
Similarly, if Windows® 7 host goes to hibernate or sleep state, the VM is paused. On host resume, the VM auto wakes up. This may also cause the Virtual applications to be unresponsive during this short time interval.
In case of forced Host shutdown, VM is powered off abruptly.

Note: In case of headless VM, Windows® 7 Host logoff/shutdown/restart will always initiate VM hibernate/save.

‘Never Hibernate’ VM Setting

When the last Virtual Application is closed (launched by the user), the VM will go into hibernate state after 5 minutes by default. This is done to ensure that host resources are freed and battery drain can be reduced when no virtual application is running. This setting can be changed so that the VM never hibernates and subsequent Virtual application can be launched with minimum latency.

Script #4: Set VM to Never Hibernate

       1: Option Explicit   ' Force explicit variable declaration.

       2:  

       3: Dim defaultVMTag, defaultVM, objArgs, objVPC, vmName  

       4: Set objArgs = WScript.Arguments

       5: Set objVPC = CreateObject("VirtualPC.Application")

       6:  

       7: defaultVMTag = "default_vm"

       8: defaultVM = objVPC.GetConfigurationValue(defaultVMTag)

       9:      

if objArgs.Count < 1 Then

WScript.Echo "Syntax: cscript <scriptname>.vbs <”VMName”>"

     WScript.Echo "Considering default VM."     

     vmName  = defaultVM

Else

     vmName  = objArgs(0)        

End if

  

  

 SetValue()

 

 Sub SetValue()

 Dim vmcTag, objVM

 vmcTag = "ui_options/seconds_to_save"

 Set objVM = objVPC.FindVirtualMachine(vmName)

 if objVM is Nothing Then

        WScript.Echo "VM not found: """ + vmName + """"          

 Else

         objVM.SetConfigurationValue vmcTag, 0

WScript.Echo "VM: """ + vmName + """ set to never hibernate"

 End if

 End Sub

This script sets the value of VMC tag "ui_options\seconds_to_save" to 0 and hence VM would never be hibernated even after closing the last Virtual Application. This tag can also be used to increase or decrease the time to hibernate the VM when last Virtual application is closed.

Note: This tag doesn’t impact VMs running in desktop or headless mode.

In most of the cases, this would ensure faster virtual application launch, as VM doesn’t hibernates after closing the last virtual application (launched by the user). But in case of host restart, first virtual application launch will still take time as VM needs to be started first. This can also be tweaked by adding an entry of starting a headless VM on Window 7 startup (refer Auto Start VM in Headless Mode)

Conclusion

In WVPC, you can configure the VM start-up and close behavior using WVPC settings and the sample scripts presented above, to optimize the user experience and performance of VMs and virtual applications. Check out WVPC and Windows XP Mode today, and let us know what you think, either via the comments section here, or sharing your feedback on the WVPC and Windows XP Mode Forum on TechNet here.

*This may get localized based on Windows® 7 Host language.

Technorati Tags: Windows 7,Windows Virtual PC,Windows XP Mode,Application Compatibility,Windows Upgrade,VPC,VHD,VM,Virtual Machine,Virtualization,Close,Shutdown,Hibernate,VM script,Headless VM

Priyank Gaharwar

SDET

Microsoft Virtualization Team

Tip: Using the keyboard to access useful functionality in Windows Virtual PC

TechNet Archive — Wed, 04 Nov 2009 12:22:23 GMT

When you use a Virtual Machine (VM) created using Windows^® Virtual PC (WVPC), following keyboard shortcuts would be very useful to make life simple without using the mouse:

Press this key	To do this
CTRL+ALT+Left Arrow	Release the mouse from the virtual machine’s (VM) window (required only when the integration features are not installed or are disabled). You can also use this shortcut to release the keyboard and move focus to the toolbar on the VM’s window.
CTRL+ALT+END	Send the CTRL+ALT+DEL command to a VM. This shortcut is also available while running virtual applications, when the focus is on such an application.
Windows logo key +UP Arrow	Switch from window mode to full-screen mode.
CTRL+ALT+PAUSE BREAK	Switch from full-screen mode to window mode.
ALT+F4	Close a VM.
CTRL+ALT +Plus key	Capture a print screen of the VM display output.
CTRL+ALT +Minus key	Capture a print screen of the window in the VM that has focus.
TAB + Right Arrow	Move to the Help menu from other menus on the VM toolbar. Before you can use this shortcut, you would need to press CTRL+ALT+Left Arrow to bring the focus on to the VM’s window.
TAB + Left arrow	Move from the Help menu to other menus on the VM toolbar. Before you can use this shortcut, you would need to press CTRL+ALT+Left Arrow to bring the focus on to the VM’s window.
ALT+B	Open the USB menu of the VM window. Before you can use this shortcut, you would need to press CTRL+ALT+Left Arrow to bring the focus on to the VM’s window.
ALT+P	Make the VM to go to a Sleep state. Before you can use this shortcut, you would need to press CTRL+ALT+Left Arrow to bring the focus on to the VM’s window.
ALT+U	Wake up the VM from sleep state.

Check out Windows XP Mode RTM Build today, and let us know what you think, either via the comments section here, or sharing your feedback on the WVPC and Windows XP Mode Forum on Technet here.

Technorati Tags: Windows 7,Windows Virtual PC,Windows XP Mode,Application Compatibility,Windows Upgrade,VPC,VHD,VM,Virtual Machine,Virtualization,Keyboard,Shortcut,Hot key

Rahul Razdan

Program Manager

Microsoft Virtualization Team

Publishing Virtual Applications in Windows Virtual PC

TechNet Archive — Mon, 02 Nov 2009 12:19:27 GMT

Windows® Virtual PC (WVPC) provides a feature called virtual applications, using which you can access applications running in a Virtual Machine (VM) seamlessly from Windows® 7 host Start menu. These applications get added to the host start menu automatically upon installing inside the VM using a feature called Auto Publish.

Preparing a VM for Auto Publish

For a Windows based VM (XP SP3 and higher versions), you need to install “Update for Windows® XP SP3 or above to enable RemoteApp™” or “Update for Windows® Vista SP1 or above to enable RemoteApp™” inside the VM. Windows® XP mode VHD has this package preinstalled. Also, you need to ensure auto-publishing is enabled in the virtual machine settings. Open ‘Virtual Machines’ folder and select the VM à right click à settings à Auto Publish.

Fig. 1. Enabling Auto Publish using WVPC settings dialog

Publishing an application

By default, applications installed under ‘All users’ profile are auto-published to the Windows 7 host. So, if an application has created its shortcuts in ‘All users’ profile, no action is required from user. There are applications which don’t install for “All users” and get installed for current user only. Follow the steps as below to publish such applications

Click on the Start Menu button
Right Click on Programs
Click open. You'll see the start menu open up as a folder. This is the start menu folder in the user's profile
You will see the application folder/shortcut appearing here. Copy that folder/shortcut (Ctrl+C)
Right Click on programs again and then Click on "Open All Users"
Now paste the above folder/ application shortcut to this folder (“All users” start menu)
In a few moments the application will get published to the host start menu

Let’s take an example for publishing command prompt. To publish it simply create a new shortcut to cmd.exe at "C:\Documents and Settings\All Users\Start Menu\Programs" inside the VM. That is all you need to do for publishing the command prompt (Fig 2).

Fig. 2. Adding a virtual application (cmd.exe) to All User programs folder to Auto Publish it

Using this shortcut, now you can launch any application inside VM as remote app or install new applications.

Controlling publishing

Though auto-publishing works totally automatically, with virtually no user intervention required; there are ways in which publishing can be controlled.

Exclude List

You may want some applications that you install in the guest to not get published to the host Start menu. For this we maintain a list inside the guest registry called the “Exclude List”. This list contains full paths of applications that we do not want to publish to the host start menu. The Exclude List is present in the guest registry at HLKM\Software\Microsoft\Windows NT\CurrentVersion\Virtual Machine\VPCVAppExcludeList.

This is illustrated by an example below (Fig 3). For example you install Microsoft Security Essentials (http://www.microsoft.com/security_essentials/ ) to secure your VM. This would publish the anti-virus’s UI to the host start menu which you might not want. You need to add this application to the exclude list. This is illustrated below.

1. Right-click on the Microsoft Security Essentials® shortcut on the Start menu and click on properties

Fig. 3. Microsoft Security Essentials dialog

2. Retrieve the full path of the application.

Fig 4. Retrieving the application path for adding it to the Exclude list

3. Add this path to the exclude list (remember to get rid of the quotes) and restart the guest.

Fig 5. Using Exclude list to prevent a virtual application from getting Auto published

4. Consequently you may want some application which is present in the All-User’s start menu but did not get published. These are windows default application which we have excluded by default. For that just delete the entry of that application from the exclude list and restart the guest. For example for publishing the XP MSPaint.exe to Windows 7 start menu, just delete the mspaint.exe entry from the exclude list.

5. Restart the Virtual Machine.

Manual publishing

Another way you can control the applications that get published to the host Start menu is through manual publishing. Here, the user disables auto-publishing and takes total control of what gets published to the host start menu. This is very useful for IT-Administrators who want to restrict applications that get published, irrespective of the number of applications that the user installs inside the guest.

Steps to manually publish the applications

Applications that get published to the host Start menu have an entry in the guest registry which is managed by the WMI class Win32_TSPublishedApplication. Scripting can be used to manipulate this WMI class to manually publish and unpublish application. This is illustrated below.

Shutdown the VM. Disable the Auto Publishing setting and then restart the VM.
Log in to the virtual machine as an administrator.
Install the application
Save the following VBScript to a .vbs file and execute it.
Do remember to replace the “App Name” with the name of the application and “App Path” with the full application path.
If you run it on a Vista on Windows 7 Virtual Machine, then run in on an elevated command prompt.

        1: '******************************************************

       2: 'Declare the variables to be used in the script

       3: '******************************************************

       4: strComputer = "."

       5: strNamespace = "\root\cimv2\TerminalServices"

       6: 'Replace "App Name" with the application Name.

       7: appName = "App Name"

       8: 'Replace "App Path" with the full application path.

       9: appPath = " App Path" 

'*******************************************************

'Create a unique ID for the app entry in the allow list.

'*******************************************************

  

set x = createobject("Scriptlet.TypeLib")

strNewGuid=Mid(x.GUID,2,8)

  

Set objSWbemServices = GetObject("winmgmts:\\" & strComputer & strNamespace)

Set objSWbemObject = objSWbemServices.Get("Win32_TSPublishedApplication")

Set objNewSWbemObject = objSWbemObject.SpawnInstance_()

  

'***************************************************************************************

'Set the various properties for the application to be added 

'***************************************************************************************

  

objNewSWbemObject.Properties_.Item("Name") = appName  

objNewSWbemObject.Properties_.Item("Alias") = strNewGuid

objNewSWbemObject.Properties_.Item("Path") = appPath

objNewSWbemObject.Properties_.Item("PathExists") = "true"

objNewSWbemObject.Properties_.Item("CommandLineSetting") = "1"

objNewSWbemObject.Properties_.Item("RequiredCommandLine") = ""

objNewSWbemObject.Properties_.Item("IconIndex") = "0"

objNewSWbemObject.Properties_.Item("IconPath") = appPath

objNewSWbemObject.Properties_.Item("VPath") = appPath

objNewSWbemObject.Properties_.Item("ShowInPortal") = "0"

  

'*******************************************

'Add the application entry 

'*******************************************

objNewSWbemObject.Put_

7. Restart the guest.

Note: - This is an indicative script and you might have to customize it according to your requirements. E.g., if the icon is not present in the executable file itself but is part of some other file, then that file path needs to be provided for the value of “IconPath”. Details of the various fields can be found at http://msdn.microsoft.com/en-us/library/bb736365(VS.85).aspx .

Steps to manually unpublish the applications

Similarly, you can manually unpublish an application using the following script.

       1: '******************************************************

       2: 'Declare the variables to be used in the script

       3: '******************************************************

       4: strComputer = "."

       5: strNamespace = "\root\cimv2\TerminalServices"

       6: 'Replace "App Name" with the application Name.

       7: appName = "App Name"

       8:  

       9: strQuery = "Select * From Win32_TSPublishedApplication  WHERE Name='" & appName & "'"

      10: Set objSWbemServices = GetObject("winmgmts:\\" & strComputer & strNamespace)

      11:  

      12: Set colItems = objSWbemServices.ExecQuery _

      13:     (strQuery)

      14: For Each objItem in ColItems

      15:         objItem.Delete_

      16: Next

To remove all the virtual applications, use the modified script below:

       1: '******************************************************

       2: 'Declare the variables to be used in the script

       3: '******************************************************

       4: strComputer = "."

       5: strNamespace = "\root\cimv2\TerminalServices"

       6:  

       7: strQuery = "Select * From Win32_TSPublishedApplication"

       8: Set objSWbemServices = GetObject("winmgmts:\\" & strComputer & strNamespace)

       9:  

      10: Set colItems = objSWbemServices.ExecQuery _

      11:     (strQuery)

      12: For Each objItem in ColItems

      13:         objItem.Delete_

      14: Next

Another way to do the same is through WMI management tools like wbemtest.exe or WMI Administrator tools (http://www.microsoft.com/downloads/details.aspx?familyid=6430F853-1120-48DB-8CC5-F2ABDC3ED314&displaylang=en ).

Using these tools, you can list the instances of the class Win32_TSPublishedApplication in the namespace root\cimv2\TerminalServices and then delete one or more of the instances to manually unpublish those applications. This is illustrated here http://technet.microsoft.com/en-us/library/cc738926(WS.10).aspx

Check out Windows XP Mode RTM Build today, and let us know what you think, either via the comments section here, or sharing your feedback on the WVPC and Windows XP Mode Forum on Technet here.

Technorati Tags: Windows 7,Windows Virtual PC,Windows XP Mode,Application Compatibility,Windows Upgrade,VPC,VHD,VM,Virtual Machine,Virtualization,Virtual applications

Palash Kar

SDE

Microsoft Virtualization Team

Windows Virtual PC

Windows Virtual PC and Windows XP Mode no longer require HAV processors

Folder Sharing between Windows 7 and VM

Sharing a Folder on Windows 7 Desktop with a VM

Fig. 1. Sharing a folder on Windows 7 host with a VM using the Setting User Interface

Sending a File from a VM to a Windows 7 Folder

Fig. 2. Creating a shortcut to send files from a VM to the Windows 7 host

Fig. 3. Using the right click menu to select the ‘Send To’ folder receiving the copied file from the VM

USB Architecture in Windows Virtual PC

Figure 1a: USB Menu on a Virtual Machine’s Tool Bar

Figure 1b: Manage USB Devices for Virtual Applications

USB Architecture

Figure 2: USB Architecture showing a USB Device in VM

Server Side (Host OS)

Client Side (Virtual Machine)

Figure 3: A USB Device assigned to a Virtual Machine

Power State Changes of Host and Virtual Machine

Virtual Machine Power State Changes

Host Power State Changes

Device Sharing vs. USB Device Redirection

Prevent Device Redirection using Group Policy

Figure 4: Group Policy Settings for USB Device restrictions

Preventing redirection of devices that match any of these Device IDs

Figure 5: Group Policy setting for redirection of specific USB devices restrictions

Preventing redirection of USB devices

Implementation and Code examples

Assign a USB Device

Release a USB Device

Using Group Policy Objects to restrict USB Devices

Create own applications on top of these APIs

Conclusion

Networking in Windows Virtual PC

Fig 1: Setting Dialog box to configure VM network adapters.

Network Connection Options in Windows Virtual PC

Fig 2: WVPC network filter driver bound to the host, while using Bridge Mode.

Brief Architecture of Bridge Mode Networking in Windows Virtual PC

Fig 3: High Level Architecture of Bridge Mode Networking

In Closing

Various File Types for Virtual Machine Backup in Windows Virtual PC

File Types

File extension

Description

Should back up?

How to backup a virtual machine

Illustration with Windows XP Mode VM

Figure 1. Specifying the Hard Disk location in Windows XP Mode Settings UI

How to restore a backed up VM

Virtual Hard Disks (VHDs) in Windows Virtual PC

What are VHDs?

Types of VHDs

Figure 1. Two VMs on a single host with their Differencing disks sharing the same Base disk

Using VHDs

VHDs and Windows XP Mode

Figure 2. Different VMs sharing the same parent VHD in Windows® XP Mode

Using Scripting API for Advanced Operations in Windows Virtual PC

Deleting a Virtual Machine completely

Moving the parent of a VM’s hard disk to some other location

Disabling Time Sync between the host and guest

In closing…

Auto-Start and Close Options for Windows Virtual PC

Once a VM is created, it can be started in Desktop mode from the Windows® Virtual PC Center. However Windows® XP Mode VM can be directly started from the Start Menu.

Figure 1: Windows® Virtual PC Center to create or launch a VM

Figure 2(a): WVPC Settings to change Auto-Enable Integration Features Figure 2(b): Manually disabling Integration Features

Script #1: Disable Integration Features at Start-up

Starting a headless VM

Script #2: Starting a VM in Headless Mode

Auto Start a VM

Auto Start a Virtual Application:

Auto Start VM in Headless mode

Figure 3: Set a Virtual Application to Auto-Start

Auto Start VM in Desktop Mode

Figure 4: Set VM to Auto-Start in Desktop Mode

Close a VM

Figure 5: Close VM options.

Figure 6: Default close VM setting for XP Mode

Script #3: Enable prompt while closing the VM

‘Never Hibernate’ VM Setting

Script #4: Set VM to Never Hibernate

Conclusion

Tip: Using the keyboard to access useful functionality in Windows Virtual PC