Re: [libvirt] [RFC v1 4/6] migration: Migration support for ephemeral hostdevs
On 05/13/2015 05:57 AM, Daniel P. Berrange wrote:
On Wed, May 13, 2015 at 11:36:30AM +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(a)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
> +void
> +qemuMigrationRestoreEphemeralDevices(virQEMUDriverPtr driver,
> + virConnectPtr conn,
> + virDomainObjPtr vm,
> + bool live)
> +{
> + qemuDomainObjPrivatePtr priv = vm->privateData;
> + virDomainDeviceDefPtr dev;
> + int ret = -1;
> + size_t i;
> +
> + VIR_DEBUG("Rum domain restore ephemeral devices");
> +
> + for (i = 0; i < priv->nEphemeralDevices; i++) {
> + dev = priv->ephemeralDevices[i];
> +
> + switch ((virDomainDeviceType) dev->type) {
> + case VIR_DOMAIN_DEVICE_NET:
> + if (live) {
> + ret = qemuDomainAttachNetDevice(conn, driver, vm,
> + dev->data.net);
> + } else {
> + ret = virDomainNetInsert(vm->def, dev->data.net);
> + }
> +
> + if (!ret)
> + dev->data.net = NULL;
> + break;
> + case VIR_DOMAIN_DEVICE_HOSTDEV:
> + if (live) {
> + ret = qemuDomainAttachHostDevice(conn, driver, vm,
> + dev->data.hostdev);
> + } else {
> + ret =virDomainHostdevInsert(vm->def, dev->data.hostdev);
> + }
This re-attach step is where we actually have far far far worse problems
than with detach. This is blindly assuming that the guest on the target
host can use the same hostdev that it was using on the source host.
(kind of pointless to comment on, since pkrempa has changed my opinion
by forcing me to think about the "failure to reattach" condition, but
could be useful info for others)
For a <hostdev>, yes, but not for <interface type='network'> (which
would point to a libvirt network pool of VFs).
This
is essentially useless in the real world.
Agreed (for plain <hostdev>)
Even if the same vendor/model
device is available on the target host, it is very unlikely to be available
at the same bus/slot/function that it was on the source. It is quite likely
neccessary to allocate a complete different NIC, or if using SRIOV allocate
a different function. It is also not uncommon to have different vendor/models,
so a completely different NIC may be required.
In the case of a network device, a different brand/model of NIC at a
different PCI address using a different guest driver shouldn't be a
problem for the guest, as long as the MAC address is the same (for a
Linux guest anyway; not sure what a Windows guest would do with a NIC
that had the same MAC but used a different driver). This points out the
folly of trying to do migration with attached hostdevs (managed at *any*
level), for anything other than SRIOV VFs (which can have their MAC
address set before attach, unlike non-SRIOV NICs).