On Tue, Jul 03, 2012 at 09:51:52PM +0200, Matthias Bolte wrote: > 2012/7/3 Doug Goldstein <cardoe@xxxxxxxxxx>: > > On Mon, Jul 2, 2012 at 4:44 PM, Matthias Bolte > > <matthias.bolte@xxxxxxxxxxxxxx> wrote: > >> I started the download part and the stream driver quite a while ago > >> but stopped and put it aside as I realized that the storage volume > >> API up- and download functions assume one file per volume. This is a > >> problem with ESX as a VMDK can consist of two files. To solve this > >> now I added two new flags: METADATA and CONTENT. With this flags the > >> user can specify which part of such a volume to transfer. See patch > >> 3/3 for more details. > >> > > > > Well technically VMDKs can have more than 2 files per disk. They have > > the .vmdk which is just the metadata but then the content pieces can > > be divided into 2G chunks. Would this be something you'd want to > > account for in this patch series or a future update? > > You're right. I forgot about the possibility for having the content > split into 2GB chunks. Well, I have no idea how to represent this in > the libvirt storage API except by adding CONTENT1, CONTENT2, CONTENT3, > ... flags. In the case of a split VMDK file, I'd expect that the list of virStorageVolPtr objects corresponds to the .vmdk metadata files. Do not expose each individual data file as a volume. We could perhaps extend the XML format for virStorageVolPtr to list the names of the data files. The upload/download streaming APIs would transparently write to the appropriate data file depending on what offset you currently access. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list