On Tue, Jul 03, 2012 at 09:51:52PM +0200, Matthias Bolte wrote:
2012/7/3 Doug Goldstein <cardoe@gentoo.org>:
On Mon, Jul 2, 2012 at 4:44 PM, Matthias Bolte <matthias.bolte@googlemail.com> 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 :|