Virtuozity

I have been working on a VM as a desktop replacement for over a year now and I am quite satisfied with the experience. This is not a full-blown VDI, it's more like my personal virtual client, which I find very convenient compared to classic desktop computers.

Anyway, today I got a new monitor with a screen resolution of 1920x1200 pixels and I realized there is a limitation to the screen resolution of VMs. Here is how you can get beyond the standards, but you have to add a few lines to the relevant VMX file:

svga.maxWidth = "1920"
svga.maxHeight = "1200"
svga.vramSize = "9216000"

Width and height are pretty obvious but you also have to increase the RAM of your virtual video adapter, otherwise it cannot display the desired resolution. Here is how you get the value for this entry:

Width (pixels) * Height (pixels) * ColorDepths (bits) / 8

In case your Windows does not show you the right results in your desktop configuration, you can do it manually by editing the registry. Use regedit and go to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Hardware Profiles\Current\System\CurrentControlSet\Control\VIDEO\{FEDC7ADF-34C8-4BAF-B872-48C92671D7D5}\0000

The adapter string might be different, but there should not be too many adapters on a VM here anyway. Now modify the following entries to suite your needs:

DefaultSettings.XResolution
DefaultSettings.YResolution
DefaultSettings.BitsPerPel

This might require a reboot to work. The new resolution will also be usable on the VMware console. Please be aware that not all RDP clients are the same, e.g. I learned that my favorite tool from visionApp has a built-in limitation of 1600 pixels width. The original Microsoft RDP client had no problems showing the larger resolution.

Today I would like to show how to virtualize a Linux system. This kind of process is most often referred to as P2V, but my approach is more generic, so at the end of the day you can use it for P2V, V2P, V2V, P2P, X2X or whatever you like...

Are you a hot or a cold guy?

The first step is to clone your existing system into the new box (e.g. a virtual machine). There are a few different ways to do this, but you have to make the famous "Hot-Or-Cold Decision": Is your server online while doing the transition? I strongly recommend the cold way but there might be scenarios where it is necessary to do it hot. Today lots of companies tell you, you will be able to do a hot P2V with their products, but the ugly truth is that I have seen them all fail on real life production systems when inaccessible files or databases are involved.

So, let's stick to the cold path and get our stuff on the new box. The easiest and most convenient way is to use the boot CD of an image solution like TrueImage, Ghost or g4l (Ghost 4 Linux), etc. Most of this breed of tools are also capable of resizing partitions on the fly. This will not work if you use LVM and is also true for dynamic disks on Windows. Remember that you can also use the boot CD of the VMware Converter to transfer your machine directly into vCenter!

But I am hard-boiled!

If these tools let you down or if you are just the tough kind of Linux guy, you can do it all by yourself, which is not too hard anyway. Start the system you want to transfer with a bootable Linux CD, e.g. Knoppix. Check if your disks are accessible, otherwise load the appropriate driver, e.g. lots of HP servers have CCISS RAID controllers which might not appear under /dev. Type the following

cd /dev
sh MAKEDEV cciss

to create the device nodes. Now you can mount them, e.g. the first partition on your first disk of your first controller would be /dev/cciss/c0d0p1.

Now we will transfer the content of our disks to the new system, so check if the network is set up properly and log in on the new system via SSH. Check if the partition layout fits your needs. Now choose your transfer method: I recommend rsync, but dd does the job as well. The advantage of dd is that you can copy data at raw level which allows to clone your "Master Boot Record (MBR)" like this:

dd if=/dev/sda count=1 bs=512 ) | dd of=/dev/sda

Of course this example above refers to standard SCSI controllers and has to be modified for RAID adapters.

OK, now we're going for rsync. Please make sure that the source is mounted on the original system and the destination is mounted on the target system! Now we send the data to the destination host. Here is an example how to synchronize your user directories for testing purposes:

rsync -avHx --delete /home/ root@destination:/home

You might want to use exclusion lists to copy the whole / directory, because you sure do not want to copy directories like /dev and /proc. The rsync approach could also be used in totally different way: You could install the same version of your Linux on your new box and rsync all the stuff you need. In this case you definitely exclude the /boot directory!

Ready to go?

Now I assume you have your Linux on the new box, one way or the other. If you did it with the VMware Converter, please check the configuration of the VM, there will probably be a lot of crappy virtual hardware you won't need. Just go ahead and delete all devices like USB, serial or parallel ports. You might want to change the SCSI adapter from Buslogic to LSI, depending on the Linux OS you are using and it's supported hardware.

That was pretty easy, wasn't it? So let's boot the new box and see what happens... If you are a really lucky guy, you might find a working OS here. But as the world is a bad place, probably you are not going to be lucky. You will rather get a sweet little "Kernel Panic". OK, so let's make this #?%*! box boot again...

Boot your new system into rescue mode with some kind of emergency CD, usually the first one of your installation CD's will do the trick. For RHEL use the start option "linux rescue" at the boot prompt. The system should find your storage, otherwise there seems to be a driver missing. Mount all partitions the system asks you for.

Be sure you don't miss this one: Use chroot to change your root file system to the root partition because right now you work in a boot environment and not on your final system! Now mount all additional partitions you might need. Run kudzu to search for hardware changes.

And here's the real deal: The last remaining problem is your old initial ramdisk, that will probably not work in your new environment. So have to create a new one with the mkinitrd command. Here is an example:

/sbin/mkinitrd -v -f /boot/initrd-2.x.xx-xx.img 2.x.xx-xx

Take a look at /boot to find the right initrd name suiting your kernel. Also check /lib/modules, you should have a match here, too.

A totally different solution might also work, depending on your distribution: Instead of booting into rescue mode, try to perform an upgrade installation. This seems to work pretty well on some distributions.

If you are having really bad trouble booting your system, you might want to try to extract the kernel and initial ramdisk from another box with similar hardware. This works fine, but has a really big disadvantage: Kernel updates you receive will probably not work. I will have to look into this matter...

Cleaning up the mess...

I assume you have a booting Linux OS now. So, what is left to do? First, I would like to encourage you to uninstall any proprietary hardware assistance software and drivers from your old system. You will probably not need them on the new hardware anyway. Second, please install the VMware Tools on your new machine if you have gone virtual on ESX. The same is true for other vendors. Always install the specialized tools and drivers to get optimal results.

Link: http://panologic.com/who-we-are/resources.php

Thin Clients are a standard solution for Citrix or VDI environments. Pano goes one step further and presents the first "Zero Client", which means that the device has no CPU, no memory, no operating system, no drivers, no software and no moving parts.

Originally the development was for ESX servers only, but today the Pano Zero Client offers a wide range of connectivity. One of the major advantages of the Zero Client is it's low power consumption of only 3 watts. Please use the link above for further details on Pano and it's products.

Hardware vendors quickly embraced virtualization technology as they found a new market for their products. Popular CPU-based implementations are "Intel VT-x" and "AMD-V". This architecture is called "Hardware Assisted Virtualization" and since it is hardware-integrated, the VMM can run even under Ring-0 with "Root Level Privileges".

Besides the traditional Kernel and User Mode, there is an additional mode called "Guest Mode" where VMs are run in. Unprivileged applications have direct access the hardware, while privileged instructions are excepted and handled by the Hypervisor. The goal is the avoidance of rewriting instructions as you know it from binary translation.

Today I will take a look at "Paravirtualization". This technology is used in popular products like Xen and Parallels Virtuozzo. In Paravirtualization non-virtualizable instructions are replaced by so-called "Hypercalls". The Hypervisor itself is a kernel-modified OS with an inserted virtualization layer for translation. Just like binary translation direct unprivileged user mode access is possible. It is important to understand that the Host OS is the first VM started on the Hypervisor. This VM is referred to as a privileged guest (Dom0 in Xen) and has access to the drivers to access the underlying hardware.

Paravirtualization is much more flexible as far as hardware is concerned, because standard OS drivers can be applied. This means that a Para-Hypervisor can be extraordinary small, because it does not need to contain any hardware driver support.

Speaking of drivers: The unprivileged guests have frontend drivers which communicate with the backend driver of the privileged guest. This pro driver argument also is the downside of this architecture, since this virtualization approach is set to it's original OS. This means that you can only host Windows VMs on a Windows Host, Linux VMs on a Linux Host, and so on... The portability of the guests is also limited.

Since Paravirtualization is a major trend in the industry, VMware claims that they also used some these technology aspects in their VMware Tools on the VMs, of course without modifiying the OS kernel.