[PATCH] qemu: migration: don't open storage driver too early

Peter Krempa pkrempa at redhat.com
Mon Oct 12 08:01:50 UTC 2020


On Mon, Oct 12, 2020 at 09:39:33 +0200, Michal Privoznik wrote:
> On 10/12/20 1:44 AM, Cole Robinson wrote:
> > If storage migration is requested, and the destination storage does
> > not exist on the remote host, qemu's migration support will call
> > into the libvirt storage driver to precreate the destination storage.
> > 
> > The storage driver virConnectPtr is opened too early though, adding
> > an unnecessary dependency on the storage driver for several cases
> > that don't require it. This currently requires kubevirt to install
> > the storage driver even though they aren't actually using it.
> > 
> > Push the virGetConnectStorage calls to right before the cases they are
> > actually needed.
> > 
> > Signed-off-by: Cole Robinson <crobinso at redhat.com>
> > ---
> >   src/qemu/qemu_migration.c | 17 ++++++++++-------
> >   1 file changed, 10 insertions(+), 7 deletions(-)
> > 
> > diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
> > index 2000c86640..99a6b41483 100644
> > --- a/src/qemu/qemu_migration.c
> > +++ b/src/qemu/qemu_migration.c
> > @@ -169,8 +169,7 @@ qemuMigrationSrcRestoreDomainState(virQEMUDriverPtr driver, virDomainObjPtr vm)
> >   static int
> > -qemuMigrationDstPrecreateDisk(virConnectPtr conn,
> > -                              virDomainDiskDefPtr disk,
> > +qemuMigrationDstPrecreateDisk(virDomainDiskDefPtr disk,
> >                                 unsigned long long capacity)
> >   {
> >       int ret = -1;
> > @@ -181,6 +180,7 @@ qemuMigrationDstPrecreateDisk(virConnectPtr conn,
> >       g_auto(virBuffer) buf = VIR_BUFFER_INITIALIZER;
> >       const char *format = NULL;
> >       unsigned int flags = 0;
> > +    virConnectPtr conn = NULL;
> 
> Wee tiny nitpick. If you're touching this might switch it g_auto:
> 
> g_autoptr(virConnect) conn = NULL;
> 
> and drop the explicit unref.

In this specific case I'd stay with explicit cleanup. If you look at the
cleanup section we have a 'vol', 'pool' and 'conn' pointer. They are
interconnected. While libvirt internally does refcounting, cleaning them
up in random order might seem wrong.




More information about the libvir-list mailing list