Re: [PATCH 6/7] storage:dir: adapts .refreshVol .refreshPool for ploop volumes

[Olga Krishtal <okrishtal@xxxxxxxxxxxxx>]

On 06/04/16 16:07, Ján Tomko wrote:

On Wed, Apr 06, 2016 at 03:57:17PM +0300, Olga Krishtal wrote:

On 06/04/16 15:11, Ján Tomko wrote:

On Wed, Apr 06, 2016 at 11:18:22AM +0300, Olga Krishtal wrote:

The thing is that if we changed the size, the content of root.hds and
had left the old DiskDeskriptor.xml - it becomes impossible to operate.
I mean that DiskDescriptor.xml stores this info - size, Celinders,
Sectors, and what is more important - all information about snapshot.
In the situation when we have uploaded previously snapshoted volume -
the content of volume and DiskDescriptor will be inconsistent.
And work upon such volume will be impossible.
But if you have any idea, where such refresh of DiskDescriptor.xml could
be done - I will be glad to know.

DiskDeskriptor should be changed at the same time as root.hds -
if libvirt does the resize/content change, it should refresh the XML as
part of the API that changes the volume.

Libvirt's pool refresh or vol refresh should only update libvirtd's
in-memory metadata to match the on-disk state.

DiskDescriptor.xml content is based on root.hsd - ploop 
restore-desciptor uses root.hds header.
 From this point of view I just copy the info from root.hds yo DD.xml

If the on-disk state was left inconsistent by some other application,
it's a problem of that application. I don't think libvirt should be
working around that.

Jan

But what about the uploadVol. As I understand volume ulpload is 
asynchronous operation - I mean,
that virStorageVolUpload will returned before the content will be updated:
  if (virStorageVolUpload(vol, st, offset, length, 0) < 0) { ------ 
returned from ulpoad, but I can not generate new DiskDeskriptor.xml it 
is too early. I need volume with new content.
         vshError(ctl, _("cannot upload to volume %s"), name);
         goto cleanup;
     }

     if (virStreamSendAll(st, cmdVolUploadSource, &fd) < 0) { ----- I 
can do it. Volume is ready to use.
         vshError(ctl, _("cannot send data to volume %s"), name);
         goto cleanup;
     }
I

storageVolUpload registers virStorageVolFDStreamCloseCb as the callback
that is executed after the volume has finished uploading.
The virStorageVolPoolRefreshThread is only called by
virStorageVolFDStreamCloseCb and looks like it could regenerate
DiskDeskriptor.xml before refreshing the pool.

Jan

Ok, thanks. I'll try to do it.
I have one more question:  we have ploop volume, the xml that describing the vz containers usually looks like:
<devices>
 <filesystem type='mount'>
We do not use disk, when we create the ct.
I want to add new type 'volume'.
This will add the possibility to use the volume as the source for ct root directory.
It will look smth like:
<devices>
 <filesystem type='mount'>
<source pool='pool name' volume='volume name'>
Would you be so kind to think it over: do you like such an idea.

I have look through code - it is also possible for lxc containers to use filesystem upon volume.

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list