If there were enough room, the full title for this article would actually be something more like, “Converting a Suse SLES or Opensuse Linux machine from either VMware Workstation or ESXi or to Hyper-V, even when you don’t have the VMware environment anymore…“
To give you a little background, Microsoft recently released the MVMC v2 (http://www.microsoft.com/en-us/download/details.aspx?id=42497), packed with some critical new features, including better handling of Linux VM guests. And it just so happens that I have a small handful of dev/test Linux machines lying around from a VMware lab environment that I tore down a while ago that I’d love to have in my Hyper-V lab. The problem is that I just don’t have the VMware workstation or space on my ESXi servers to bring the VMs back up and follow the standard documented procedure.
If you haven’t figured it out already, the basic problem here is that the Linux VMs (that came from the VMware environment) don’t have the Hyper-V drivers configured because they weren’t needed at installation (again, on VMware), but the Installation ISOs *do* have the drivers at the ready when booting the “rescue system”.
And while the very nice documentation provided with the converter kit (Microsoft_Virtual_Machine_Converter_Admin_Guide_2_0.docx) gets you close to knowing what you need to do, it doesn’t quite provide you with step-by step instructions, especially with the guests already downed or in an archive.
Without further ado, here’s how to convert and fix those Linux VMs. Of course, there are a few particulars here; for instance, this procedure was tested with Opensuse versions 12.2 and 12.3, and SLES 11 sp3, but should be the same for other similar versions. And it should go without saying that by following these instructions, you proceed at your own risk.
Step 1: Install MVMC2
First, the installation. Go to the MVMC2 download site, get the software, and install. I recommend doing this on a Windows 8+ or Server 2012R2 machine, for a few small niceties (like defaulting to vhdx format, etc.).
Step2: Convert the Disk
Open Powershell *as Administrator* (right-click, run as Administrator), and load the module:
Import-Module "C:Program FilesMicrosoft Virtual Machine ConverterMvmcCmdlet.psd1"
We need to create a temporary folder for our converted disk — in my case on a separate drive from where my source VMs reside, to speed things up a tad:
And then we can convert out source disk:
ConvertTo-MvmcVirtualHardDisk -SourceLiteralPath "E:Virtual MachinesOpensuse12.3Opensuse12.3.vmdk"
Next, move the newly converted disk to wherever you keep your virtual hard disks (I assume you have a designated location).
Then, create a Generation 1 Virtual Machine in Hyper-V (try to use the same name, memory settings, and so on as before), but choose to “Use an existing virtual hard disk” and set it to the newly converted hard disk. But before you start it, attach the correct installation ISO (I use the tiny “network install” ISO). Remember, it’s mandatory that you use the correct processor type ISO (32 vs. 64), and you should use the correct distro version.
Step 3: Boot and Mount the Alternate Root
Start the VM (booting from ISO), and choose “Rescue System” as the boot choice. Tip: while the splash screen is up, hit the escape key and notice the Hyper-V drivers it chose; in my case it was only hv_netvsc and hv_storvsc, but you may have others.
Once at the “Rescue” prompt, enter “root” as the login.
Now, mount the proper disk partition for your root filesystem; this may take some guessing if you don’t remember which is which. For instance, on some of my lab machines, I used /dev/sda2 as the full root filesystem. On others, I created a separate partition for /boot, so the root file system was on /dev/sda3. If you don’t know, you might have to mount a few of them and look and see what’s in them. And of course, if you have a separate /boot, you’ll have to mount that too. But for the examples that follow, we’ll assume the full root file system is all on /dev/sda2.
So mount the root filesystem under the alternate mount point, like this example:
# mount the root
mount /dev/sda2 /mnt
# you may have to mount /boot too, depending on your setup
# mount /dev/sda1 /mnt/boot
# you must re-mount the live dev and proc
mount -–rbind /dev /mnt/dev
mount -–rbind /proc /mnt/proc
# set the chroot environment
…and then we’re ready to actually do some fixing.
Step 4: Fix the Modules
(These next instructions are re-interpreted from the MVMC2 guide, courtesy Microsoft):
Use vi to edit /etc/sysconfig/kernel to include the Hyper-V modules. Sorry, there’s not enough room here to teach you how to use vi… 😉 Add the “hv_” modules to the end INITRD_MODULES line, which *may* look something like this:
INITRD_MODULES="mptspi ata_piix ata_generic vmxnet3 vmw_pvscsi vmxnet”
…or perhaps like this (this example does not have VMtools drivers):
INITRD_MODULES="mptspi ata_piix ata_generic”
…and with your change, you’re making it look more like this (again, we’re only adding the hv_ modules to the end):
INITRD_MODULES="mptspi ata_piix ata_generic vmxnet3 vmw_pvscsi vmxnet hv_vmbus hv_netvsc hv_storvsc”
And finally, recreate the initrd with something similar to the following command (this example is taken from one of my older ones). The kernel and initrd specified in the command must match your current kernel the machine boots with.
mkinitrd -k /boot/vmlinux-3.7.10-1.11-desktop.gz -i /boot/initrd-3.7.10-1.11-desktop
…and you’re done! Type “exit” to end the chroot environment, and “init 0” to shut down. Go to the settings of the VM, and detach the ISO, and boot it up.
Phew! You did it. Enjoy your Linuxy goodness…