Description of problem: When trying to migrate from the local machine to another machine: # virsh migrate --live --tunnelled tmp0 qemu+ssh://root@ham0/system error: use virDomainMigrateToURI3 for peer-to-peer migration Version-Release number of selected component (if applicable): On local machine: libvirt-daemon-1.1.3.4-4.fc20.x86_64 On remote machine: libvirt-daemon-1.1.3.4-4.fc20.x86_64 How reproducible: 100% Steps to Reproduce: 1. Enter the migration command given in the description above. Additional info: libvirt XML of guest: <domain type='kvm' id='2'> <name>tmp0</name> <uuid>bd72dd7f-eaa4-4d47-a1d9-e5a7636eab9f</uuid> <memory unit='KiB'>1048576</memory> <currentMemory unit='KiB'>1048576</currentMemory> <vcpu placement='static'>4</vcpu> <resource> <partition>/machine</partition> </resource> <os> <type arch='x86_64' machine='pc-i440fx-1.6'>hvm</type> <boot dev='hd'/> </os> <features> <acpi/> <apic/> <pae/> </features> <cpu mode='host-model'> <model fallback='allow'/> </cpu> <clock offset='utc'> <timer name='rtc' tickpolicy='catchup'/> <timer name='pit' tickpolicy='delay'/> <timer name='hpet' present='no'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/bin/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none' io='native'/> <source file='/var/lib/libvirt/images/tmp0.img'> <seclabel model='selinux' labelskip='yes'/> </source> <target dev='sda' bus='scsi'/> <alias name='scsi0-0-0-0'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <controller type='scsi' index='0' model='virtio-scsi'> <alias name='scsi0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </controller> <controller type='usb' index='0'> <alias name='usb0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> </controller> <controller type='pci' index='0' model='pci-root'> <alias name='pci.0'/> </controller> <controller type='virtio-serial' index='0'> <alias name='virtio-serial0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </controller> <interface type='bridge'> <mac address='52:54:00:28:ec:8e'/> <source bridge='br0'/> <target dev='vnet0'/> <model type='virtio'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> <console type='pty' tty='/dev/pts/0'> <source path='/dev/pts/0'/> <target type='virtio' port='0'/> <alias name='console0'/> </console> <input type='tablet' bus='usb'> <alias name='input0'/> </input> <input type='mouse' bus='ps2'/> <graphics type='vnc' port='5900' autoport='yes' listen='127.0.0.1'> <listen type='address' address='127.0.0.1'/> </graphics> <video> <model type='cirrus' vram='9216' heads='1'/> <alias name='video0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> <memballoon model='virtio'> <alias name='balloon0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </memballoon> </devices> <seclabel type='dynamic' model='selinux' relabel='yes'> <label>system_u:system_r:svirt_t:s0:c711,c1020</label> <imagelabel>system_u:object_r:svirt_image_t:s0:c711,c1020</imagelabel> </seclabel> </domain>
Seems to be a problem with virsh. In any case I posted this patch: https://www.redhat.com/archives/libvir-list/2014-May/msg00300.html
I sent a slightly different patch upstream: https://www.redhat.com/archives/libvir-list/2014-May/msg00745.html
I'm happy to go with whatever patch you want.
commit 7bdc7702f31ac9123e1ec9787368a8fbfe365496 Author: Jiri Denemark <jdenemar> Date: Thu May 22 13:18:21 2014 +0200 Fix error message when TUNNELLED flag is used in non-p2p migration The current error message is error: use virDomainMigrateToURI3 for peer-to-peer migration which is correct but a bit misleading because the client did not specify VIR_MIGRATE_PEER2PEER flag. This patch changes the error message to error: cannot perform tunnelled migration without using peer2peer flag which is consistent with the error reported by older migration APIs. Reported by Rich Jones in https://bugzilla.redhat.com/show_bug.cgi?id=1095924