Bug 1181182 - libvirt will set a wrong priv->origname when do migrate to target then migrate back to source fail
Summary: libvirt will set a wrong priv->origname when do migrate to target then migrat...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.1
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Libvirt Maintainers
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-01-12 14:26 UTC by Luyao Huang
Modified: 2015-11-19 06:07 UTC (History)
6 users (show)

Fixed In Version: libvirt-1.2.13-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-19 06:07:42 UTC
Target Upstream Version:


Attachments (Terms of Use)
source libvirtd log (161.31 KB, text/plain)
2015-06-24 10:18 UTC, zhe peng
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2202 0 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2015-11-19 08:17:58 UTC

Description Luyao Huang 2015-01-12 14:26:03 UTC
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.

Comment 1 Jiri Denemark 2015-01-15 10:42:13 UTC
Fixed upstream by v1.2.11-170-g5035279:

commit 503527919807b03c4e7b5bcf1aef92fa7b3eafb6
Author: Luyao Huang <lhuang@redhat.com>
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@redhat.com>
    Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

Comment 3 zhe peng 2015-06-24 10:16:37 UTC
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.

Comment 4 zhe peng 2015-06-24 10:18:23 UTC
Created attachment 1042684 [details]
source libvirtd log

Comment 5 Luyao Huang 2015-06-25 02:27:15 UTC
(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

Comment 6 Jiri Denemark 2015-06-30 14:32:36 UTC
Correct, the patch from comment 5 is already upstream as v1.2.16-299-g0944472:

commit 09444724bc85d75ea3250778701e2e3b3d016df5
Author: Luyao Huang <lhuang@redhat.com>
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@redhat.com>
    Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

Comment 7 zhe peng 2015-07-28 10:45:30 UTC
verify with build:libvirt-1.2.17-2.el7.x86_64

after step 5, the guest in shut off status.

move to verified.

Comment 9 errata-xmlrpc 2015-11-19 06:07:42 UTC
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


Note You need to log in before you can comment on or make changes to this bug.