Re: [libvirt] [PATCH 0/3] esx: Storage volume up- and download
2012/7/3 Daniel P. Berrange <berrange(a)redhat.com>:
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.
That's how its implemented also also how vSphere API sees VMDKs. The
metadata .vmdk represents the volume. Where the content is is an
implementation detail.
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 individual datafiles are currently not listed as volumes and will
never be. Also I see no gain in exposing them in the volume XML.
The upload/download streaming APIs would
transparently write to the appropriate data file depending on what
offset you currently access.
I think that's good idea and will work but require a more complex
implementation especially in cases when a virStreamSend/Recv call
crosses a 2GB boundary.
--
Matthias Bolte
http://photron.blogspot.com