Trevor Orsztynowicz <trevoro@xxxxxxxxxxxxx> writes:
> I'm working on a project right now focused on Xen and I'm curious what
> everyones experiences / preferences are regarding the following two
> aspects
>
> Preferred Disk Partition Format
> and
> Location of the Kernel (ie Pygrub / Kernel outside an Image)
I have a strong preference for keeping the kernel in the image. I understand
the security concerns, but I consider it worth it to get the ease of
management and flexibility. Of course, now that 3.3 out, I'm going to
move all my stuff over to pvgrub. Either way, allowing the DomU administrator
to change the kernel allows you to separate the 'virtual server
administrator' and 'hardware/Dom0 administrator' roles much better than
keeping the kernel in the Dom0.
> For the disk format I've tried all sorts of approach and I can't find
> any specific benefits one way or the other, however I have been
> leaning more towards representing disk images as partition /dev/sda1.
> The other options of course are that I present the target as an entire
> drive, or as 'xvda'
Largely preference. Personally, I like to give each DomU 2 LVM partitions
from the dom0 point of view, the partition is named after the DomUs name,
and the second partition is domuname_boot. this lets me put the PyGrub stuff
on it's own partition (meaning that a user can more freely screw up her
main partition and then reboot into PyGrub, and choose the rescue image
to fix the problem without pestering me) From within the DomU, the
user sees xvda and xvdb (or sda and sdb, depending) so the user can
partition xvdb however they like.
Long term, I'd like to integrate some kind of PyPXEboot type thing into
pvgrub, so that a user can boot her own kernels off disk, or alternately
hit a key and download pxe kernels (to get a rescue/install image or the
like, assuming they blew away the disk) but I've not spent the time to set
that working.
but I know people who prefer to partition sda in the Dom0 as
/dev/sda5 for vm 1, /dev/sda6 for vm 2, etc. Personally, I think that
is difficult to manage, but again, it's largely preference.
The real performance differences are between file: vs. phy: vs nfs or iscsi
(or AoE or gnbd or other 'load the filesystem from within the DomU over the
network') devices. phy: as a general rule, works well and is faster than
most anything else, but doesn't do live migration. Network file systems are
all pretty slow until you get into the 'silly expensive' range.
as for file: devices, they are easy, fine for testing. some people
find files easier to deal with organizationally. tap:// devices are a good
answer for those people, but tap: lacks many of the advantages of files.
tap: is picky about the filesystem and type of file... you aren't going
to be able to tap: a file over NFS, and tap: is weird with sparse files
(see qcow, but I think sparse files are generally a bad idea.)
> The kernel location question seems more interesting to me. I've had a
> lot of success using pygrub within the different environments I've
> managed, and I personally prefer this method, but I'm interested in
> hearing arguments as to why this should or shouldn't be done.
pvgrub overcomes most of the reasons why you wouldn't want to use PyGRUB.
the only time when I think it might be easier to keep the kernels in the
Dom0 is if you were using a kernel with no modules, and all your DomUs
always used the same kernel. In that case, it could be easier to keep
it in the Dom0. But in most situations where I've used Xen, keeping the
kernel in the DomU is much easier.
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home