I've managed to come up with something pretty neat -- a shared base
image with unionfs providing an overlay for a "delta" filesystem that
allows each host to customize the image to their heart's content while
storing only the changes (deltas). I *love* how xen and open source
work. :-)
xen config exports to the domUs a file-backed master.img which
contains a base root filesystem as /dev/hda1. Then each domU gets
their own LVM-backed logical volumes for root (/dev/hdb1) and swap
(/dev/hdc1). This allows me to grow/shrink partitions as necessary.
And because these partitions only contain changes, they don't use as
much data. I customized the initrd process to union mount the base
root filesystem with the "delta" filesystem and overlay that as root.
This works pretty well, so far -- I'm just trying to make this work
with NFS-exported file systems for maximum flexibility.
Anyway, this may not really be a xen issue, but I thought I'd ask. I
was trying to get several domU's to share a base LVM-backed
filesystem, but when I fire up a second domain using the same fs, it
says that the vbd is already in use. I take it isn't possible to have
multiple mounts of an LVM-backed volume? That's one reason why I had
to use a file-backed root fs above.
Also... As I'm not too sure about this, is it *safe* for a file-backed
root fs to be shared across multiple domUs? I have the initrd mount it
as read-only BUT the xen config has to make it writable. Making it
read only in the config causes the mount process to spit an error
(EXT3 INFO requires write access ...).
-gino
On 5/25/05, Gino LV. Ledesma <gledesma@xxxxxxxxx> wrote:
> On 5/25/05, Anthony Liguori <aliguori@xxxxxxxxxx> wrote:
> > Gino LV. Ledesma wrote:
> >
> > >Hi, list
> > >
> > >Has anyone gotten something similar to work? Any ideas / tips /
> > >comments / suggestions in doing so? I'm tweaking my xen RPM spec file
> > >to support unionfs and right now just looking at the boot up process
> > >of getting the domain to mount something else on top of the exported
> > >root file system (either a file-backed VBD or yet another NFS export).
> > >
> > >
> > This is actually a large part of the paper for this presentation at OLS:
> >
> > http://www.linuxsymposium.org/2005/view_abstract.php?content_key=117
> >
> > There's a number of approaches to solving this problem. unionfs would
> > be ideal but it's a bit unstable. Another approach is to keep certain
> > directories read only (like /usr, /bin, /lib, /sbin, etc.) and others
> > read write (/etc, /var/, etc.). This will get you pretty far.
>
> Thanks for the reply. I guess this is one of the most oftens suggested
> approaches. The two goals that I'd like to meet are:
> 1. Storage flexibility (resize as necessary) -- LVM looks good to go,
> though in our setup where we can use NetApps, NFS would be another
> approach.
> 2. Ease of administration / maintenance -- Some of the issues I'm wary
> about when going unionfs is that if we make changes to the underlying
> filesystem (e.g. OS upgrade) and there are changes on the overlay,
> conflicts might occur.
>
> I'll look to doing both -- I'd like to keep things simpler, as there'd
> be less chances of breaking things.
>
> Thanks again.
>
> gino ledesma
>
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home