Yet another installment of our Foray series of technical discussions. It has been quite some time since my last installment. In a manner of speaking I have been otherwise preoccupied. Well over the past few weeks I have learned about the original IOS, that is the Cisco proprietary operating system for all of their networking devices. Perhaps one day I will sit for the CCNA exam?
I digress; however, I do plan to talk about my crash course indoctrination into Level 3 or managed switches. Suffice to say I have much to learn about IOS.
What exactly is hardware virtualization? Why should it interest you?
Well most people now understand that there is generally a cost penalty for proliferating bare metal computing. More specifically, for every computer running in your home there is some measure of power consumption penalty. In truth, I have never taken the time to calculate how much electricity our home servers consume during an average month. In the basement, I run a VPN/gateway, PBX (aka re-purposed HP Pavilion running OpenBSD), Slackware workstation (aka AG desktop), managed 24 port switch, and a wi-fi access point. Actually, there were two more machines that ran continuously, but have since been retired (ie yet another HP Pavilion whose proprietary power supply failed and Pentium III based machine that ran my mythtv setup). Needless to say that is a healthy power consumption. I would guess at minimum each machine could easily consume 350W depending upon computation load.
I suppose the delightful promise of virtualization is the ability to spin-up an instance of your preferred operating system within seconds and then possibly deploy it locally or remotely.
Of course locally would suggest that you are running it on your own hardware and remotely would suggest that you are leasing space with a vendor (ie virtual private server, amazon ec2, or more recently GOOG).
Please note that this blog entry will not be an exhaustive explanation of para-virtualization and the differences between various commercially available hypervisors (ie virtualbox, Xen, etc). That is beyond the scope of this post and will be left as an exercise for the reader. I merely wish to discuss my experiences with QEMU / KVM.
Firstly, it is important to note that KVM is a kernel based virtualization strategy, which enables total virtualization of guest operating system of your choosing. It is not a para-virtualization platform like Xen. Perhaps what I like most about KVM is that the project is not owned or managed by a corporate conglomerate. So, there is no concern about the codebase being managed by shareholder interests. Since KVM is tightly bound to the kernel, you can expect it to work as advertised without issue.
For those of you who are already familiar with QEMU, you will note that it was the first Open Source alternative to VMWare. Apparently the project founder, Fabrice Bellard was more interested in a stable software than making a market splash. It would appear that the project has been in existence for at least 8yrs and it just reached v2.0.
When I was initially introduced to virtualization circa 2001, I used the student edition of VMWare, which I believe was v1.0. It was truly a memory hog, but certainly less painful than dual booting. At that time, the only reason I cared to explore hardware virtualization was to run the odd M$ Windows program. Fast forward to present date, I can attest that running Win7, Android or PC-BSD as a guest OS would offer immediate value.
I often am faced with supporting end-users who only run Win7, so I really needed to use my _legal_ copy of Win7 Pro and extract the CD image. Below is the script that I ran at the command line to create the virtual machine. The flags are interesting, but before I get into them let me share a bit of my experience running QEMU-KVM on Slackware.
qemu-system-x86_64 -enable-kvm -localtime -m 1000 -hda /home/agreen/.aqemu/Windows_7_HDA.img -cdrom /dev/cdrom -boot d
While you do not need to run an GUI to control and manage virtual machine instances, it is convenient to actually organize each of your virtual guests. Especially, if you are running several instances. In my case, I only ran one guest OS, and I chose aqemu. Some people seem to prefer virtmanager, but aqemu was simple enough to use and had a fairly lightweight GTK style GUI.
I immediately, discovered a well documented bug within Cairo, one of the graphical libraries. After perusing the Interwebs, I was able to install the latest Cairo library from Slackware-Current. Apparently, the cairo library provided with Slackware 14.0 had some weird issue that prevented the aqemu window from refreshing or simply being drawn as expected.
Bridged Networking with KVM (Photo credit: xmodulo)
After installing the correct library all worked as expected and I was fascinated on the ease of pausing the guest OS. I allocated roughly 8GB of disk space to the Win7 instance. As the '-m 1000' flag would suggest, the virtual machine will use 1GB of RAM. Somehow I believe there is a setting that permits the virtual machine to use increased amounts of memory on demand. I am certain that I did not choose that particular option. /dev/hda was actually a portion of my home partition, managed by LVM. So, in essence, I could grow the disk if necessary without disrupting anything on my host box. The "/Windows_7_HDA.img -cdrom /dev/cdrom -boot d " statement is simply defining the boot device or path to virtual cdrom drive. Really fairly simple, I didn't not need any exotic virtual drivers and it did not take several hours to setup or install so do not believe the plethora of erroneous information in circulation regarding running Win7 as a guest OS within QEMU-KVM.
One major issue is the bridging networking feature. By default QEMU will create a virtual network, that will allow the virtual machine to see the outside world, but you will not be able to browse the local area network. After reading alienBOB's wiki, I see there is a means to get around this limitation, but it requires installing and setting up DNSmasq. I will revisit this blog entry once I get a moment to resolve that problem and setup bridged networking as desired.