XCP PV templates start

From Xen
Revision as of 07:07, 29 January 2015 by Xenfomation (talk | contribs) (Trying to add platform:vga options since bootloader options are discussed here.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search
Icon todo.png To Do:

Has this been implemented? If so, it should be moved to Designs in the XAPI Devel Index


A virtual machine, when created using the xe command along with its series of options, such as: xe vm-install template="... (examples are "Ubuntu", "RedHat", "Debian", "openSUSE", and so forth)" ... new-name-label="YOUR_DESIRED_VM_NAME"..., the following steps take place:


  1. XCP clones a virtual machine template where the template metadata defines is-a-template=true || default_template=true and instantiates it as its own, unique virtual machine
  2. It process the original virtual machine's 'disks' - along with other metadata from the template - such as disks: <provision><disk device="0" size="8589934592" sr="" bootable="true" type="system"/></provision>) ... this will naturally create the new virtual machine's virtual disks based on the template definition.
  3. After the user specifies configurable options for the virtual machine being created from the VM template (network interfaces, RAM, and so forth), the new VM is now its own official entity and starts: running with the specified virtual machine's original template value for PV-bootloader, which is "eliloader"
  4. And here template specific starts...

eliloader

Eliloader is python script located in /usr/bin/eliloader. It allows XCP to download network installation images (kernel and overgrown initrd) for specified operating system (actual network image is really differ in suse, centos and debian systems). For some legacy and antique systems (like RHEL 4) it to some patching of initrd. Exact path is constructed from type of template (install-distro in other-config) and url, provided by used in other-config: install-repository). After initrd and kernel is extracted they are used as kernel and initrd for virtual machine (and installation started).

Right after successful VM start PV-bootloader is replaced from eliloader to pygrub (to boot to new VM native kernel). Of course, if user stops installation process, at next startup there will be no kernel and vm will not start again.

installation restart

For installation restart PV-bootloader can be set back to eliloader (xe vm-param-set uuid=... PV-bootloader=eliloader), after that installation can be restarted again.

Eliloader replacement

The main problem of eliloader is large initrd, tranferred via internet (or other network). This can be sometimes annoying and can be solved by using pre-downloaded initrd. This will not works for older systems (like RHEL4) which require patching of initrd, but works fine for modern version of ubuntu, opensuse (suse too, I hope), debian. Those files must be placed in /boot/guest directory on every host of the pool (don't forget to check if enough free space is available!).

Here sample for Debian 6 (squeezy), 64 bits:

cd /boot/guest
mkdir squeezy64-install
cd squeezy64-install
wget http://mirror.yandex.ru/debian/dists/Debian6.0.3/main/installer-amd64/current/images/netboot/xen/vmlinuz
wget http://mirror.yandex.ru/debian/dists/Debian6.0.3/main/installer-amd64/current/images/netboot/xen/initrd.gz
(vm-install and vif creating skipped)
xe vm-param-set uuid=... PV-bootloader=
xe vm-param-set uuid=... PV-kernel=/boot/guest/squeezy64/vmlinuz
xe vm-param-set uuid=... PV-ramdisk=/boot/guest/squeezy64/initrd.gz
xe vm-start uuid=...
xe vm-param-set uuid=... PV-bootloader=pygrub

Note the last line: set back to pygrub to avoid endless installation.

The main problem of eliloader is large initrd, tranferred via internet (or other network). This can be sometimes annoying and can be solved by using pre-downloaded initrd. This will not works for older systems (like RHEL4) which require patching of initrd, but works fine for modern version of ubuntu, opensuse (suse too, I hope), debian. Those files must be placed in /boot/guest directory on every host of the pool (don't forget to check if enough free space is available!).


PV/HVM Graphic Replacement

By default, most virtual machine templates lean upon the Cirrus VGA drivers as they are not only the most generic, but most compatible with various architectures. There is an option that can be changed at either the "virtual machine template" level or the "Guest/User VM" level to leverage VGA options:

xe vm-platform-set uuid="UUID of your VM" platform:vga=std platform:videoram=8

The videoram's max value can be 16MiB. The platform flag defining VGA as the "standard" (std) informs the Hypervisor to leverage VGA-based drivers instead of the more basic, Cirrus drivers.