Hide Forgot
Description of problem: Set the destination hostname to only numbers such as 1234 then do migration,migration will fail Version-Release number of selected component (if applicable): libvirt-0.8.2-18.el5 kvm-83-229.el5 kernel-2.6.18-252.el5 How reproducible: always Steps to Reproduce: 1.virsh start <domain> 2. Migrate the domain to the second system; # virsh migrate <domain> qemu+ssh://host2/system Actual results: It will show "error: operation failed: migration to 'tcp:(null):0' failed: migration failed" Look at /var/log/messages: pr 3 06:35:50 localhost libvirtd: 06:35:50.218: error : qemuMonitorTextMigrate:1309 : operation failed: migration to 'tcp:(null):0' failed: migration failed Expected results: Additional info: If I set hostname to name such as kxiong,the migration can succeed If I set hostname to number only such as 1234,the migration will fail
If you don't specify "--migrateuri", libvirt detects desination hostname to form the destination QEMU URI for starting migration on source host, so if you specify an ill hostname, then it's expected the migration fails. But it's a problem that it should quit migration early while "virGetHostname" returns NULL, not goes on passing a obvious incorrect QEMU URI and wait for the failure, this is trival, but need to fix.
This bug could reproduce on the following components of rh5.6: kernel-2.6.18-238.el5 libvirt-0.8.2-15.el5 virt-manager-0.6.1-13.el5 Steps to reproduce: 1.Build the migration environment on two hosts 2.set hostname of the host with the ip address "10.66.6.149" to "1234",then # virsh migrate rh5 qemu+ssh://10.66.6.149/system root.6.149's password: error: operation failed: migration to 'tcp:(null):0' failed: migration failed 3.set hostname of the host with the ip address "10.66.6.149" to "jianghuming",then # virsh migrate rh5 qemu+ssh://10.66.6.149/system root.6.149's password: (success)
This request was evaluated by Red Hat Product Management for inclusion in Red Hat Enterprise Linux 5.7 and Red Hat does not plan to fix this issue the currently developed update. Contact your manager or support representative in case you need to escalate this bug.
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.