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