[libvirt] [PATCH 5/6] qemu: snapshot: Properly handle image locking
Peter Krempa
pkrempa at redhat.com
Tue Jan 10 15:33:29 UTC 2017
On Sat, Jan 07, 2017 at 13:37:48 -0500, John Ferlan wrote:
>
>
> On 12/16/2016 11:24 AM, Peter Krempa wrote:
> > Images that became the backing chain of the current image due to the
> > snapshot need to be unlocked in the lock manager. Also if qemu was
> > paused during the snapshot the current top level images need to be
> > released until qemu is resumed so that they can be acquired properly.
> >
> > Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1191901
> > ---
> > src/qemu/qemu_driver.c | 17 +++++++++++++++++
> > 1 file changed, 17 insertions(+)
> >
> > diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
> > index 742b6ceda..13da035c2 100644
> > --- a/src/qemu/qemu_driver.c
> > +++ b/src/qemu/qemu_driver.c
> > @@ -14452,6 +14452,23 @@ qemuDomainSnapshotCreateDiskActive(virQEMUDriverPtr driver,
> > virStorageFileUnlink(diskdata[i].src) < 0)
> > VIR_WARN("Unable to remove just-created %s", diskdata[i].src->path);
> > }
> > + } else {
> > + /* on successful snapshot we need to remove locks from the now-old
> > + * disks and if the VM is paused release locks on the images since qemu
> > + * stopped using them*/
> > + bool paused = virDomainObjGetState(vm, NULL) != VIR_DOMAIN_RUNNING;
> > +
> > + for (i = 0; i < snap->def->ndisks; i++) {
> > + if (!diskdata[i].disk)
>
> Should this be disk.src? Or handle the _NONE case? since src only gets
> filled in for that.
The entries in the 'diskdata' array are filled only if they are not
_NONE. !diskdata[i].disk->src would crash on the missing entries since
.disk would be NULL. !diskdata[i].disk || !diskdata[i].disk->src is
redundant since the src member is mandatory for a disk object, thus
always present if .disk is not NULL.
Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170110/014ff7cb/attachment-0001.sig>
More information about the libvir-list
mailing list