no edit summary
Xen hardware virtual machine (HVM) provides support for the virtualization of unmodified guest operating systems. Where ever possible it is better to run paravirtualized guests because HVM domainU guests run slightly slower than paravirtualized domainU guests and require that the host system contain a processor type with build in virtualization support. That said, if you need to virtualize an operating system which has not, or cannot be modified to run as a paravirtualized Xen guest (such as Microsoft Windows) then HVM virtualization is
the only solution.
== Full Virtualization vs. Para-Virtualization ==
== Preparing to Install a Xen HVM domainU Guest ==
In order to install a fully virtualized Xen guest some
from of disk storage is needed to contain the installed operating system. This can take the form of a physical disk (such as /dev/sdb) or a disk image file. A suitable disk image file can be created using the ''dd'' command. For example:
dd if=/dev/zero of=
XenGuest1.img bs=1024k seek=6144 count=0
The above command creates a 6Gb disk image file for use by the Xen HVM domainU guest.
In addition, suitable installation media (such as a DVD or ISO image) will required from which to install the guest operating system onto the disk image or disk drive.
== Creating a Xen HVM Configuration File ==
The example HVM guest configuration file provided
wtih Xen is as follows:
This file provides an excellent template to use as the basis for an HVM domainU guest configuration file. Many of these values can be left unchanged. Some key values which will need to be changed will be discussed in the remainder of this section.
disk = [ 'file:/home/xen/
XenGuest.img,hda,w', 'phy:/dev/cdrom,hdc:cdrom,r' ]
The above examples assume that you will be installing the guest operating system from a CD or DVD drive. It is also possible to perform the
installation from an ISO image residing on the filesystem of the host. For example:
Both SDL and VNC work well in terms of displaying a graphical console, although VNC has some distinct advantages over SDL. Firstly, VNC provides greater flexibility than SDL in terms of remote access to the domainU graphical console. With VNC it is possible to connect to the graphical console from other systems, either on the local network or even over the internet. Secondly, when you close a VNC viewer window the guest domain continues to run
and ytou can simply reconnect to carry on where you left off. Closing an SDL window immediately terminates the guest domainU system resulting in possible data loss.
By default Xen does not automatically start the VNC console when the domainU guest starts up. In order to have the graphical console spawned automatically, change the ''vncconsole ='' value to 1:
Finally, the boot search sequence needs to be defined. Since have to install the operating system before we
canboot from the hard disk drive we need to place the first in the boor order:
== Booting the HVM Guest ==
The guest system can now be started using the ''xm create''
All being well the domainU guest will start with output
ion the Xen text console similar to the following:
xm create *cfg -c
== Connecting to the HVM dominU Guest Graphical Console ==
If SDL was chosen for the graphical console then the console should appear when the guest starts up. If, on the other hand, VNC was selected and the domainU was not configured to automatically start ''vncviewer'' it is now necessary to connect manually. By default the VNC port is 5900 + the ID of the domain to which you wish to connect (which can be obtained using the ''xm list'' command). For example, to connect to domain ID 10:
Once the installation of the guest operating system has completed be sure to reverse the boot order in the configuration file if you no longer wish to have the CD/DVD drive first
in the boot order:
# default: hard disk, cd-rom, floppy