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: FW: [Xen-devel] questions about production use

To: "Williamson, Mark A" <mark.a.williamson@xxxxxxxxx>
Subject: Re: FW: [Xen-devel] questions about production use
From: Nick Craig-Wood <ncw1@xxxxxxxxxxxxxxxx>
Date: Mon, 26 Jan 2004 20:19:38 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 26 Jan 2004 20:21:27 +0000
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: <CF8C1D789F0AD0459192CDEAF3A7EC5001E53BDE@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
References: <CF8C1D789F0AD0459192CDEAF3A7EC5001E53BDE@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
User-agent: Mutt/
On Mon, Jan 26, 2004 at 03:58:29PM -0000, Williamson, Mark A wrote:
> > Sort of like LVM but run by Xen?  Tha sounds very interesting.
> Yes, it is rather like LVM.  The user space virtual disk tools manage
> allocation of disk extents and keep track of which extents belong to
> which virtual disks.  Then when you create the Virtual Block Device that
> domains will use to access that virtual disk, Xen does all the address
> translation, so it just appears like another other Xen block device to
> the guest OS.

That sounds nice and efficient and extensible.

I'm a little concerned about keeping lots of data in a potentially
non-standard disk format.  I just hope its less troublesome than LVM
which always seems to be losing its metadata and hence all the data on
the disks!

> >> [me talking about the free pool]
> > 
> > That sounds like just the job.  We'd also want to be able to access
> > all the virtual disks from Domain0 for administrative purposes (backup
> > / transfer to a new host etc) but I guess that is possible.
> Xen 1.2 and above have "automatic plumbing" of virtual block devices:
> you create a virtual block device for a domain and it "just knows" that
> it's there, a bit like hot plugging.  You can use this to add a virtual
> disk to a device node in dom0, do stuff with it, then remove it from
> dom0 again.


>  However, it is not safe to have two writers to one filesystem

Sure.  We'd either use it for migration in which case domX would be
stopped, or for a hot backup in which case it wouldn't but it would be
read only (no this isn't an ideal way to take a backup but its better
than nothing!).

> >> [me talking about re-exporting devices from dom0]
> > 
> > Excellent!
> > 
> > How much of this and the above is implemented now?  Should I be
> > checking out Xen 1.2 and reading the docs?
> Virtual Disks are in the 1.2 and unstable trees right now.


> There was an implementation of virtual disks in versions 1.0 and 1.1
> but the rewrite adds support for the new Python-based toolchain and
> some new features.  AFAIK nobody has used the new VD tools "in
> anger" yet but it's been working pretty solidly in testing.

I'll see whether I can blow them up then ;-)

> At some stage after we've got 1.2 released (which will be soon) I'll
> be adding some more whizzy features to the unstable tree but these
> would probably be backwards compatible with 1.2.
> The virtual disk howto is now slightly out of date but I will be
> updating it presently.  If you get stuck, there's always interactive
> help on the mailing list ;-) - I can feed back any discussions we have
> to make the docs better.


> The ability to re-export devices from one domain that just appear like
> an ordinary Xen block device to another domain is still at the design
> stage, as yet.  However, this is fairly high on the priority list at the
> moment...

This would be a useful feature for us and it would alleviate the
potential pain of having data stored in non-standard disk formats.
Howewever I can see the virtual disk space would be faster.

Thanks for your help!

Nick Craig-Wood

The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
Xen-devel mailing list