Description of problem: If "domain rename" is supported, we can't use it without specify "<migrateuri>" meanwhile. If they are really needed be together to work. probly we should update the help strings and document. such as "<dname> rename to new name during migration (if supported), must use with <migrateuri>". but not just says "<migrateuri>" can be omitted. so may be the end-user will try to use like this: # virsh migrate --live toy qemu+ssh://${target_host_ip}/system toy-f1 definitely, it will be failed. If they aren't needed be together to work, probly we should provide "options" to the migrate command to seperate them. such as "virsh migrate --live toy qemu+ssh://${target_host_ip}/system --dname toy-f1". following is part of the help strings in virsh: --undefinesource undefine VM on source --suspend do not restart the domain on the destination host <domain> domain name, id or uuid <desturi> connection URI of the destination host <migrateuri> migration URI, usually can be omitted <dname> rename to new name during migration (if supported) Version-Release number of selected component (if applicable): virsh # version Compiled against library: libvir 0.7.8 Using library: libvir 0.7.8 Using API: QEMU 0.7.8 Running hypervisor: QEMU 0.12.1 How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: definitely, it will be failed, because it will parse "toy-f1" as a tcp URI. Expected results: if <dname> and <migrateuri> must be used together, improve the document and help strings. if they need not be used together, provide some options to tell the command line parser seperate them, such as --migrateuri qemu+ssh://${target_host_ip}/system --dname toy-f1 Additional info:
[root@dhcp-66-70-* ~]# rpm -q libvirt libvirt-client qemu-kvm libvirt-0.7.8-0.pre20100330.el6.x86_64 libvirt-client-0.7.8-0.pre20100330.el6.x86_64 qemu-kvm-0.12.1.2-2.32.el6.x86_64 Regards osier
This is a limitation of the way the virsh migrate command was written. It really should have used flags for the optional stuff, instead of positional args. Not sure best way to re-write this. Perhaps we should allow for any of the named positional args to be set via the flags at the same time.
I'm pretty sure this limitation has been long since fixed using the different internal migration APIs