This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-users] Preferred Disk Image Format / Kernel Location

To: Trevor Orsztynowicz <trevoro@xxxxxxxxxxxxx>
Subject: Re: [Xen-users] Preferred Disk Image Format / Kernel Location
From: Luke S Crawford <lsc@xxxxxxxxx>
Date: 10 Sep 2008 21:26:31 -0400
Cc: xen-users@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 10 Sep 2008 18:25:42 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <5E474442-091E-4C1A-A83B-7729EE7F1957@xxxxxxxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <5E474442-091E-4C1A-A83B-7729EE7F1957@xxxxxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
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

<Prev in Thread] Current Thread [Next in Thread>