2008-04-23 21:08:31 +04:00
< html >
< body >
< h1 > Xen hypervisor driver< / h1 >
2009-05-21 18:20:21 +04:00
< ul id = "toc" > < / ul >
2008-04-23 21:08:31 +04:00
< p >
The libvirt Xen driver provides the ability to manage virtual machines
on any Xen release from 3.0.1 onwards.
< / p >
2009-05-21 18:20:21 +04:00
< h2 > < a name = "prereq" > Deployment pre-requisites< / a > < / h2 >
2008-04-23 21:08:31 +04:00
< p >
The libvirt Xen driver uses a combination of channels to manage Xen
virtual machines.
< / p >
< ul >
< li >
< strong > XenD< / strong > : Access to the Xen daemon is a mandatory
requirement for the libvirt Xen driver. It requires that the UNIX
socket interface be enabled in the < code > /etc/xen/xend-config.sxp< / code >
configuration file. Specifically the config settings
< code > (xend-unix-server yes)< / code > . This path is usually restricted
to only allow the < code > root< / code > user access. As an alternative,
the HTTP interface can be used, however, this has significant security
implications.
< / li >
< li >
< strong > XenStoreD< / strong > : Access to the Xenstore daemon enables
more efficient codepaths for looking up domain information which
lowers the CPU overhead of management.
< / li >
< li >
< strong > Hypercalls< / strong > : The ability to make direct hypercalls
allows the most efficient codepaths in the driver to be used for
monitoring domain status.
< / li >
< li >
< strong > XM config< / strong > : When using Xen releases prior to 3.0.4,
there is no inactive domain management in XenD. For such releases,
libvirt will automatically process XM configuration files kept in
the < code > /etc/xen< / code > directory. It is important not to place
any other non-config files in this directory.
< / li >
< / ul >
2009-05-21 18:20:21 +04:00
< h2 > < a name = "uri" > Connections to Xen driver< / a > < / h2 >
2009-01-27 17:49:09 +03:00
< p >
The libvirt Xen driver is a single-instance privileged driver,
with a driver name of 'xen'. Some example conection URIs for
the libvirt driver are:
< / p >
< pre >
xen:/// (local access, direct)
xen+unix:/// (local access, via daemon)
xen://example.com/ (remote access, TLS/x509)
xen+tcp://example.com/ (remote access, SASl/Kerberos)
xen+ssh://root@example.com/ (remote access, SSH tunnelled)
< / pre >
2009-05-21 18:20:21 +04:00
< h2 > < a name = "imex" > Import and export of libvirt domain XML configs< / a > < / h2 >
< p > The Xen driver currently supports two native
config formats. The first known as < code > xen-xm< / code > is the format
used by the XM tool for files in < code > /etc/xen< / code > . The second
known as < code > xen-sxpr< / code > , is the format used for interacting
with the XenD's legacy HTTP RPC service.< / p >
< h3 > < a name = "xmlimport" > Converting from XM config files to domain XML< / a > < / h3 >
< p >
The < code > virsh domxml-from-native< / code > provides a way to convert an
existing set of XM config files into a guest description using libvirt Domain XML
that can then be used by libvirt.
< / p >
< pre > $ virsh -c xen:/// domxml-from-native xen-xm rhel5.cfg
< domain type='xen'>
< name> rhel5pv< /name>
< uuid> 8f07fe28-753f-2729-d76d-bdbd892f949a< /uuid>
< memory> 2560000< /memory>
< currentMemory> 307200< /currentMemory>
< vcpu> 4< /vcpu>
< bootloader> /usr/bin/pygrub< /bootloader>
< os>
< type arch='x86_64' machine='xenpv'> linux< /type>
< /os>
< clock offset='utc'/>
< on_poweroff> destroy< /on_poweroff>
< on_reboot> restart< /on_reboot>
< on_crash> restart< /on_crash>
< devices>
< disk type='file' device='disk'>
< driver name='tap' type='aio'/>
< source file='/var/lib/xen/images/rhel5pv.img'/>
< target dev='xvda' bus='xen'/>
< /disk>
< disk type='file' device='disk'>
< driver name='tap' type='qcow'/>
< source file='/root/qcow1-xen.img'/>
< target dev='xvdd' bus='xen'/>
< /disk>
< interface type='bridge'>
< mac address='00:16:3e:60:36:ba'/>
< source bridge='xenbr0'/>
< /interface>
< console type='pty'>
< target port='0'/>
< /console>
< input type='mouse' bus='xen'/>
< graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0'/>
< /devices>
< /domain>
< / pre >
< h3 > < a name = "xmlexport" > Converting from domain XML to XM config files< / a > < / h3 >
< p >
The < code > virsh domxml-to-native< / code > provides a way to convert a
guest description using libvirt Domain XML, into the XM config file
format.
< / p >
< pre > # virsh -c xen:/// domxml-to-native xen-xm rhel5pv.xml
name = "rhel5pv"
uuid = "8f07fe28-753f-2729-d76d-bdbd892f949a"
maxmem = 2500
memory = 300
vcpus = 4
bootloader = "/usr/bin/pygrub"
kernel = "/var/lib/xen/boot_kernel.0YK-cS"
ramdisk = "/var/lib/xen/boot_ramdisk.vWgrxK"
extra = "ro root=/dev/VolGroup00/LogVol00 rhgb quiet"
on_poweroff = "destroy"
on_reboot = "restart"
on_crash = "restart"
sdl = 0
vnc = 1
vncunused = 1
vnclisten = "0.0.0.0"
disk = [ "tap:aio:/var/lib/xen/images/rhel5pv.img,xvda,w", "tap:qcow:/root/qcow1-xen.img,xvdd,w" ]
vif = [ "mac=00:16:3e:60:36:ba,bridge=virbr0,script=vif-bridge,vifname=vif5.0" ]
< / pre >
2009-01-27 17:49:09 +03:00
2008-04-23 21:08:31 +04:00
< h2 > < a name = "xmlconfig" > Example domain XML config< / a > < / h2 >
< p >
Below are some example XML configurations for Xen guest domains.
For full details of the available options, consult the < a href = "formatdomain.html" > domain XML format< / a >
guide.
< / p >
< h3 > Paravirtualized guest bootloader< / h3 >
< p >
Using a bootloader allows a paravirtualized guest to be booted using
a kernel stored inside its virtual disk image
< / p >
< pre > < domain type='xen' >
< name> fc8< /name>
< bootloader> /usr/bin/pygrub< /bootloader>
< os>
< type> linux< /type>
< /os>
< memory> 131072< /memory>
< vcpu> 1< /vcpu>
< devices>
< disk type='file'>
< source file='/var/lib/xen/images/fc4.img'/>
< target dev='sda1'/>
< /disk>
< interface type='bridge'>
< source bridge='xenbr0'/>
< mac address='aa:00:00:00:00:11'/>
< script path='/etc/xen/scripts/vif-bridge'/>
< /interface>
< console tty='/dev/pts/5'/>
< /devices>
< /domain> < / pre >
< h3 > Paravirtualized guest direct kernel boot< / h3 >
< p >
For installation of paravirtualized guests it is typical to boot the
domain using a kernel and initrd stored in the host OS
< / p >
< pre > < domain type='xen' >
< name> fc8< /name>
< os>
< type> linux< /type>
< kernel> /var/lib/xen/install/vmlinuz-fedora8-x86_64< /kernel>
< initrd> /var/lib/xen/install/initrd-vmlinuz-fedora8-x86_64< /initrd>
< cmdline> kickstart=http://example.com/myguest.ks < /cmdline>
< /os>
< memory> 131072< /memory>
< vcpu> 1< /vcpu>
< devices>
< disk type='file'>
< source file='/var/lib/xen/images/fc4.img'/>
< target dev='sda1'/>
< /disk>
< interface type='bridge'>
< source bridge='xenbr0'/>
< mac address='aa:00:00:00:00:11'/>
< script path='/etc/xen/scripts/vif-bridge'/>
< /interface>
< graphics type='vnc' port='-1'/>
< console tty='/dev/pts/5'/>
< /devices>
< /domain> < / pre >
< h3 > Fullyvirtualized guest BIOS boot< / h3 >
< p >
Fullyvirtualized guests use the emulated BIOS to boot off the primary
harddisk, CDROM or Network PXE ROM.
< / p >
< pre > < domain type='xen' id='3'>
< name> fv0< /name>
< uuid> 4dea22b31d52d8f32516782e98ab3fa0< /uuid>
< os>
< type> hvm< /type>
< loader> /usr/lib/xen/boot/hvmloader< /loader>
< boot dev='hd'/>
< /os>
< memory> 524288< /memory>
< vcpu> 1< /vcpu>
< on_poweroff> destroy< /on_poweroff>
< on_reboot> restart< /on_reboot>
< on_crash> restart< /on_crash>
< features>
< pae/>
< acpi/>
< apic/>
< /features>
< clock sync="localtime"/>
< devices>
< emulator> /usr/lib/xen/bin/qemu-dm< /emulator>
< interface type='bridge'>
< source bridge='xenbr0'/>
< mac address='00:16:3e:5d:c7:9e'/>
< script path='vif-bridge'/>
< /interface>
< disk type='file'>
< source file='/var/lib/xen/images/fv0'/>
< target dev='hda'/>
< /disk>
< disk type='file' device='cdrom'>
< source file='/var/lib/xen/images/fc5-x86_64-boot.iso'/>
< target dev='hdc'/>
< readonly/>
< /disk>
< disk type='file' device='floppy'>
< source file='/root/fd.img'/>
< target dev='fda'/>
< /disk>
< graphics type='vnc' port='5904'/>
< /devices>
< /domain> < / pre >
< h3 > Fullyvirtualized guest direct kernel boot< / h3 >
< p >
With Xen 3.2.0 or later it is possible to bypass the BIOS and directly
boot a Linux kernel and initrd as a fullyvirtualized domain. This allows
for complete automation of OS installation, for example using the Anaconda
kickstart support.
< / p >
< pre > < domain type='xen' id='3'>
< name> fv0< /name>
< uuid> 4dea22b31d52d8f32516782e98ab3fa0< /uuid>
< os>
< type> hvm< /type>
< loader> /usr/lib/xen/boot/hvmloader< /loader>
< kernel> /var/lib/xen/install/vmlinuz-fedora8-x86_64< /kernel>
< initrd> /var/lib/xen/install/initrd-vmlinuz-fedora8-x86_64< /initrd>
< cmdline> kickstart=http://example.com/myguest.ks < /cmdline>
< /os>
< memory> 524288< /memory>
< vcpu> 1< /vcpu>
< on_poweroff> destroy< /on_poweroff>
< on_reboot> restart< /on_reboot>
< on_crash> restart< /on_crash>
< features>
< pae/>
< acpi/>
< apic/>
< /features>
< clock sync="localtime"/>
< devices>
< emulator> /usr/lib/xen/bin/qemu-dm< /emulator>
< interface type='bridge'>
< source bridge='xenbr0'/>
< mac address='00:16:3e:5d:c7:9e'/>
< script path='vif-bridge'/>
< /interface>
< disk type='file'>
< source file='/var/lib/xen/images/fv0'/>
< target dev='hda'/>
< /disk>
< disk type='file' device='cdrom'>
< source file='/var/lib/xen/images/fc5-x86_64-boot.iso'/>
< target dev='hdc'/>
< readonly/>
< /disk>
< disk type='file' device='floppy'>
< source file='/root/fd.img'/>
< target dev='fda'/>
< /disk>
< graphics type='vnc' port='5904'/>
< /devices>
< /domain> < / pre >
< / body >
< / html >