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-devel] Xen & Automated Disk Management for Domains

To: Michael Vrable <mvrable@xxxxxxxxxxx>
Subject: Re: [Xen-devel] Xen & Automated Disk Management for Domains
From: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
Date: Thu, 05 Aug 2004 23:26:09 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx, Ian.Pratt@xxxxxxxxxxxx
Delivery-date: Thu, 05 Aug 2004 23:39:00 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Your message of "Thu, 05 Aug 2004 12:02:22 PDT." <20040805120222.A20439@xxxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
> 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.

AFAIK, LVM2 broke snapshot functionality, but that it'll be going
back into 2.6.8 (which will likely be released in the next week
or two).

> > [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.

I believe it should b e pretty easy to change the
behaviour. Alternatively, Bin Ren's CoW md block driver is
believed to work and is rather simpler....

> > 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.

I'm certainly not aware of anyone working in this area.


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