On Thu, Aug 05, 2004 at 06:56:58PM +0100, Ian Pratt wrote:
> > One feature that would be really nice to have is the ability to easily
> > manage the disk images used by the Xen domains, so that I could, for
> > example, quickly load a particular Linux distribution on a set of LVM
> > logical volumes, then start a new Xen instance with those.
>
> I'd certainly like to see more support for this.
>
> Copy-on-write (CoW) sparse disks are pretty high on everyone's
> wish list. In principle, it should be possible to do this today,
> but it's a pain to setup: use LVM snapshot with the log device as
> a loop interface connected to a sparse file.
[Just to make sure we're on the same page since I didn't specify
earlier, I'm using LVM2 and not LVM1.]
I haven't gotten snapshots working yet...in my last attempts, I've
gotten a kernel NULL pointer dereference when trying to create a
snapshot. I haven't put much effort into tracking the problem down, so
I'm not even sure if it's Xen-related yet, but I'd like to look into it
more soon. Perhaps with XenoLinux 2.6 ready to run as Domain 0, I can
give that a shot as well--I'm currently using 2.4.
At the moment, I'm simply using LVM as a convenient way to create and
destroy partitions for new domains. (Disk space is cheap, and I've
found this easier to manage than I think using sparse files and the
loopback driver would be.)
> [The LVM snapshot device is a bit 'odd' for our purposes as
> writes occur in-place, with the old block contents being copied
> to a log device. It would make more sense if we slightly modified
> the code to have the writes go to the log and leave the original
> device pristine. ]
Very true, but I don't know how much work this would be. Since I
haven't been able to test, I don't know how multiple COW images of the
same underlying disk would work in the current implementation (if at
all). They would certainly work better with the behavior you describe.
> It would certainly be very nice to have xend assist with setting
> all this up, and have a nice way of naming images etc (leveraging
> LVM wherever possible).
>
> xend is intended to be extensible for exactly this sort of
> thing. Mike's writing a manual for it, which should be going into
> the tree RSN.
I've been reading over some of the code for xend the last few days, so I
at least have some ideas for how to proceed. I'm hoping that I wouldn't
be stepping on anyone else's toes or duplicating work if I did work on
this.
Oh, and to everyone who has helped build Xen: Thanks! It's been a lot
of fun to use.
--Michael Vrable
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
Home