All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.