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