[libvirt] [PATCH] send default USB controller in xml to destination during migration on PPC64

[Shivaprasad bhat]

Ping... Can someone review this simple patch ?

Thanks,
Shiva

On Wed, Mar 2, 2016 at 8:39 PM, Shivaprasad G Bhat <
shivaprasadbhat at gmail.com> wrote:

> The default USB controller is not sent to destination as the older versions
> of libvirt(0.9.4 or earlier as I see in commit log of 409b5f54) didn't
> support them. For some archs where the support started much later can
> safely send the USB controllers without this worry. For now, changing the
> checks to allow PPC64 here. If we can track the historical support for
> other archs, the changes can be extrapolated to them too.
>
> The patch fixes a bug that, if the USB controller happens to occupy
> a slot after disks/interfaces and one of them is hot-unplugged, then
> the default USB controller added on destination takes the smallest slot
> number and that would lead to savestate mismatch and migration
> failure.
>
> Signed-off-by: Shivaprasad G Bhat <sbhat at linux.vnet.ibm.com>
> ---
>  src/qemu/qemu_domain.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> index 9044792..6ecc0e2 100644
> --- a/src/qemu/qemu_domain.c
> +++ b/src/qemu/qemu_domain.c
> @@ -2226,7 +2226,7 @@ qemuDomainDefFormatBuf(virQEMUDriverPtr driver,
>                  usb = def->controllers[i];
>              }
>          }
> -        if (usb && usb->idx == 0 && usb->model == -1) {
> +        if (!ARCH_IS_PPC64(def->os.arch) && usb && usb->idx == 0 &&
> usb->model == -1) {
>              VIR_DEBUG("Removing default USB controller from domain '%s'"
>                        " for migration compatibility", def->name);
>              toremove++;
>
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20160426/77260680/attachment-0001.htm>