Xen tips and tricks
1. Setting the security context of Xen images
The targeted SELinux policy for Xen requires Xen disk images to have the xen_image_t context. If an image is not in that context, access to that image will be denied to the domU system (Anaconda-based installers, like the CentOS installer will fail to find the hard disk that this image should provide). By default, two directories are defined with this context:
/var/lib/xen/images(/.*)? system_u:object_r:xen_image_t:s0 /xen(/.*)? system_u:object_r:xen_image_t:s0
You can also explicitly set the context of files or directories with chcon, or add a local file context customization if you want to keep the correct context when contexts are restored for some reason. For instance, I like to keep my images in /srv/xen. The following commands prepare this directory for use of Xen images:
# mkdir -p /srv/xen # semanage fcontext -a -t xen_image_t "/srv/xen(/.*)?"
The second command adds the following line to /etc/selinux/targeted/contexts/files/file_contexts.local:
/srv/xen(/.*)? system_u:object_r:xen_image_t:s0
and reloads the SELinux policy. Now that the correct file context is known to the policy, you can use restorecon to recursively give this directory the right context:
# restorecon -R /srv/xen
If you want, you can check that the context is correctly set with ls:
# ls -dZ /srv/xen drwxr-xr-x root root system_u:object_r:xen_image_t /srv/xen
2. Console handling
The default console device in a domU system is xvc0. This is what xm console attaches to. To be able to log on to this console, an agetty instance has to listen to xvc0. If this is not the case, you will only see syslog messages that are redirected to this specific console or to all consoles. Kudzu automatically adds an entry for xvc0 to /etc/inittab if /dev/console and /dev/xvc0 represent the same device (which is the case if xvc0 is the primary or only console device). If you use a virtual framebuffer device, this will not be the case, and an xvc0 entry will not be added to /etc/inittab. Virt-manager uses the virtual frame buffer, this can be determined by looking through the domain configuration file for the vfb option. E.g.:
vfb = ["type=vnc,vncunused=1"]
If you would still like to be able to log in via xvc0, add the following line to /etc/inittab in the domU:
co:2345:respawn:/sbin/agetty xvc0 9600 vt100-nav
Also add xvc0 to /etc/securetty.
You can instruct init to reread /etc/inittab as root, with:
# telinit q
3. Defining other keyboard layout through virt-manager
Probably you've seen that the keyboard layout in a DomU para-virtualized system always act as a 'qwerty' keyboard through virt-manager and doesn't use the keyboard layout declared during setup (and configured in /etc/sysconfig/keyboard). This behaviour only happens if you use vfb (through virt-manager or directly with vncviewer). If you use xm console , the system will use the correct keyboard layout.
But starting from CentOS 5.1 (so with packages xen-3.0.3-41.el5, xen-libs-3.0.3-41.el5, libvirt-0.2.3-9.el5 and virt-manager-0.4.0-3.el5) you can use another keyboard layout than qwerty inside of a DomU through virt-manager. Unfortunately, this can't be done in virt-manager itself, but on a 'guest' basis in the config file :
here is an example for a DomU using a Belgian keyboard layout (be-latin1) :
vfb = [ "type=vnc,vncunused=1,keymap=fr-be" ]
Of course, you have to modify with the correct layout : all possible keymaps are located in /usr/share/xen/qemu/keymaps
You can also set a certain keyboard layout as the default for all domU's. To do this edit the file /etc/xen/xend-config.sxp, then add a line like this (example for a french keyboard):
(keymap 'fr')
The Xen daemon then needs to be restarted to make this configuration change active (service xend restart).