From: Michael Vrable <mvrable@cs.ucsd.edu>
To: xen-devel@lists.sourceforge.net
Subject: Re: Xen & Automated Disk Management for Domains
Date: Thu, 5 Aug 2004 12:02:22 -0700 [thread overview]
Message-ID: <20040805120222.A20439@gradlab.ucsd.edu> (raw)
In-Reply-To: <E1BsmU7-0000NZ-00@mta1.cl.cam.ac.uk>; from Ian.Pratt@cl.cam.ac.uk on Thu, Aug 05, 2004 at 06:56:58PM +0100
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
next prev parent reply other threads:[~2004-08-05 19:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-05 17:27 Xen & Automated Disk Management for Domains Michael Vrable
2004-08-05 17:56 ` Ian Pratt
2004-08-05 19:02 ` Michael Vrable [this message]
2004-08-05 21:36 ` Brian Wolfe
2004-08-05 22:31 ` Ian Pratt
2004-08-05 22:26 ` Ian Pratt
2004-08-06 21:49 ` Michael Vrable
2004-08-06 22:13 ` Ian Pratt
-- strict thread matches above, loose matches on Subject: below --
2004-08-07 11:33 Björn Sessler
2004-08-07 12:38 ` Christian Limpach
2004-08-07 13:11 ` Ian Pratt
2004-08-07 14:21 ` Christian Limpach
2004-08-07 14:35 ` Ian Pratt
2004-08-08 9:52 ` Björn Sessler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040805120222.A20439@gradlab.ucsd.edu \
--to=mvrable@cs.ucsd.edu \
--cc=xen-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.