[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [RFC v1 4/6] migration: Migration support for ephemeral hostdevs



On Wed, May 13, 2015 at 10:36:34AM +0200, Peter Krempa wrote:
> On Wed, May 13, 2015 at 11:36:30 +0800, Chen Fan wrote:
> > add migration support for ephemeral host devices, introduce
> > two 'detach' and 'restore' functions to unplug/plug host devices
> > during migration.
> > 
> > Signed-off-by: Chen Fan <chen fan fnst cn fujitsu com>
> > ---
> >  src/qemu/qemu_migration.c | 171 ++++++++++++++++++++++++++++++++++++++++++++--
> >  src/qemu/qemu_migration.h |   9 +++
> >  src/qemu/qemu_process.c   |  11 +++
> >  3 files changed, 187 insertions(+), 4 deletions(-)
> > 
> > diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
> > index 56112f9..d5a698f 100644
> > --- a/src/qemu/qemu_migration.c
> > +++ b/src/qemu/qemu_migration.c
> > @@ -3384,6 +3384,158 @@ qemuMigrationPrepareDef(virQEMUDriverPtr driver,
> >      return def;
> >  }
> >  
> > +int
> > +qemuMigrationDetachEphemeralDevices(virQEMUDriverPtr driver,
> > +                                    virDomainObjPtr vm,
> > +                                    bool live)
> > +{
> > +    qemuDomainObjPrivatePtr priv = vm->privateData;
> > +    virDomainHostdevDefPtr hostdev;
> > +    virDomainNetDefPtr net;
> > +    virDomainDeviceDef dev;
> > +    virDomainDeviceDefPtr dev_copy = NULL;
> > +    virCapsPtr caps = NULL;
> > +    int actualType;
> > +    int ret = -1;
> > +    size_t i;
> > +
> > +    VIR_DEBUG("Rum domain detach ephemeral devices");
> > +
> > +    if (!(caps = virQEMUDriverGetCapabilities(driver, false)))
> > +        return ret;
> > +
> > +    for (i = 0; i < vm->def->nnets;) {
> > +        net = vm->def->nets[i];
> > +
> > +        actualType = virDomainNetGetActualType(net);
> > +        if (actualType != VIR_DOMAIN_NET_TYPE_HOSTDEV) {
> > +            i++;
> > +            continue;
> > +        }
> > +
> > +        hostdev = virDomainNetGetActualHostdev(net);
> > +        if (hostdev->mode != VIR_DOMAIN_HOSTDEV_MODE_SUBSYS ||
> > +            hostdev->source.subsys.type != VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI ||
> > +            !hostdev->ephemeral) {
> > +            i++;
> > +            continue;
> > +        }
> > +
> > +        dev.type = VIR_DOMAIN_DEVICE_NET;
> > +        dev.data.net = net;
> > +
> > +        dev_copy = virDomainDeviceDefCopy(&dev, vm->def,
> > +                                          caps, driver->xmlopt);
> > +        if (!dev_copy)
> > +            goto cleanup;
> > +
> > +        if (live) {
> > +            /* nnets reduced */
> > +            if (qemuDomainDetachNetDevice(driver, vm, dev_copy) < 0)
> > +                goto cleanup;
> 
> So this is where the fun begins. qemuDomainDetachNetDevice is not
> designed to be called this way since the detach API where it's used
> normally returns 0 in the following two cases:
> 
> 1) The detach was successfull, the guest removed the device
> 2) The detach request was successful, but guest did not remove the
> device yet
> 
> In the latter case you need to wait for a event to successfully know
> when the device was removed. Since this might very well happen the code
> will need to be changed to take that option into account. Please note
> that that step will make all the things really complicated.

Even more fun

  3) The detach request was successful, but the guest is going to
     ignore it forever

Really, this is not something we want to be deciding policy for inside
libvirt. It is no end of trouble and we really must let the mgmt app
decide how it wants this kind of problem handled.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]