Xen FAQ Installation

File Systems

Is there a way to have a shared root file system amongst a set of Xen servers?

Yes, the best way to achieve this is to install your guest with an LVM-backed block device. You can then create a snapshot of this filesystem, with the command: lvcreate -L<size of snapshot> -s -n <snapshot name> <backend disk name>

You should create one snapshot per guest, and then put the snapshot into the guest's .cfg file.

Using snapshots allows you to avoid having to make a read-only root filesystem. However, should you wish to use a read only root fs, you can install the OS in an LVM partition and use it shared across all the xen domUs when you use the parition as 'r' instead of 'w' when defining the disk.

Will I get good I/O performance if I use a file-backed (.img) block device?

No. Using lvm to create a volume, and using the

disk=['phy:/...']

method in your .cfg file will yield better performance. This is particularly important for I/O intensive VMs, such as databases.

How can I make disk resizing work?

I tried to resize a disk of my data guest from 100 to 400 GB. I did an lvresize /dev/xendata/data-disk -L 400G an it works. I started the Guest and did an df -h to check the size but there are still 100 G

The container is bigger but the filesystem isn't. Resizing an LV doesn't make the FS any bigger.

Log into the DomU and do a resize2fs <device>. You can do this while it's mounted as long as the filesystem is getting bigger.

Oh, and if you've partitioned the LV inside the guest, you'll also need to resize the partition (BEFORE you do a resize2fs, etc.). There are two ways to do this - the safest is to use parted, which works if you're using ext2/ext3 (and a couple other of the most popular filesystems - reiser, I think). The other method is to delete the partition and recreate it with the extended end points. This isn't quite as safe and requires that 1) your start point for the partition is exactly the same as it was before, and 2) the partition is the last (or only) one on the LV.

How do I overcommit storage?

This is a matter of what storage backend you use. If you use one of the following, you will be able to overcommit storage:

• sparse raw file (with file: or tap:aio:)
• qcow
• vmdk/vdisk (I think full support is only in newer Xen or Opensolaris)
• zvol (on Opensolaris)

If you use disk/partition/LVM for domU storage, you won't be able to.

32bit vs 64 bit

Is there any way to install 64Bit Linux DomU on 32Bit Linux Dom0?

Types of domU that can be run depends mostly on the hypervisor, and not dom0. So if you have a 64bit hypervisor, you should be able to run 32 and 64bit PV and HVM domUs, regardless whether dom0 is 32 or 64bit.

If you have 32bit dom0 and 32bit hypervisor, you should be able to run 64bit HVM domU, but not 64bit PV domU.