On Mon, Oct 29, 2007 at 02:49:16PM +0000, Richard W.M. Jones wrote: > Daniel P. Berrange wrote: > >As we did with virsh attach-disk/attach-interface, vs attach-device > >I think it would be helpful to provide a 'virsh vol-create' variant > >which took a handful of explicit args as an alternative to the XML, > > > >eg virsh pool-create --type fs xenimages /var/lib/xen/images > > Yes, vital really, and even better if it's a libvirt call. > > >NB, <format> is actually optional - it defaults to raw. Permissions > >should be optional, but currently aren't. Allocation is optional too, > >without it, you will get a sparse file. > > I didn't really understand the semantics of <allocation>. It should be > <sparse/> AFAICS. This underlines actually why XML is so much more > slippery than real typing. Basically, capacity is intended to be the logical size, while allocation is the amount of space used on the host. So in the case of raw files, capacity is the size we ftruncate to, while allocation is actual disk blocks consumed. With VMDK / QCOw & other auto-grow disk formats, capacity is a piece of metadata embedded in the disk metdata - they don't use sparse files on the host disk, while again allocation is disks blocks allocated up front. So sparse is only really a concept for raw files where you litterally do have a sparsely allocated file on the filesystem. IIRC some logical volume managers also have a concept of volume size, vs volume allocation, allowing blocks from the VG to be dynamically allocated to LV, rather than fixed upfront. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list