On 06/04/16 15:11, Ján Tomko wrote:
On Wed, Apr 06, 2016 at 11:18:22AM +0300, Olga Krishtal wrote:
On 05/04/16 18:01, Ján Tomko wrote:
On Mon, Mar 14, 2016 at 07:00:39PM +0300, Olga Krishtal wrote:
Refreshes meta-information such as allocation, capacity, format, etc.
Ploop volumes differ from other volume types. Path to volume is the path
to directory with image file root.hds and DiskDescriptor.xml.
https://openvz.org/Ploop/format
Due to this fact, operations of opening the volume have to be done once
again. get the information.
To decide whether the given volume is ploops one, it is necessary to check
the presence of root.hds and DiskDescriptor.xml files in volumes' directory.
Only in this case the volume can be manipulated as the ploops one.
Such strategy helps us to resolve problems that might occure, when we
upload some other volume type from ploop source.
Signed-off-by: Olga Krishtal <okrishtal@xxxxxxxxxxxxx>
---
src/storage/storage_backend.c | 62 ++++++++++++++++++++++++++++++++++++--
src/storage/storage_backend.h | 5 ++++
src/storage/storage_backend_fs.c | 64 +++++++++++++++++++++++++++++++++++++---
src/util/virstoragefile.c | 7 +++--
4 files changed, 129 insertions(+), 9 deletions(-)
@@ -69,6 +109,7 @@ virStorageBackendProbeTarget(virStorageSourcePtr target,
int fd = -1;
int ret = -1;
int rc;
+ int format = VIR_STORAGE_FILE_AUTO;
virStorageSourcePtr meta = NULL;
struct stat sb;
@@ -84,14 +125,26 @@ virStorageBackendProbeTarget(virStorageSourcePtr target,
goto cleanup;
if (S_ISDIR(sb.st_mode)) {
- target->format = VIR_STORAGE_FILE_DIR;
- ret = 0;
- goto cleanup;
+ if (virStorageBackendIsPloopDir(target->path)) {
+ if (virStorageBackendRedoPloopUpdate(target, &sb, &fd,
+ VIR_STORAGE_VOL_FS_PROBE_FLAGS)
+ < 0)
+ goto cleanup;
+ /* Refresh information stored in DiskDescriptor.xml according
+ * to ploop image file content.*/
+ if (virStorageBackendPloopRestoreDesc(target->path) < 0)
+ goto cleanup;
Probing a volume should not change its contents - libvirt should only
refresh this XML when it changed the volume.
The rest looks good to me.
Jan
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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list