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

[Olga Krishtal]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20160406/1ae210ad/attachment-0001.htm>