Hide Forgot
Description of problem: libvirt will set a wrong priv->origname when do migrate to target then migrate back to source fail Version-Release number of selected component (if applicable): libvirt-1.2.8-12.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1.set this in source host qemu.conf: security_driver = "none" 2.set this in target host qemu.conf: security_driver = "selinux" 3.start a guest have this label in source: <seclabel type='dynamic' model='dac' relabel='yes'> <label>+107:+107</label> <imagelabel>+107:+107</imagelabel> </seclabel> 4. migrate to target with option(success): # virsh migrate r7 --live qemu+ssh://lhuang/system --dname r7-12 --verbose --p2p --tunnelled 5.try to migrate this guest back to source(fail and cause this issue): # virsh migrate r7-12 --live qemu+ssh://test1/system --dname r7 error: unsupported configuration: Unable to find security driver for label selinux 6.then destroy target guest: # virsh destroy r7-12 Domain r7-12 destroyed 7.start source guest again: # virsh start r7 Domain r7 started 8.then this issue happend in source host: # virsh migrate r7 --live qemu+ssh://lhuang/system --dname r7-12 --verbose --p2p --tunnelled error: internal error: Incoming cookie data had unexpected name r7-12 vs r7 # virsh migrate r7 --live qemu+ssh://lhuang/system --verbose --p2p --tunnelled error: internal error: Incoming cookie data had unexpected name r7-12 vs r7 Actual results: cannot do migrate after these step Expected results: migrate work well Additional info: i checked the target and source libvirtd and found maybe the issue is here: when try migrate back to source in qemuMigrationPrepareAny but failed in qemuProcessStart (because we have no selinux driver) but seems libvirt forget clear the priv->origname and will make migrate fail because leave a wrong origname in priv, and will Generate a wrong cookie when do migrate next time.
Fixed upstream by v1.2.11-170-g5035279: commit 503527919807b03c4e7b5bcf1aef92fa7b3eafb6 Author: Luyao Huang <lhuang> Date: Tue Jan 13 10:15:52 2015 +0800 qemu: free priv->origname when qemuMigrationPrepareAny fails https://bugzilla.redhat.com/show_bug.cgi?id=1181182 When we meet error in qemuMigrationPrepareAny and goto cleanup with rc < 0, we forget clear the priv->origname and this will make this vm migrate fail next time because leave a wrong origname in priv, and will Generate a wrong cookie when do migrate next time. This patch will make priv->origname is NULL when migrate fail in target host. Signed-off-by: Luyao Huang <lhuang> Signed-off-by: Jiri Denemark <jdenemar>
Hi Jiri: when i verify this bug, i found an issue. i use build libvirt-1.2.13-1.el7 & libvirt-1.2.16-1.el7 step same with description, after step 5, migration failed on target, but on source machine, the guest disappear, it should be in shut off status.Would you help to check this,thanks in advance.
Created attachment 1042684 [details] source libvirtd log
(In reply to zhe peng from comment #3) > Hi Jiri: > when i verify this bug, i found an issue. > i use build libvirt-1.2.13-1.el7 & libvirt-1.2.16-1.el7 > > step same with description, > after step 5, migration failed on target, but on source machine, the guest > disappear, it should be in shut off status.Would you help to check > this,thanks in advance. After a check, i think this is another issue, i have sent a patch to upstream need review: https://www.redhat.com/archives/libvir-list/2015-June/msg01289.html
Correct, the patch from comment 5 is already upstream as v1.2.16-299-g0944472: commit 09444724bc85d75ea3250778701e2e3b3d016df5 Author: Luyao Huang <lhuang> Date: Thu Jun 25 09:38:57 2015 +0800 qemu: Avoid removing persistent config if migration fails When migration fails in qemuMigrationPrepareAny, we unconditionally call qemuDomainRemoveInactive, which should only be called for transient domains. The check for !vm->persistent was accidentally removed by commit 540c339. Signed-off-by: Luyao Huang <lhuang> Signed-off-by: Jiri Denemark <jdenemar>
verify with build:libvirt-1.2.17-2.el7.x86_64 after step 5, the guest in shut off status. move to verified.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2015-2202.html