[libvirt] [PATCH 0/3] esx: Storage volume up- and download

Daniel P. Berrange berrange at redhat.com
Tue Jul 3 20:40:19 UTC 2012


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




More information about the libvir-list mailing list