Wouldn't it make more sense to alter the COW driver to do just that?
writes goto the COW partition, leaving the original pristine for
multiple COW targets? The way it is now, it sounds like you can only
have one COW device using the origin partition.....
On Thu, 2004-08-05 at 14:02, Michael Vrable wrote:
> 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
-------------------------------------------------------
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