Automating Xen VM deployment with SystemImager
From SystemImager
Contents |
Automating Xen VM deployment with SystemImager
Andrea Righi, System & Technology Department, CINECA
Mar 2008
Abstract
One advantage of server virtualization is the ability to rapidly provision new production environments. Automatic virtual machine deployment can significantly speed up the time to instantiate new services or reallocate resources depending on the user needs.
This article focuses on the integration of SystemImager and Xen to create a totally open source framework able to manage on-demand deployment of virtual machines, such as physical machines, using a single centralized point of management.
This approach allows to strongly reduce IT costs and simplify administrative tasks for enterprise data centers, even with a complex and/or reduced set of hardware resources, exploiting the dynamic-provisioning functionalities of SystemImager and virtualization advantages of Xen.
Xen
Xen is a Linux virtual machine environment that provides near-native performance through a technique called paravirtualization. Essentially, paravirtualization allows the guest operating system (OS) some direct hardware access, instead of virtualizing the entire hardware interface. Xen requires both the host and guest operating systems to run modified kernels to support this[1].
With Xen virtualization, a thin software layer known as the Xen hypervisor is inserted between the server's hardware and the operating system. This provides an abstraction layer that allows each physical server to run one or more "virtual servers," effectively decoupling the operating system and its applications from the underlying physical server[2].
Automatic virtual machine deployment
The automatic virtual machine deployment can be modeled using a three steps sequential workflow[3].
- Preparation: create a image of the system for a target machine
- Deployment: instantiate the target virtual machine
- Activation: power-on the virtual machine
All these three steps can be automated using SystemImager and xen-tools functionalities.
Preparation
A design feature of SystemImager that facilitates Linux distribution and hardware independence is the support of file based (rather than block based) system images. An image is stored as a directory hierarchy of files representing a comprehensive snapshot of a machine, containing all the files and directories from the root of that machine's file system. Images can be acquired in multiple ways, including retrieval from a sample physical or virtual system (called golden client), or by direct generation on the SystemImager server using third-party tools (debootstrap for Debian/Ubuntu, yum for Fedora/Red Hat, YaST for SuSE, etc.)[4].
We can use this SystemImager feature to implement the preparation phase of the automatic virtual machine deployment. Generating a normal SystemImager image is sufficient to create the starting template, that will be used to instantiate the virtual machine environments for the production.
Deployment
The preparation phase works out of the box and does not require any modification in the typical SystemImager usage. Anyway, the deployment phase cannot be fully automated using typical standalone SystemImager installations[5]. A potential approach could be to simply install the virtual machine using Xen hardware assisted virtualization (Xen-HVM). In this way the guest system's kernel does not require modification and a common BOEL or UYOK SystemImager kernel can be booted to deploy the virtual environment and then reboot with the Xen paravirtualized mode kernel, or just perform a normal reboot and stay in HVM mode (althought the performance penalty due to MMU virtualization by shadow page tables, I/O and hardware components emulation, and a bigger CPU exception rate, due to the root-mode/non-root-mode switches provided by VT-x or AMD-V hardware). This approach would have the benefit to perfectly consolidate the installation of virtual machines, because it is actually the same of physical machines, but it has the disadvantage that requires a VT-x or AMD-V server to host the Xen hypervisor.
There is also another way to deploy virtual machines, faster and more portable. Here the xen-tools suite comes into play: xen-tools is a collection of simple perl scripts created by Steve Kemp which allow to easily create new guest Xen domains. Multiple installation method are supported, like install via debootstrap, rpmstrap, copying from a chroot-able image or untar an archive of a pre-created image.
In particular the copy from a chroot-able image is exactly what we need to deploy our SystemImager images. Following an example of a SystemImager image server with 4 images available for deployment:
$ si_lsimage -------------------------------------------------------------------------------- Available image(s): -------------------------------------------------------------------------------- Debian4 centos5 opensuse10.3 ubuntu7_10
The following command uses xen-create-image (from xen-tools suite) to create a ready to use virtual machine instance from ubuntu7_10 SystemImager image:
$ sudo xen-create-image --memory 256 --size=2Gb --swap=128Mb --dhcp \
> --dir=/home/righiandr/xen --hostname=ubuntu --install-method=copy \
> --install-source=/var/lib/systemimager/images/ubuntu7_10
General Information
--------------------
Hostname : ubuntu
Distribution : etch
Fileystem Type : ext3
Size Information
----------------
Image size : 2Gb
Swap size : 128Mb
Image type : sparse
Memory size : 256
Kernel path : /boot/vmlinuz-2.6.22-14-xen
Initrd path : /boot/initrd.img-2.6.22-14-xen
Networking Information
----------------------
IP Address : DHCP
Creating swap image: /home/righiandr/xen/domains/ubuntu/swap.img
Done
Creating disk image: /home/righiandr/xen/domains/ubuntu/disk.img
Done
Creating ext3 filesystem on /home/righiandr/xen/domains/ubuntu/disk.img
Done
Installation method: copy
(Source: /var/lib/systemimager/images/ubuntu7_10)
Done
Running hooks
Done
No role script specified. Skipping
Creating Xen configuration file
Done
All done
Logfile produced at:
/var/log/xen-tools/ubuntu.log
NOTE
- hwclock doesn't work in Xen i386 guests and causes the boot process to pause for a long time. It is strongly suggested to disable the service hwclock from the init scripts (/etc/init.d/) if you don't want to hang your VMs during the boot or shutdown.
- for the same reason you need to also check the udev rules about hwclock and rtc kernel module, in Ubuntu for example you need to comment the following line in the file /etc/udev/rules.d/85-hwclock.rules:
KERNEL=="rtc", ACTION=="add", RUN+="set_hwclock"
Activation
Now the virtual machine is ready to be powered on. The activation phase simply consists in the Xen command to start the fresh created virtual machine:
$ sudo xm create /etc/xen/ubuntu.cfg -c Using config file "/etc/xen/ubuntu.cfg". Started domain ubuntu [ 0.000000] Linux version 2.6.22-14-xen (buildd@terranova) (gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)) #1 SMP Tue Feb 12 09:27:26 UTC 2008 (Unofficial) [ 0.000000] Reserving virtual address space above 0xf5800000 [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] Xen: 0000000000000000 - 0000000010800000 (usable) [ 0.000000] 0MB HIGHMEM available. [ 0.000000] 264MB LOWMEM available. [ 0.000000] NX (Execute Disable) protection: active [45456.399570] Zone PFN ranges: [45456.399572] DMA 0 -> 67584 [45456.399575] Normal 67584 -> 67584 [45456.399576] HighMem 67584 -> 67584 [45456.399578] early_node_map[1] active PFN ranges [45456.399581] 0: 0 -> 67584 [45456.403848] ACPI in unprivileged domain disabled [45456.406115] Allocating PCI resources starting at 20000000 (gap: 10800000:ef800000) [45456.406171] Built 1 zonelists. Total pages: 67056 ...
The virtual machine is up, running and ready for production (just remove the "-c" option to start it in background).
Conclusion
Advantages of the automated Xen VM deployment:
- significantly speeds up on-demand deployment and allows to implement self-healing services[6],
- helps to automate transitions from physical to virtual, virtual to physical, and/or virtual to virtual envronments (even between different virtual technologies, i.e. VMWare to Xen or vice versa), reducing IT costs and simplifying administrative workloads,
- allows to quickly deploy testing environments, like IT labs, virtual servers, virtual clusters, etc.[7]
References
- ↑ A. Norton, AutoXen: Automating Virtual Machine Deployment Within the Grid, 2006
- ↑ P. Barham, B. Dragovic, K. Fraser, S. Hand, T. Harris, A. Ho, R. Neugebauer, I. Pratt, A. Warfield, Xen and the art of virtualization, 2003. ISBN 1581137575
- ↑ L. He, S. Smith, R. Willenborg, Q. Wang, IBM Automating deployment and activation of virtual images
- ↑ A. Righi, B.E. Finley, E. Focht, B. Li, SystemImager and BitTorrent: a peer-to-peer approach for Large-Scale OS Deployment, 2007
- ↑ K. Buytaert, Automating Xen Virtual Machine Deployment, 2006
- ↑ G. Kecskemeti, P. Kacsuk, G. Terstyanszky, T. Kiss, T. Delaitre, Automatic Service Deployment Using Virtualisation, 2008. ISSN 10666192
- ↑ A.d. Vicente, Building A Virtual Cluster with Xen, 2006
