OVF vs OVA the saga continues

It has been over two years since I began working with the OVF standard from the DMTF.

Repeatedly during this process I have had to educate folks about what an OVF package is, and quite frequently what an OVA is and when to use it.  Just yesterday I corrected a person in a conference call as this is still a relatively new thing to most folks.

In very simple terms, an OVA is a single file.  It is a TAR archive of an OVF.  It simply has the file extension “.ova” to give some indication that it is an OVF.  Otherwise it would be just any other “.tar”

The OVF is the real important part that the DMTF keeps defining and expanding upon.

The OVF package is basically two things. 

1. It is an XML file that describes the virtual environment (vCPU, vRAM, vNetwork config, and it lists references to any other parts of the OVF package).
2. It is a collection of files.  Virtual disks of virtual machines, .ISO installation media, any other file attachments that a person could dream up.

Use OVA when you need to take an OVF package somewhere.  Or want to give it to someone as a download.

Use an OVF for all of your internal purposes.

Is OVF a promise that an appliance can be imported to and run on any hypervisor?  Absolutely not.

OVF is NOT a way to convert workload from one platform to another – no reason why it could not be used that way (it makes sense) – but that is not why it exists.  Eventually I see companies implement conversions around OVF packages.  The closest thing I know of today is the “fixup” that is in the Citrix Kensho implementation.

There are two reasons why:  The OS installed in the VM and its built in driver support and that different hypervisors present virtual hardware in different ways. 

To a lesser extent there is a third reason: proprietary VM tools.  The tools from vendor A can prevent a VM from running on a different hypervisor (or at least make it really difficult) or they can cause the performance of the VM to be very poor on the new hypervisor.

So, the moral of the story:  Use OVA appropriately and don’t expect an OVF package build on one hypervisor to “just work” on a different hypervisor.  And be wary of VM tools installed within the VM.

PowerShell DateTime to CIM_DateTime

Obviously no one that is using PowerShell is using WSMAN against a remote Linux system.  Everything assumes WMI, simple enough.

Use WSMAN against Linux and you enter into a insane land of XML and properly formatting your XML.

Take for example the simple act to send an XML string that queries a time period.

In PowerShell you type Get-Date and you get a nice, human friendly value back: Wednesday, May 05, 2010 10:24:14 AM

Now, try to send that to a CIM provider of any type (in my case a CIM provider that sits behind a WSMAN interface) and you immediately get a value invalid error.

off to Bing-land.. searching, searching, searching – absolutely nothing.  Wait, there are a couple useful things…

on MSDN the Scripting API Objects, the SWbemDateTime Object.  The what?  you say.  Isn’t it obvious? (I didn’t think so).

Here is the kicker, the CIM_DateTime format.  It expects this really strange format that looks like this:  yyyymmddHHMMSS.mmmmmmsUUU

So how do I take this:  Wednesday, May 05, 2010 10:24:14 AM and turn it into this: 20100505102415.000000-420

I have to play with objects in PowerShell, here is my script part:

$startTimeWindow = ((Get-Date) - $9Minutes)
$objScriptTime = New-Object -ComObject WbemScripting.SWbemDateTime
$objScriptTime.SetVarDate($startTimeWindow)
$startTime = $objScriptTime.Value

I first set my time window to begin 9 minutes before ‘now’.  I then create a SWbemDateTime object from the Wbem.Scripting class.  I then take the start of my time window and set this friendly formatted time to the object.  Then I retrieve the value of the object and I have a CIM_DateTime to send off to my Linux system CIM interface (through WSMAN).

Creating a Windows 7 or Server 2008 R2 image for VM deployment

Creating a Windows 7 image for deployment to a virtual machine is not as straightforward as you might think. If you simply perform a standard installation, image that to a WIM with ImageX and then attempt to deploy that image, you will be left with a system that requires that the boot manager be recreated.

Just in case anyone is confused as to why the boot partition is there, it's so that you can use bitlocker to encrypt your system drive on the fly.  Bitlocker needs the unencrypted boot partition to work.

If you create a VM and insert your Windows 7 media and proceed to click Next through the entire installation wizard you will end up with a system that is actually installed on two partitions and not deployed back from WIM without requiring repair.

One tool that can be used is the Wim2Vhd tool. This is useful if you meet the client requirements and have a way to import the resulting VHD into a new VM. It performs the required repair for you.

However, I would like to avoid the situation of needing to perform the BCDBoot repair all together.

Say that you want to use ImageX (from the Windows Automated Installation Kit ) to image the Windows 7 installation to a WIM and then deploy that Windows 7 image to other virtual systems. I do not want to repair each and every time – I want to build the reference system in a way that this is not required.

The key is to prevent the default Windows 7 installation behavior of creating a System Reserved partition (which contains the necessary boot loader files) and a separate partition where the OS is installed (where there are no boot loader files).

Method One – pre-partition the virtual disk:

This is the most direct approach; in the end nothing looks unusual.

1. Create the VM from a template

2. Boot to WinPE (or mount the disk to another (helper) VM)

(An alternative to this is to boot using the installation media.  At the "Install Windows" screen (the first screen of the installer) type Shift+F10 to open a command prompt)

3. Run diskpart

a. List disk

b. Select the disk

c. Create a primary partition (you must use the entire volume)

d. Make the partition Active

e. Format the volume

f. Exit

4. Power off the VM ( or detach the virtual disk from the helper vm)

5. Attach the Windows 7 installation ISO

6. Boot to the ISO

7. Begin the installation wizard

8. Select a “Custom” installation

9. At the “Where do you want to install Windows” screen accept the volume that was previously formatted

10. Complete the wizard

11. Apply all installations and patches to your VM

12. Prepare your VM with sysprep

13. Boot the VM to WinPE

14. Create your VM image using ImageX.

Method Two – confuse the installation wizard:

I could not think of a better title for this, because really what you are doing is messing with the options allowed in the installation wizard until you get the behavior you want.

1. Create the VM from a template

2. Attach the Windows 7 installation ISO

3. Boot to the ISO

4. Begin the installation wizard

5. Select a “Custom” installation

6. At the “Where do you want to install Windows” screen

a. Select the virtual disk

b. Select “Drive options (advanced)”

c. Select “New”

d. The default should be the entire volume – Select “Apply”

e. Acknowledge the warning

f. Select and Delete Partition 2

g. Acknowledge the warning

h. Select and Extend the System Reserved partition

i. The default should be the entire volume – Select “Apply”

j. Acknowledge the warning

k. Select Next

7. Complete the wizard

8. Apply all installations and patches to your VM

9. Prepare your VM with sysprep

10. Boot the VM to WinPE

11. Create your VM image using ImageX.

The primary difference between the results of the two methods is:

· Method Two results in a deployed image where the C: volume name is “System Reserved”

Method One:	Method Two:

BOOTMGR is missing - Repairing a Windows 7 or 2008 R2 image after VM deployment

Deploying a Windows 7 image to a virtual machine is not as straightforward as you might think.
The primary issue resides in how the reference Windows 7 system is installed.
If you create a VM and insert your Windows 7 media and proceed to click Next through the entire installation wizard, you will have a working Windows 7 installation, that can be templated, it can be copied, you can do just about anything you like to it – as long as all copies involve the entire virtual disk.
Say that you want to use ImageX to image the Windows 7 installation and then deploy that Windows 7 image to other virtual systems.
If all that you did was click Next through the installation wizard or you did not customize your unattend.xml at all – you actually have a VM that has been installed with two volumes – a System Reserved volume and the volume where the actual system is installed.
The standard process is that you boot your system into the WinPE environment and you use ImageX /capture to create a WIM from a particular volume. Note the word “volume.” ImageX is a volume based tool, not a disk based tool.
The problem comes when we try to deploy this image. We boot into ImageX and /apply – then we reboot the virtual machine and we end up with the error: “BOOTMGR is missing”

The boot manager resides on the System Reserved volume, that is the extra partition that is created but was not captured by ImageX.
According to Microsoft TechNet documentation How to Perform Common Deployment Tasks with Virtual Hard Disks we need to use BCDBoot.exe to “configure the boot entry in the BCD store to be on the volume inside the VHD.” If you follow the link, the portion that we are concerned with is: “Prepare a VHD image to boot inside a virtual machine.”
To repair the VM where the image we need some type of recovery environment. We can get to a prompt to fix the applied image by any of the following ways: Boot to a WinPE 3.0 ISO, Boot to a Recovery Console using the OS installation media, attach the virtual disk to another known working Windows virtual machine.
For my example I have used the Windows Automated Installation Kit and created a WinPE 3 ISO. However, in testing I first simply attached the failing virtual disk to a working VM and performed the same commands. I also found references that booting into the Recovery Console of the installation media also works, but I did not test this. It is important to note that if you use WinPE the bit-ness of your WinPE image must match the bit-ness of the OS in the VM (32-bit to 32-bit / 64-bit to 64-bit).
The repair process:
1. Boot the virtual machine into WinPE (or attach the virtual disk to a running VM).

(An alternative to this is to boot using the installation media.  At the "Install Windows" screen (the first screen of the installer) type Shift+F10 to open a command prompt)

2. Discover the drive letter assigned to the virtual disk that is failing to boot.

3. Execute the following command (pay attention to use the correct drive letter – in my example “C:” is the letter that was assigned to the virtual disk, the WinPE system volume is “X:”).
C:\windows\system32\bcdboot C:\windows /s C:

4. Simply type “exit” to cause WinPE to shutdown and reboot into the VM. If the virtual disk was mounted in another VM, then power off the VM and detach the virtual disk before booting the imported VM.

WireShark broke XP Mode

I know right now, that Ben Armstrong over at MSFT is reading this post and I have no idea what he is thinking to himself except I am sure that it is something along the line of - “no, it didn’t”  [but I made him look  ;-)  ]

And, technically, he is right, it really didn’t but the initial perception is that it did.

Okay, the background – XP Mode is the new Win7 feature which is actually the new VPC 7 (VirtualPC 7 – not VirtualPC 2007) with a pre-built Windows XP VM (that you have a legal license for as long as you run it in this intended way).

That means that there is a virtualization engine running on your system, one that interacts with your processor, one that takes RAM, and one that owns (PWNs - http://en.wikipedia.org/wiki/Pwn) your networking stack.

And it is actually some interesting side behavior that caused me installing WireShark on Win7 to break the networking in my XP Mode VM.

When an XP Mode application is closed – it really isn’t.  When an XP Mode Desktop is closed – it really isn’t.  The XP Mode operating system is simply put into a paused / saved state by VPC – kind of like hibernation.

The side effect is that the OS in the XP Mode VM is rarely rebooted or cleanly shut down (as we all know that XP likes to be).  So if things change we are in the automatic thinking of reboot.  that takes a bit more.

Anyway, back to networking and desktop virtualization engines.

What happened is that in the act of installing WireShark – I moved the networking stack away from VPC7 – thus my XP Mode VM can no longer connect through the virtual networking layer that I had it configured to use.

Yes, I installed WireShark (it added WinPCap) and I used it and went along my merry way.  All was fine until the next morning.  I maximized my XP Mode application (which was running along happily in the background the entire time, during the installation of WireShark and all) and boom, it cannot connect to its back-end server.

Hmm, I open the full XP Mode desktop – IE cannot get out either.

Well darn, I know I need to reboot my Win7 machine (I really know that is what I have to do).  But, first I try the futile hope of shutting down and restarting the XP Mode VM.  Futile yes, and a waste of my time.  The result was as expected, not networking love for my XP Mode VM.

So, I try to logon to my XP Mode VM as the local administrator – hmm… no love, I try a second time - I get an error that the system is busy with an existing Terminal Server session.  Okay, I bet it is tearing down my previous logon attempt and resetting the listener in the VM.

But, I can’t log in to the silly VM to shut it down and I need it powered off.

Time to “Disable Integration Features” – Now, I can logon as the local administrator of the XP Mode VM.

…time passes…  That was NOT fun.  I had to attempt to logon to the XP Mode VM multiple (4) times, each time I did the VM went straight into the mode of installing updates and shutting down.

Mind you, I have been working on PowerShell and WSMAN for the past few weeks.  I have all kinds of IE Tabs and windows open, documents, PowerShell Plus, etc.  I really don’t want to reboot – but I run Visual Studio in my XP Mode VM (I hate all the baggage that Visual Studio installs in my client – not good for testing).

In the end, yes the reboot of the entire system solved the problem.

The moral of the story – If you have a virtualization engine and you mess with the networking stack, plan to reboot, you will be broken until you do.