1.Description of problem: It report migration with shmem device is not supported , when I use the command "virsh migrate --live" to migrate a VM to another host. 2.Version-Release number of selected component (if applicable): libvirt 3.9.0 qemu-kvm 2.8.1 3.Steps to Reproduce: 1)add serveral lines below to guest configuration <shmem name='my_shmem1'> <model type='ivshmem-plain'/> <size unit='M'>4</size> </shmem> 2)virsh start guest-1 3)virsh migrate --live guest-1 qemu+ssh://target/system Actual results: error: Requested operation is not valid: migration with shmem device is not supported 4.Code Review When using the command “virsh create guset-1.xml,it produce corresponding command below. “qemu-kvm -device ivshmem-plain, id=shmem0,memdev=shmmem-shmem0,bus=pci.0,addr=0xa” I read qemu-doc.texi in qemu-2.8.1 source code, which have a explain of migrating ivshmem below “With device property @option{master=on}, the guest will copy the shared memory on migration to the destination host. With @option{master=off}, the guest will not be able to migrate with the device attached.” But libvirt library can not recognize the property “master=on”. When I directly used command "qemu-kvm -device ivshmem-plain,id=shmem0,memdev=shmmem-shmem0,master=on,bus=pci.0,addr=0xa” to launch a guest, it can migrate in live. I review the code about qemu code with branch 2.8.1 and master from https://github.com/libvirt/libvirt, it have no configuration definition for “master=on” The below is the part of source code domain_conf.h struct _virDomainShmemDef { char *name; unsigned long long size; int model; /* enum virDomainShmemModel */ struct { bool enabled; virDomainChrSourceDef chr; } server; struct { bool enabled; unsigned vectors; virTristateSwitch ioeventfd; } msi; virDomainDeviceInfo info; };
*** Bug 1657436 has been marked as a duplicate of this bug. ***
Could you please share the exact version of libvirt and qemu-kvm RPM packages you use? It's unclear whether you use RHEL packages, upstream versions or a combination of them.
I found the cause for this problem libvirt/src/qemu/qemu_migration.c if (vm->def->nshmems) { virReportError(VIR_ERR_OPERATION_INVALID, "%s", _("migration with shmem device is not supported")); return false; }
(In reply to Jiri Denemark from comment #3) > Could you please share the exact version of libvirt and qemu-kvm RPM packages > you use? It's unclear whether you use RHEL packages, upstream versions or a > combination of them. I found the cause for this problem libvirt/src/qemu/qemu_migration.c if (vm->def->nshmems) { virReportError(VIR_ERR_OPERATION_INVALID, "%s", _("migration with shmem device is not supported")); return false;
This is not the cause. If you remove the check, you won't see the error anymore, but that doesn't mean the domain will be migrated and keep working on the destination host. Anyway, please reply to comment 3.
(In reply to Jiri Denemark from comment #6) > This is not the cause. If you remove the check, you won't see the error > anymore, but that doesn't mean the domain will be migrated and keep working > on > the destination host. > > Anyway, please reply to comment 3. I read qemu-doc.texi in qemu-2.8.1 source code, which have a explain of migrating ivshmem below “With device property @option{master=on}, the guest will copy the shared memory on migration to the destination host. With @option{master=off}, the guest will not be able to migrate with the device attached.”
I don't think copying random parts of the bug description to comments helps with anything. Could you please reply to comment 3?
(In reply to Jiri Denemark from comment #3) > Could you please share the exact version of libvirt and qemu-kvm RPM packages > you use? It's unclear whether you use RHEL packages, upstream versions or a > combination of them. libvirt 3.9.0 qemu-kvm 2.8.1 these two package are compiled, not rpm
Thanks. I'm moving the bug to upstream tracker then.
Thank you for reporting this issue to the libvirt project. Unfortunately we have been unable to resolve this issue due to insufficient maintainer capacity and it will now be closed. This is not a reflection on the possible validity of the issue, merely the lack of resources to investigate and address it, for which we apologise. If you none the less feel the issue is still important, you may choose to report it again at the new project issue tracker https://gitlab.com/libvirt/libvirt/-/issues The project also welcomes contribution from anyone who believes they can provide a solution.