Re: FW: questions about production use

[Nick Craig-Wood <ncw1@axis.demon.co.uk>]

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.

OK.

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

Excellent!

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

Great.

> 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
-- 
Nick Craig-Wood
ncw1@axis.demon.co.uk


-------------------------------------------------------
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.
http://www.eclipsecon.org/osdn