Robert Larson

Installing Zune 3.1 on Windows Server 2008 x64

Ok you are probably wondering why you would ever need Zune software on your Windows Server 2008 x64 machine….well if you are like me, my primary machine is my notebook and I run Windows Server 2008 x64 so I can have Hyper-V.

Anyway, Microsoft released a new version of the Zune software the other day and I wanted to install the latest version on my machine.  Good – there is a native 64-bit version of Zune. Bad - the Zune installer blocks on Windows Server 2008 x64.

So how do you get around this issue?  You can extract the installation package and install by hand…..that gets around the installation block on OS version, but there is a catch, you MUST install as the local administrator. No you cannot install with an account that is a member of the local administrators group.

Here is the process

1) Download the Zune 3.1 package from here.  It is a 300+ MB package

2) Open a command prompt and launch the downloaded package with the /x option to extract it versus launch the installation.

ZUNEPACKAGE31.exe /x

3) Specify a folder to extract to, I used C:\TEMP\ZUNE31 as the directory

4) Go to C:\TEMP\ZUNE31\x64\PACKAGES

5) Right Click the ZUNE_X64.MSI and select Install

6) Answer the questions and it will install

Now go enjoy the music!

Go to 8GB on your notebook for ~$350

Some vendors have started shipping DDR2-5300 memory that provides 667Mhz 4GB SODIMMs for you notebook.  You will need a notebook that has a SantaRosa chipset to be able to access all 8GB and even then the BIOS has to support it.

I personally purchased 8GB G.Skill memory from newegg.com for $170 per chip.  I have tested the memory in a Lenovo T61P and a Dell Latitude 830 with no issues.  I did have an issue with a Dell Inspiron 1420.  It does not recognize both 4GB chips when installed and does not finish the boot process.  It does support a 4GB and a 2GB module for 6GB RAM.

So for about $350 you can upgrade your compatible notebook to 8GB RAM.

Hope this helps you run more VMs on your notebook.  :-)

Installing Updates on Server Core

I love Windows Server 2008 installed with Server Core. It’s small footprint (although it could be even smaller), simplistic command line UI, and the boot speed.  One thing I dislike (until recently) is installing updates on Server Core. Well I found a nice little sample script that works beautifully to check and install all available updates from the command line

http://msdn.microsoft.com/en-us/library/aa387102(VS.85).aspx

This is a VBScript  that uses the built in Windows Update Agent (WUA) to check for all available updates, provide you a list, and allow you to select to download and install the updates on your machine.

This makes updating a Server Core image a breeze.

Enjoy.

Additional NIC for your Laptop and Hyper-V

If you are like me and use Windows Server 2008 and Hyper-V on your laptop, you have possibly found out that Hyper-V does not support wireless adapters. This is an issue with the Wireless spec no Hyper-V.  You can use ICS or bridging to get it to work, but having a 2nd wired network adapter can be helpful in some situations.

What you need is a USB NIC that can be quickly added to your machine when you need it.  I have been searching an have bought some adapters from local computer stores to find none that have x64 drivers.

Well another MS consultant told me about an adapter that his friend uses with Hyper-V.  I bought one and found some drivers that work

These two adapters work with Vista x64 and Windows Server 2008 x64 if you use the Vista x64 drivers from the chipset manufacturer.

http://www.airlink101.com/products/agigausb.php - 1 Gb version (AS88718)

http://www.airlink101.com/products/asohousb.php - 100 Mb version (AS88772)

Use drivers from chipset mfgr http://www.asix.com.tw

TrendNet also makes a 10/100 USB adapter that has x64 Vista drivers.

http://trendnet.com/products/proddetail.asp?prod=150_TU2-ET100&cat=49

Their gigabit adapter might also have drivers, but I have not investigated it to find out.

So if you find yourself in need of another wired NIC on your notebook running x64, then you have options….doesn’t everyone do clustering on their notebooks :-)

BTW, Fry’s carries the 10/100Mb AirLink101 adapter and it is on sale right now for $2.99 in stores.

Getting UNDO functionality with Hyper-V Snapshots

Snapshots are not the same as UNDO disks in Virtual Server 2005…go here to read a previous post of mine to learn about how they work.

That said, you get UNDO like functionality using snapshots…..with maybe a little more work.

In Virtual Server, when you wanted to use UNDO, you powered down your VM and enabled UNDO on the Virtual hard disk tab. Then after you power on the VM, when you powered it off you will be asked if you want to Save, Commit, or Discard your changes. Selecting Save kept the changes separate, Commit merged them into the original VHD and then started the UNDO process over again, and Discard threw away the changes and started over again. All of this used Differencing disks in the background.

In Hyper-V, UNDO is not an available option on the virtual disk menu anymore, you now have snapshots. If you want the ability to protect your VHD from any changes getting merged you need to do this.

Before you first power on a VM (the same point you would have enabled UNDO in Virtual Server), take a snapshot and call it something like UNDO DISCARD. This just makes your VHD effectively read only and all changes are written to a working AVHD file.

Power on your VM and work away.  When you want to effectively “Turn OFF and Discard” all changes, then apply/revert to the UNDO DISCARD snapshot and it is all gone…start a new test scenario. Just remember that if you made any changes to the VM settings, they are also discarded.

By default all changes are saved to the working file, so you need to do nothing to get the SAVE feature.

If you want a COMMIT capability and want it permanent like it is with Virtual Server, then that takes a little more work.   Once you create the UNDO DISCARD snapshot, there is no way to merge any changes back to the original VHD through the snapshot UI. 

You can do the following though to get the COMMIT functionality

1. Power down the VM
2. Find the working avhd file
3. Copy it to CHILD.VHD
4. Backup up your original VHD for protection
5. Use the Edit disk option in Hyper-V MMC to edit the new CHILD.VHD and select Merge for the action in the wizard
6. Select to Merge to the parent
7. Wait for the merge to complete
8. Apply the UNDO DISCARD Snapshot (which throws away all the changes which you just merged from the copy and creates a new working avhd file that is the child of the original VHD)
9. Power on the VM and work away

Once again remember that if you had made any changes to the VM settings, that applying the UNDO DISCARD snapshot would have thrown them away…..other than that have fun!!

Let me know if you have any issues...

Entering Product Keys into Virtual Machines

I create virtual machines every day.  I have a set of product keys that I use from my MSDN subscription and I hate playing the visual copy typing game (ok I am a lousy typist). It turns out that I had overlooked a nice little feature in VMConnect that makes this VERY easy.

If you open up VMConnect console to a virtual machine, you will see an option on the menu called Clipboard. The first option is Type Clipboard Text. This nice little time saver allows you to highlight a string of text on the host and then have it pasted into the VM at the current cursor position.

To copy a product ID into a setup dialog, copy the product ID and the hyphens from a notepad file or other location on the host, place your cursor within the borders of the VM (or click inside the VM if you do not have integration components loaded), click into the product ID box, and press CTRL-V. The feature types the contents of the clipboard text.

Short, simple, easy to use.

Virtual Machine Snapshots with Hyper-V

Snapshots are a new feature of Windows Server 2008 Hyper-V. Snapshots are a point in time version of a virtual machine…..what does that mean you ask? It means that you can be running a virtual machine, take a snapshot and at any point you can select a previous snapshot and revert back to that point in time.  You end up with the virtual machine in the EXACT configuration that it was when you took the snapshot…and I mean exact….memory, virtual hardware, processes, state, etc. So you can have a running virtual machine, take a snapshot, change the virtual hardware configuration, format the disk and install a different OS, it does not matter, when you apply the previous snapshot it looks exactly like it did when you took the snapshot.

Snapshots do not affect the running state of the virtual machine, meaning that taking a snapshot does not change the virtual machine hardware, applications, or the currently running processes. It also means that deleting a snapshot does not change the virtual machine either….it just means that you cannot go OOPS and go back to that point in time to get you out of something you just did.

The snapshot files consist of the following:

• A copy of the VM configuration .xml file
• Any save state files
• A differencing disk(.avhd) that is the new working disk for all writes that is the child of the working disk prior to the snapshot.

If you create snapshots one right after each other and never apply a previous snapshot, the you will have a tree with one branch. if you apply a previous snapshot, then you will get another branch to the snapshot tree starting at the applied snapshot.

Creating Snapshots – How does it work?

When you create a new VM in a directory, let’s say D:\TestVM, two sub directories are created – D:\TestVM\Snapshots and D:\TestVM\Virtual Machines. The \Snapshots directory contains nothing, but the \Virtual Machines directory contains the original XML configuration file saved with a unique GUID as the filename with an .xml extension and a directory to house the save state files (.VSV and .bin) memory files. The directory also uses the same GUID as the directory name. I will refer to this as the VMGUID.

Note: All the filenames and directories are actual GUIDs, I am using friendly names to make it easier to write and understand the concept.

The VMGUID.XML file points to the D:\TESTVM\TESTVM.VHD as the current VHD for all writes. Before you do any snapshots, all changes get written to the D:\TESTVM\TESTVM.VHD file and any save state is saved in the D:\TestVM\Virtual Machines\VMGUID directory.

When you create the first snapshot you have two scenarios: [1] You create it with the virtual machine powered down or [2] you create it while the virtual machine is running.

CASE [1] – VM is powered off

1. It creates two directories in the D:\TestVM\Snapshots\ folder

• One with a folder name of VMGUID – this is where all the avhd files will be stored for all snapshots (This only happens for the first snapshot)
• One with a new GUID for a folder name – this is where the memory save state for this snapshot is stored, I will refer to this as SNAPGUID
• In this case no files are written to D:\TestVM\Snapshots\SNAPGUID here because the VM is powered down and there is no memory state

1. It also creates a copy of the VM’s XML configuration file with filename SNAP1GUID.XML
2. It creates a working .avhd files with another GUID and stores it in the D:\TESTVM\Virtual Machines\VMGUID directory. I will refer to this as WORKING.AVHD
3. The VM’s original VMGUID.XML file is updated to point to the new WORKING.AVHD as current VHD

CASE [2] – VM is powered on

1. Everything that happens for CASE [1] happens for case [2] except in this case the memory is saved to disk and stored in the D:\TestVM\Snapshots\SNAPGUID folder as a BIN with the actual memory saved and a VSV with supporting process information.

Both Case [1] and [2] proceed the same from here….

From this point on, all writes are written to the WORKING.AVHD file. If you make a bunch of changes and then decide to use Revert (to go back to the point in time of the first snapshot), this is what happens

1. The WORKING.avhd file is deleted and a new one is created with a different GUID
2. The VM’s original VMGUID.XML file is updated to point to the new WORKING.AVHD as current VHD
3. If there was a save state file to load it would be loaded and the VM would be resumed from save state.
4. If there was no save state file to load, the machine would remain powered down since you took the snapshot when it as powered down.

So you make a bunch of more changes and then take another snapshot, this is what happens

1. A copy of the current VMGUID.XML files is made, placed in the SNAPSHOTS folder and given a filename with a new GUID, let’s call it SNAP2GUID.XML
2. A folder is created in the SNAPSHOTS folder using the SNAP2GUID to house the save state files for this snapshot, The VM is save stated to this folder
3. The current D:\TESSTVM\Snapshots\VMGUID\WORKING.AVHD file is now the point in time state of the VHD (the GUID does not change)
   • Its parent is the original TESTVM.VHD file
4. A new WORKING.AVHD file is created with a new GUID
   • Its parent is the old WORKING.AVHD file
5. The VMGUID.XML file is updated to the new WORKING.AVHD

So for each new snapshot in succession

1. A copy of the current VMGUID.XML is made and placed in the VMs SNAPSHOTS folder, the filename is a unique GUID
2. A new directory is created in the SNAPSHOTS folder to hold the save state files, the folder name is the same as the GUID in (a) above
3. A new avhd file is created with a new unique GUID. This becomes the new working avhd file and the existing one becomes the RO parent.
4. All new writes are made to the new working avhd file

Hope that provides you with a better understanding on what snapshots are and how they are created under the hood…..I will save deleting snapshots for a future post :-)

Robert….

Building a Host Cluster with Hyper-V Beta 1

Well by now you have heard the news that Microsoft shipped Hyper-V Beta 1 early!!

Like many of you I have been testing away and thought I would share the steps for creating a host cluster in Windows 2008 and Hyper-V. For those that have built host clusters in Virtual Server, you will find the process in Windows 2008 and Hyper-V much more streamlined and user friendly. One major improvement is the integration of Hyper-V as a cluster aware application and native support for making a virtual machine highly available.

So what are the 10 steps you have to go through to build a host cluster using iSCSI shared storage?

1) Build nodes with Hyper-V
2) Build Virtual Network Switches in Hyper-V
3) Establish iSCSI Target Quorum and Data drives
4) Use iSCSI initiator on each node to connect to targets
5) Install Failover Clustering on each node
6) Run Validate on the cluster nodes
7) Create Cluster
8) Build a VM to make highly available
9) Make the VM highly available
10) Test it by moving the VM to another node

Node1

LAN IP address = 192.168.0.170
Heartbeat IP address = 10.10.10.1

Node2

LAN IP address = 192.168.0.171
Heartbeat IP address = 10.10.10.2

Cluster IP Address = 192.168.0.181

Step 1:

Building the nodes with Windows 2008 Enterprise or Data Center edition is a simple process.  Once you have the OS installed, you need to add the Hyper-V role in Server Manager (and reboot)

Step 2:

Once you reboot and Hyper-V installation completes, you need to launch the Hyper-V management console from the Administration Tools menu on each node.

[Do this on both nodes] On the right hand side, click the Virtual Network Manager, and create a new virtual network switch. For simplicity make it a private network and call it Private. The name must be the same on both nodes.

Step 3:

Go to the iSCSI target (hardware or software based) and build two disks enabled for shared access.  One disk needs to be 500 MB or larger to hold the cluster configuration info, and other disk needs to be big enough to hold the virtual machine, say 10 GB minimum. Be sure to enable the option for shared or cluster access to the disks.

Step 4:

On NODE1 launch the iSCSI initiator software.  Discover the iSCSI target via name or IP address and then establish a connection to the Data and Quorum disks that were established in step3.

Once the disks are connected to Node1, use Disk Management to initialize and format them as NTFS volumes. Assign driver letter Q: to the small disk and a drive letter like S: to the large disk.

Now go to Node2 and use the iSCSI initiator to connect the target disks, you do not need to do anything else.

Step 5:

From Server Manager, install the feature called Failover Clustering on each node. and when done, launch the Failover Clustering Management console .

Step 6:

Verify that Node1 has current ownership of the disk resources (although either disk could have ownership) and then launch the Validate process from Node1 specifying Node1 and Node2 are the nodes of the cluster, run all tests.  If issues are identified, the validate report will provide details on what the issue(s) are and how to resolve them.

Click Validate a Configuration

Provide the names of the two nodes

Execute the validation process

Get a report back on the progress, if successful you should see all green checkmarks

Step 7:

Once you have completed a successful validate process, you can now build the cluster.  It is a four step process

1) Select Create Cluster from the Failover Cluster Management console.
2) Specify the nodes of the cluster
3) Specify the name and IP address of the cluster
4) Execute the create process

Step 8:

Using the Hyper-V Management console, create a virtual machine called TestVM on Node1 that can be made highly available.  Use Windows 2008 for the operating system.  The integration components are automatically installed for you.

Do not start TestVM, it must be in the powered off state to make it highly available.

Step 9:

Make TestVM highly available. This allows you to have a planned or unplanned migration of a VM between nodes.

Click Configure a Service or Application

Select Virtual Machine from the list of available services or applications

Select TestVM as the VM to make highly available

Execute the process

Success!!

Now bring the VM online, right click the VM in the list and select "Bring this service or application online"

Step 10:

Once it is online you can test the fail over by moving the VM to Node2.

Right-click the Application and select "Move this service or application to another node", select Node2

Watch the process

1) The VM is placed in saved state
2) The resources are moved to Node2
3) The VM is resumed from saved state

Now the VM has successfully failed from Node1 to Node2.

You have successfully built and tested a 2-node host cluster using Hyper-V.  Note that you can have up to 16 nodes in a Hyper-V host cluster.

Hope this helps you understand Hyper-V host clustering......:-)

Virtualization at IT Forum

Well I am off to Barcelona Spain again to speak at TechEd IT Forum November 12-16th. This will be an exciting show for Virtualization. System Center products will be launching and Microsoft will be making some announcements about Windows Server 2008 virtualization.

System Center products focused on virtualization:

Virtual Machine Manager 2007 - centralized management of your Virtual Server 2005 R2 SP1 pool of hosts, Physical to Virtual migration, Virtual to Virtual Migration, Self Service web portal, VM templates, provisioning, and much more....

Data Protection Manager 2007 - centralized backup to disk or tape, native support for Exchange, SQL, SharePoint, and Virtual Server, delta based backup to reduce network traffic, end user file recovery, and much more

Operations Manager 2007 - SCOM has already been launched, but at the show will be new management packs for VMM and Virtual Server

Viridian announcements - While I cannot blog about the announcements...yet, I think you will really like them. So stay tuned....

There will also be many breakout sessions on Virtualization. There will be a surprise at a couple of the sessions....we will be giving away signed copies of the Virtual Server 2005 R2 Resource Kit , so come attend for a chance to win a copy.

See you there!!

Self Service VM Management with SCVMM

One of the features of VMM that I really like is the power of the Self Service Web Portal (SSWP).  The portal provides an individual user or group of users access to a virtual machines that they own or that they create.  They can see, manage, and interact with virtual machines remotely using the VMRC ActiveX control.

You can create a portal and limit a group of users to specific actions or management capabilities. The use of the SSWP is limited only by your imagination. Here are some examples that I have thought about

1) Remote development environment for internal or outsourced developers.
2) Remote training environment, you can build a view only environment for end users so they can remotely attend a training class and watch the instructor teaching them a new skill from the instructors view-only VM, then switch over to a development VM to try it themselves.
3) Remote admin into a production environment (one you own or a hosted environment)
4) Remote test and Q/A environment
5) Remote proof of concepts for your software applications
and many more....

Enabling the SSWP for end users requires the following steps:

1) Install the Web Portal on a server (I just installed it on the VMM server for test purposes)

2) Create a Host Group and place one or more managed hosts in the host group (only the hosts in the host group are available resources for new VM creation)

3) Create a Self Service Policy (or multiple if you want different ones to apply to different VMs, View Only policy, Manage Policy, Create and Manage Policy)

4) Configure any pre-existing VMs for the policy

5) Build templates for the self services users if you are going to allow them to create virtual machines

Installing the web portal is easy and well documented, so I will not go over it again here.

Creating the host group is pretty easy also, in the VMM Admin Console, go to the Host view, then in the Actions menu on the right hand side, you will see a section called Host Groups, Click New Host Group, give it a name (I called mine SelfServe) and press OK.

Once you have the host group, you can drag and drop one or more managed hosts into the group.  Once you do that, then select the group and then in the Host Group actions, Press New Self-Service Policy.

Provide a name for the policy

Set the policies that you want to apply to the user or group of users that you selected and save the policy.

If you already have Virtual machines on the host or if you will be pre-creating the virtual machines and not allowing the users to create virtual machines on their own, then you must configure the VM properties to recognize the policy.  When you allow the users to create their own VMs, these values will be automatically set as the VM is created.

If you are creating the VMs for the user, then you must change the owner value of the VM to be owned by the user or group you selected for the policy.  Select the VM and look at it properties. In the Owner box, set the owner.

Next click the Self-Service Tab and set the policy and the quota value for the VM.

Press OK.

Now you have the host group, self-service policy, and the existing VMs all configured for the policy.

The user can now connect to the Self-Service Portal to access the VMs that they have rights to. When they go to the self service web site, they will be prompted for their credentials, then presented with the screen below. On the left hand side is the list of all the VMs they have rights.  If they select a VM, they will be presented with information on the VM and a menu of actions will be presented on the right hand side. For this VM the policy allows the user to Start, Stop, and view the properties of the VM.

As the administrator, if you go to the self service portal, you will see the same screen as a regular user. The administrator will be presented with a troubleshooting screen that allows you to help users of the portal.

Entering a user name in the box and pressing Enter will allow you to see the same interface the user sees so you can determine any issues they are having.

As you can see, setting up a Self Service Web Portal is not that complicated.

Enjoy!!

Microsoft publishes the Hypercall APIs via the Open Specification Promise

Microsoft announced today with it will be publishing the Hypercall APIs through the Open Specification Promise when Windows Server Virtualization ships. In addition they posted a draft of these interfaces in the form of a Hypervisor top-level functional specification on Microsoft downloads here. This document gives you and view of the external interfaces of the first generation hypervisor from Microsoft and contains the following information:

• Introduction
• Basic Data Types, Concepts and Notation
• Feature and Interface Discovery
• Hypercall Interface
• Partition Management
• Physical Hardware Management
• Resource Management
• Guest Physical Address Spaces
• Intercepts
• Virtual Processor Management
• Virtual Processor Execution
• Virtual MMU and Caching
• Virtual Interrupt Control
• Inter-Partition Communication
• Timers
• Message Formats
• Partition Save and Restore
• Scheduler
• Event Logging
• Guest Debugging Support
• Statistics
• Booting
• Appendix

This is really cool and gives you a detailed view of how to interface with the Microsoft hypervisor.

For more information, go to the Virtualization Product team blog entry here

Changes to Virtual Networks in Virtual Server 2005 R2 SP1

In Virtual Server 2005 R2, a virtual network operated like a hub with a switched uplink port.  Traffic on all guests plugged into the network was visible on every port of the virtual network, but that traffic was not visible to anything on the other side of the uplink port because it was switched.  The pro was that it was easy to use Network Monitor to trace what was going on the network.  The con was every guest saw every packet and extra overhead existed.

In Virtual Server 2005 R2 SP1, the virtual network was converted to a switch for all ports. This reduced the traffic that each VM saw and reduced the network overhead, but made it harder to sniff traffic between guests.

There is a solution to the problem though on a per VM basis. To enable the VM to see all the traffic, you need to enable promiscuous mode for the port. There is a setting in the VMC file called allow_promiscuous_mode that by default the value is false. 

This tag exists under the <virtual machines> node and the syntax is

<allow_promiscuous_mode type="boolean">TRUE/FALSE</allow_promiscuous_mode>

Setting the value to TRUE will enable the old behavior from R2.

You will need to do this if you want to load NetMon or other packets sniffer software in the VM and see all the traffic on the virtual network.

New bonus scripts for Virtual Server 2005 R2 Resource Kit

My co-author Janique Carbone has posted two new bonus scripts on her site http://vscommunity.com.

Both scripts have to do with finding out information about differencing disks.

GETVHDParentInfo - Allows you to specify a VHD file on the command line and the script will tell you if the VHD is a differencing disk and then walk the tree of dependencies to show you the entire hierarchy of the parent child relationship

ListDiffDisks - Allows you to point at a Virtual Server host and it will enumerate all the virtual machines and all of their VHDs, telling you which ones are differencing disks and also printing the entire hierarchy of the parent child relationship.

These are posted in the Downloads area and require you to be a registered user of the site to download them.

Enjoy....

Windows 2008 Components Posters

Previously published in the July issue of TechNet Magazine, these are two PDFs of Windows 2008: Operating System components and Active Directory components. The posters explain how they work and detail capabilities.  They are great resources to have up on your office wall (you will need a big printer though).

http://www.microsoft.com/downloads/details.aspx?FamilyID=c2b9e44e-0bbd-47cb-bc09-b3d48be7f867&DisplayLang=en

The Feature Components poster highlights the following components of the Windows Server 2008 operating system:

Terminal Services
Network Access Protection
IIS 7.0
Server Manager
Server Backup
Server Core
BitLocker
Windows Server Virtualization

The Active Directory Poster highlights the following components of Active Directory in Win2008

AD Lightweight Directory Services
AD Federation Services
AD Rights Management Services
Group Policy
AD Management
AD Read-Only Domain Controllers

These are painstakingly created by two Microsoft employees in Australia, Martin and Astrid McClean. These two have been building these posters for years and they have all been great hits, usually causing multiple re-printings.

Great job once again.....

How does the mapping from a virtual network adapter to a physical adapter work?

Adapted from Chapter 7 of the Virtual Server 2005 R2 Resource Kit book from Microsoft Press

So you are trying to figure out how a virtual machine network adapter is mapped to a physical network adapter in the host through a virtual network. Maybe you moved a virtual machine between hosts and it now gives an error about not finding XYZ virtual network and will be binding to the default virtual network.

There are three pieces to this puzzle.

1. The options.xml configuration file of the Virtual Server host contains the physical network adapters that have the Virtual Machine Network Services (VMNS) bound to them.
2. The virtual network configuration (.vnc) file has the mapping to the physical adapter
3. The virtual machine configuration file has the mapping to the virtual networks it is attached.

To trace a virtual machines mappings, open the .vmc file and look for entries for each virtual network adapter that specifies the ID of the virtual_network that the VM it is attached to. You can see by this example, that the id value is 00D67AACDFC2499DBD9222F7A0A29D54. Record this value.

<ethernet_controller id="0">
                <ethernet_card_address type="bytes">0003FF1B6AD5</ethernet_card_address>
                <id type="integer">5</id>
                <virtual_network>
                        <id type="bytes">00D67AACDFC2499DBD9222F7A0A29D54</id>
        <name type="string">Wireless</name>
                </virtual_network>

Now open up the .vnc file for the virtual network that is attached. Search for the ID that you just recorded, then write down the <gateway> value. You will need this to determine which physical adapter it is bound.

<settings>
            <gateway type="integer">22</gateway>
    <id type="bytes">00D67AACDFC2499DBD9222F7A0A29D54</id>

Now open up the options.xml file and search each virtual_gateway entry for a value of id that matches the <gateway> value from the .vnc file.

<virtual_gateway id="7">
        <adapter type="string">\DosDevices\VPCNetS2_{CA746289-F2E6-405A-B7C2-E2595ACA750A}</adapter>
        <id type="integer">22</id>
        <name type="string">Intel(R) PRO/Wireless 3945ABG Network Connection #2</name>
        <type type="integer">2</type>
    </virtual_gateway>

Now look at the name value and you know which physical adapter your virtual machine is attached!