Whoops ;-) - here''s the reply I sent to Nick''s e-mail. Accidentally forgot to send it to the list as well...>> [me talking about virtual disks] > > 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.>> [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 (unless the filesystem explicitly supports it, which most don''t) and even with one reader and one writer, it''s probably not a good idea - you''ll have to take virtual disks offline (by at least unmounting them in the domain that''s using them) before accessing them from dom0. I expect you''d gathered this, though...>> [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. 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... HTH, Mark ------------------------------------------------------- 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
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 filesystemSure. 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Williamson, Mark A
2004-Jan-26 22:41 UTC
RE: 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 welcome. 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. Mark ------------------------------------------------------- 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel