Paravirtulization under the hood and more

For those of you that are hard core virtualization folks, there is an excellent couple of articles over at xen.org by George Dunlap from Citrix.

In the ESX world and Hyper-V world the virtualization is closer to the HVM type or PVHVM when the OS is enlightened.  Xen has grown from a different root and started from the paravirutalization world (true PV, it is actually kind of interesting how the VMs themselves boot in this world).

This also gives a bit of background into the terminology and options that are available.

There is a part 1: http://blog.xen.org/index.php/2012/10/23/the-paravirtualization-spectrum-part-1-the-ends-of-the-spectrum/

and part 2: http://blog.xen.org/index.php/2012/10/31/the-paravirtualization-spectrum-part-2-from-poles-to-a-spectrum/

Personally, I think it good reading for anyone working with machines as it is a history of evolution in one aspect.

At this same time we have MSFT Research working on the Library OS.  This is an interesting abstraction of applications into VM type containers, application containers.  This is more similar to the traditional Xen PV model, where (technically) there isn’t a boot kernel in there, just the runtime components of the machine and the bootstrap comes from the xen hypervisor itself.  (at least that is my impression of it).

The MSFT research project known as Drawbridge: http://research.microsoft.com/en-us/projects/drawbridge/

And a bit more: http://research.microsoft.com/apps/pubs/default.aspx?id=141071

And a Channel9 presentation for the short attention spans among us:  http://channel9.msdn.com/Shows/Going+Deep/Drawbridge-An-Experimental-Library-Operating-System

Other MSFT Research OS projects: http://research.microsoft.com/en-us/groups/os/

Is this the future?  the Application level virtualization that was discussed many years ago.  Decoupling the application from the OS?  Not really the decoupling, but the forcing of an application into a container.  A container that it cannot get out of and affect other applications.

I look at this and think about traditional application compatibility issues going away, true application throttling, true isolation of a session (and its applications) within a Terminal Server.  That is what really makes me think about where this is all headed.  And we continue to be just at the beginning of it all.

Importing the XenApp EVA is really this easy.

I’m going to import the XenApp 6 Evaluation Virtual Appliance into Citrix XenServer 5.6 using a new feature of XenServer 5.6 and XenCenter 5.6 called the Disk Image Import Wizard.

You can also watch this in action here: http://www.citrix.com/tv/#videos/2368

I will assume that you have already downloaded and installed XenServer 5.6 and XenCenter 5.6.

First, go to the download website for the Citrix XenApp EVA. http://www.Citrix.com/tryxenapp

A login with a MyCitrix user account is required. Be sure to download two items: the Getting Started Guide and the Evaluation Virtual Appliance package for XenApp 6.

After downloading the Evaluation Virtual Appliance, execute the CitrixXA6EVA.exe to expand the self extracting archive into a folder that contains a VHD and licensing documents.

Now, open (and read) the getting started guide. The import wizard requires some important information regarding the configuration of the virtual machine. On page four, the guide states that the EVA requires at least 2GB of RAM and the VHD requires at least 30GB of storage space. So make sure that your XenServer has a Storage Repository with at least 30GB of available space.

Open XenCenter and connect to a XenServer 5.6 host (using version 5.6 is required). In the left hand tree view select the host and then right click for the context menu and choose the Disk Image Import.

In the import wizard browse to and select the VHD and choose next.

Enter the information for the virtual machine. The VM needs a name, the number of virtual processors to assign and an amount of memory.

Note: I am unselecting the Run Operating System Fixups option because I know that this VM contains Server 2008 R2 and that it was built for Hyper-V. Server 2008 R2 can handle hardware changes pretty well (single to multiple processors, critical boot devices, etc.). XenServer also presents a critical boot device controller similar to the Hyper-V IDE specific boot device.

Then begin the import.

Once the import completes, select done.

At this time: power on the virtual machine and login at the logon screen. The domain and user account and password are in the Getting Started Guide.

If the screen of the VM flickers, Windows Server 2008 R2 is busy setting up some of the new hardware devices that it is detecting. You should still be able to login and complete the setup of the Evaluation Virtual Appliance environment.

If you would like to optimize the virtual machine for XenServer, install the XenServer tools within the virtual machine.

There is no “smoke and mirrors” involved here, it is literally this easy using the Disk Image Import wizard.

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.

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.

Enabling Citrix Merchandising Server paravirtualized vm to run on Hyper-V

Be warned, Citrix Support will not support your Merchandising Server if you follow these steps.

And - this is really antique and no longer works with Hyper-V 2012.

Here is my scenario:

I have a fully paravirtualized Linux virtual machine (Merchandising Server) that is made to run on a xen hypervisor (the family of hypervisors that enable Linux VMs to boot kernel-xen and run in a truly paravirtualized and highly efficient way).
I want to move that vm over to another hypervisor (non-xen) for a client demonstration.
Warning:  This might seem a bit convoluted, but it really isn’t difficult.  However there are a few tools involved.  The steps that apply to your situation all depends on how easy it is to get your virtual disk into a format that you can mount and edit the boot volume.  Follow these instructions at your own risk, a positive outcome is not guaranteed.  The resulting VM will most likely not be supported if it has problems.
Collecting the elements:
I am going to use a few things that I need to obtain (download) and tools that need to be installed.

• The Citrix Merchandising Server Virtual Appliance
• The Hyper-V Linux Integration Components ISO (v1, not R2)
  
  • Try this if the above is dead.
• Citrix Project Kensho OFT Tool
• Citrix XenConvert
• Some Linux distribution “Live CD” (i use Debian Live)
• A Hyper-V Host

Why so many tools?

The Merchandising Server is the appliance that I am using for the example.  XenConvert is to convert the XVA (XenServer export format) into an OVF based appliance.  The Kensho OVF Tool is to import the OVF into Hyper-V.  The Linux distribution “Live CD” is to mount the virtual disk of the example appliance so we can modify the Grub boot loader and drop a file.  And the v1 Linux Integration Components have the magic PV kernel shim that we need.

Details, details, missing details.  What gives?

I am going to state right now that; I am not going to go into deep and gory details describing each and every click that is required with each tool.  If you read my blog, I assume a couple things: that you have a clue, or you want one.  And that you are not afraid of figuring things out, or trying and failing (I am also implying that you know how to make back-ups of things before you go mucking them up).

The business at hand:

1. Expand the Merchandizing bz2 zip archive. (WinRAR can do this, and others as well)
2. Use Citrix XenConvert 2.x to convert from “Xen Virtual Appliance” to “Open Virtualization Format (OVF) Package”
   
   • Do not create an OVA, just an OVF.
3. Use Citrix Kensho OVF Tool to Import the OVF Package from step 2 to a Hyper-V host.
   
   • Or you could just copy the VHD from step 2 to your Hyper-V host and create a new VM.
   • Do not boot the VM at this time.
4. Attach the Live CD ISO to the VM
5. Set the boot order to boot from DVD first
6. Remove the default Network Adapter and add a Legacy Network Adapter
7. Add a second DVD drive
8. Attach the Hyper-V (v1) Linux IC ISO to the second DVD drive of the VM
9. Boot the VM into the Live CD and log in to its console
   
   • Debian will auto logon as ‘user’.
10. switch to root:  sudo –i
    
    • This is specific to Debian Live
11. Discover the IDE disks:
    
    • cd /dev
    • ls hd*
12. Mount the virtual disk (the vhd)
    
    • make a mount point folder:  mkdir /mnt/mine
    • mount the disk to the folder:  mount /dev/hda1 /mnt/mine
13. explore the volume
    
    • cd /mnt/mine
    • ls
    • Mine looks like a /boot volume:
    • 
14. Mount the Linux IC DVD drive (mine is the second dvd on controller 2):
    
    • mkdir /mnt/cdrom
    • mount /dev/hdd /mnt/cdrom
15. Copy the kernel shims from the ISO to the virtual disk
    
    • cd /mnt/cdrom/shim
    • cp *.* /mnt/mine
16. Edit the device.map
    
    • cd /mnt/mine/grub
    • nano device.map
    • Before:
    • After:
17. Edit the GRUB bootloader to load the shim and the kernel.
    
    1. nano menu.lst
    2. comment the ‘hiddenmenu’ option and increase the timeout so I can test.
       
       • 
    3. Create a new entry specific to the shim and the distribution kernel-xen
       
       • Notice that the kernel is the shim copied from the previous step and the existing kernel and initrd load as modules of the shim.
       • 
    4. Modify the default selection to point to my new entry.
       
       • The default entry begins counting at “0”
       • 
18. Unmount the virtual disk and the cdrom
    
    • cd /
    • umount /dev/hda1
    • umount /dev/hdd
19. Shutdown the virtual machine and remove the ISOs from the DVD drive (also remove the second virtual dvd drive).
20. Boot the virtual machine, note the new menu selection that was created – this is the kernel that should boot.
    
    • 

Note: If you run VMware – This will not run on VMware, the shim is specific to Hyper-V.

XenConvert 2.0.1 is released with VMware OVF compatibility

We have been working on adding Citrix Project Kensho OVF capabilities to XenConvert.

XenConvert is the free Citrix machine conversion utility.  It is primarily focused on converting workloads to either Provisioning Server or to XenServer, however there are some more generic functions that are of interest to most any virtualization folk.

The download can be found here:

http://www.citrix.com/English/ss/downloads/details.asp?downloadId=1855017&productId=683148

If this moves in the future go here: http://www.citrix.com/English/ss/downloads/results.asp?productID=683148 and look for XenConvert in the XenServer download section.

OVF packages from any existing VMware product (known to this date) can be consumed (imported) direct to XenServer.

The physical to OVF path can be run within a Windows machine and convert it to an OVF (meta file + .vhd) or just a vhd.

The OVF can then be consumed to XenServer with XenConvert 2 or to XenServer and / or Hyper-V in the upcoming Kensho refresh.

The VHD can, of course, be copied to any engine that uses vhd.

It also does a binary conversion of vmdk to vhd and injects a critical boot device driver that is compatible with XenServer (and works with Hyper-V).

Also, the XenServer .xva (vm backup files) can be converted to OVF.

Download and enjoy!

The OVF and OVA dilemma

Here is a really good definition that I can thank my manager for of “OVF”:

OVF is a vendor- and platform-independent format to describe virtual machine metadata and create portable virtual-machine packages. These packages do not rely on a specific host platform, virtualization platform, or guest operating system. However, the virtual disk referenced by the OVF package must be compatible with the target hypervisor.

The Open Virtualization Format is a new and developing standard from the DMTF (Distributed Management Task Force). Its purpose is to form a common framework that any virtualization vendor can use to define a virtual workload. This workload can be simply a single virtual machine; this workload could also contain many virtual machines and also include complex descriptions for networking, applications, EULAs, and other entities. In theory, a single OVF could define all of the workloads within an entire enterprise and those workloads could be transported to a remote site for DR, or moved to a new datacenter. The possibilities are many.

The standard is here: http://www.dmtf.org/initiatives/vman_initiative/OVF_Tech_Note_Digital.pdf

The concept seems simple enough.

When talking to IT Professionals there is always time spent describing OVF and OVA, and where each fits.

“OVF” is the acronym for the standard.

What is referred to as an “OVF Package” is the collection of the workload states, plus a description meta file, plus any other entities that are defined in the description file.

BTW – the description file is also called the OVF file, or OVF meta file or OVF descriptor. This is why this gets really confusing really fast.

Here are the two important terms that get thrown around:

OVF / OVA – these are not the same thing.

An OVF is a collection of items in a single folder. Most commonly this is a description file (*.ovf) a manifest file (*.mf), and virtual machine state files (*.vhd or *.vmdk)

An OVA is a single file. The OVA is the OVF folder contents all zipped into a single file. The purpose of the OVA is when you want to take an OVF and share it, or give it as a download. The OVA needs to be opened into the OVF before it can be consumed.

Currently there are a host of folks working on OVF, you can learn more about the companies involved at the web site: http://www.dmtf.org/initiatives/vman_initiative/

Most commonly folks are running into OVF with Citrix (Project Kensho and XenConvert 2); VMware (VMware Workstation 6.5, Virtual Center 3 update 3, OvfTool, etc.); Sun (Virtual Box 2.2); and IBM. The big problem to date has been that the standards have been evolving during the time that these tools have been available. For example: a VMware v3 produced OVF is distinctly different than a VMware v4 OVF package. Mainly due to the state of the standards at the time the software was written. So, currently there is little cross platform between vendors.

The other problem that is happening right now is that defining a workload in an OVF is great, however, since these are virtual machine based – the operating system within the virtual machine has to deal with the fact that the virtualization hardware underneath it has been modified. Having a virtual machine as an OVF is not the same as having a virtual machine and running it through a conversion engine that repairs the operating system within the vm.

This is all evolving and will come in time.

Virtual Machine Interoperability with Hyper-V and XenServer using OVF

Okay, I know this will sound a bit like marketing hype, but I hope to keep that to a dull roar.

For the past few months I have been involved with a virtual machine interoperability project called: "Project Kensho"

Project Kensho uses virtualization interoperability standards that are currently being developed by the DMTF (Distributed Management Task Force - the people who are bringing us lots of things such as CIM and DMI) to provide a framework for all of the virtualization vendors to use to talk the same language.

You can check the whole thing out here:
http://community.citrix.com/display/xs/Kensho

And..you won't see a bunch of screen shots, because I already did those (they are at the link above)

What does this mean to the administrator that is in the grind all day long?

You can take a VM and move it from one virtualization host to another.

You can export an entire enterprise application environment (some complex application that needs SQL, IIS, Active Directory - and those components must run on individual machines).

You can import items like these from other sources.

Here are some real world examples of what I use this for today:

Exporting a complex or large test environment.
I have an environment of 30 client virtual machines. I can export that to a package, sit on it, rebuild my hypervisor, import it back. I can also import those virtual machines to either XenServer or Hyper-V.
I also have an environment of 4 servers (the virtual disks are 36 Gb each) - but I can export and store and then import and use.

It actually ends up making my life a bit easier.

Go ahead, check it out.