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: "Nick Craig-Wood" <ncw1@xxxxxxxxxxxxxxxx>
Subject: RE: FW: [Xen-devel] questions about production use
From: "Williamson, Mark A" <mark.a.williamson@xxxxxxxxx>
Date: Mon, 26 Jan 2004 22:41:59 -0000
Cc: <xen-devel@xxxxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 26 Jan 2004 22:44:07 +0000
Envelope-to: steven.hand@xxxxxxxxxxxx
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
Thread-index: AcPkSb4ZhgIlX4aLQWWThNbZqBOxjgAAUXAw
Thread-topic: FW: [Xen-devel] questions about production use
> 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!

The metadata for virtual disks is stored in an SQLite database on Dom0's
filesystem.  It's probably good practice to keep it backed up, since you
won't be able to access the virtual disks without it, since the Dom0
tools wouldn't know where they are.

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

Well, if you find it works OK ;-)

> > 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 ;-)

That would be very welcome.  I'll try to fix anything you find problems
with.  Feature suggestions are also welcome - you know best what things
would be useful, so please let us know!  There's a TODO list in
XenoUtil.py (which contains the actual implementation) with some things
that I'm considering doing anyway.  Any more ideas or comments are

Note that you need sqlite and pysqlite installed for virtual disk
management to work.  There's a tarball at
http://www.cl.cam.ac.uk/netos/xen/downloads/pysqlite-all-2.8.11-1.tgz of
all the files they need, or you can install them separately.

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

I've now updated the HOWTO, so that should end up on bkbits at some
stage soonish.

>> [me talking about re-exporting devices / files]
> 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.

I would expect virtual disks to be faster, since it is fairly close to
being raw disk access, rather than having to indirect through a
filesystem.  That said, disk performance should be as good or better
than you'd get from UML anyway.


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