- It creates a whole disk image instead of importing partitions.
This makes it difficult to access domU filesystems from dom0, but
this is often necessary for management.
That's just part of the goal of making the domU environment as similar
as possible to the dom0. Having a single disk image passed in
means you
can keep boot info, root fs and swap all in the same place in the host
OS.
I understand the motivation here, but it does make it much harder to
manipulate the domU filesystem from dom0. I personally couldn't
figure out how to mount a domU partition when using the whole-disk
method. I imagine that it's even more complicated when the domU has
its own LVM volumes.
This issue aside, I do like the idea of having a single disk image
for each domU, though, since it keeps things simple. It's nice to
have the kernel, swap partition, and main partition (and whatever
else) all in one place. But it seems very inelegant to use the
ancient DOS partitioning scheme and then put LVM on top of it.
Things would be simpler if a domU could start out with LVM right on
top of the disk image, like if you ran 'pvcreate /dev/sda' in the
domU. Then you wouldn't need a separate /boot partition; it could be
just another LVM volume. I know that this is problematic for "real"
installations of Linux, because of the BIOS <1024 cylinder limitation
(is that still an issue?), and because grub doesn't understand LVM.
But the first limitation simply doesn't exist with a domU under Xen
(I hope), and the second can be worked around -- I imagine that
making pygrub understand LVM would be easier than making grub
understand LVM, since there aren't the same memory/space limitations.
In short, why emulate all crufty old mechanics of booting and
partitioning a PC when Xen provides a way to (finally) avoid it? You
would lose the ability to image a domU disk image right onto a real
disk and then boot a real machine with that disk, but I think that's
the only thing, and it's pretty minor.
- It doesn't provide an option for creating images on LVM volumes.
If you already have an LVM volume, you can simply specify that and it
just works (most of my test xen installs are to LVM.)
That's good to know... The script doesn't make it clear that it has
that capability. If I remember right, I tried that, and the config
file said file:/dev/VolGroup00/fc5_root, or something like that
instead of phy:.., which seems like an error. (I was still having
other Xen problems so I never got it working this way.) The LVM
volume already has a size, so what happens when you specify a disk
image size to the installer script?
Or you could use a kernel from xensource that has the xennet driver
compiled into the kernel. I don't know why the developers decided to
take the driver out of the kernel.
The default networking with Xen uses netfront/back and bridging, so
that's what we compile in. Is there really a strong need for xennet
too?
I'm not an expert on Xen network drivers... All I know is that when I
booted the jailtime.org FC5 image (and a Centos 4.2 image that I
created myself) using the stock FC5 xenU kernel, that it would say
there was no eth0 on boot. I managed to get eth0 to show up by
loading the xennet kernel module, as recommended by someone on the
xensource xen-users list. If there's way to get a domU's eth0 to
show up using the stock XenU kernel and without loading a module,
that would be great. How would I do this?
--Winston
