Hi all. Short summary on DV's request ;) I ran into a problem migrating kvm machines with libvirt-0.6.5: 1) At first, using the same syntax for the migrateuri as with xen (just the IP) did not work... looking into the source code (! ;) ), I found a different syntax for qemu. 2) using tcp://<ip>:<port> just produced an 'unknown failure' on the receiving side: root@loadgen137:~> virsh -c qemu:///system migrate --live kvm-testnode-vnode3 qemu+tcp://10.192.11.136/system?no_verify=1 tcp://10.192.11.136:12345 error: Unknown failure (Note: it was working like a charm when I eliminated the migrateuri altogether, but this was not an option in all my work environments, since one of them doesn't feature DNS, breaking migration on the hostname alone (and keeping /etc/hosts in sync on n machines is something I'd like to avoid, if possible ;) )) 3) removing the case distinction and the handling of the migrateuri in the qemudDomainMigratePrepare2 function in qemu_driver.c entirely (if-statement, and full else-part) solved both my issues. --- The issue seems to be current with 0.7.1 as well (at least I did receive the same error message - I did not investigate further) --- My 2ct: ;) I think that a wrapper like libvirt should consequently abstract lower level details (such as 'qemu', or 'xen') as much as possible (that's what libvirt is for, I guess :) ). Since the removal of the URI handling solves both the issue _and_ eliminates a case distinction between xen and qemu (painlessly, as far as I can see), I'd suggest perhaps considering the removal. :) As to the sending side specification of transfer ports: I think there should always be a possiblity to leave port selection up to libvirt, as the sending side does not necessarily an oversight over the free ports on the receiving side. (I feel that the reason for the different syntax including mandatory :port part was motivated by the wish to allow users to specify ports on the sending side) Cheers, Gregor Schaffrath. -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list