Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1751664

Summary: Destroy vm with ongoing blockcopy will leave xattr on destination image
Product: Red Hat Enterprise Linux Advanced Virtualization Reporter: yisun
Component: libvirtAssignee: Michal Privoznik <mprivozn>
Status: CLOSED ERRATA QA Contact: yisun
Severity: medium Docs Contact:
Priority: medium    
Version: 8.1CC: jdenemar, lhuang, lmen, mprivozn, xuzhang, yafu, yisun
Target Milestone: rcKeywords: Regression, Upstream
Target Release: 8.0Flags: pm-rhel: mirror+
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: libvirt-7.0.0-1.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-05-25 06:41:20 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version: 7.0.0
Embargoed:

Description yisun 2019-09-12 11:06:40 UTC
Description:
Destroy vm with ongoing blockcopy will leave xattr on destination image

Versions:
libvirt-5.6.0-4.module+el8.1.0+4160+b50057dc.x86_64

How reproducible:
100%

Steps:
1. create a transient vm
[root@ibm-x3250m6-06 domain]# virsh create /root/vm.xml 
Domain avocado-vt-vm1 created from /root/vm.xml

2. do blockcopy
[root@ibm-x3250m6-06 domain]# virsh blockcopy avocado-vt-vm1 vda /tmp/disk.copy
Block Copy started
[root@ibm-x3250m6-06 domain]# virsh blockjob avocado-vt-vm1 vda
Block Copy: [100 %]

3. destroy vm
[root@ibm-x3250m6-06 domain]# virsh destroy avocado-vt-vm1
Domain avocado-vt-vm1 destroyed

4. the destination image will have some xattrs as follow:
[root@ibm-x3250m6-06 domain]# getfattr -n trusted.libvirt.security.ref_selinux /tmp/disk.copy 
getfattr: Removing leading '/' from absolute path names
# file: tmp/disk.copy
trusted.libvirt.security.ref_selinux="1"

Comment 1 Michal Privoznik 2020-10-14 14:13:15 UTC
I think this might be fixed meanwhile, but let me check before declaring it so. Unfortunately, it didn't get enough attention.

Comment 3 Michal Privoznik 2020-12-03 12:55:57 UTC
Yeah, I can't reproduce anymore.  Should I make this TestOnly so that it's properly tested?

Comment 4 yisun 2020-12-04 06:27:10 UTC
I just try this with 8.3.1 latest av build and seems still reproducible, pls have a check.

[root@dell-per740xd-12 ~]# rpm -qa | grep ^libvirt-6
libvirt-6.6.0-8.module+el8.3.1+8648+130818f2.x86_64

[root@dell-per740xd-12 ~]# virsh create vm.xml 
Domain vm1 created from vm.xml

[root@dell-per740xd-12 ~]# virsh blockcopy vm1 vda /tmp/disk.copy
Block Copy started
[root@dell-per740xd-12 ~]# virsh blockjob vm1 vda
Block Copy: [ 60 %]

[root@dell-per740xd-12 ~]# virsh destroy vm1
Domain vm1 destroyed

[root@dell-per740xd-12 ~]# getfattr -n trusted.libvirt.security.ref_selinux /tmp/disk.copy
getfattr: Removing leading '/' from absolute path names
# file: tmp/disk.copy
trusted.libvirt.security.ref_selinux="1"
<=== here the blockcopy target file has xattr left

And if we do a blockcopy with --reuse-external again, it will be failed.
[root@dell-per740xd-12 ~]# virsh create vm.xml 
Domain vm1 created from vm.xml

[root@dell-per740xd-12 ~]# virsh blockcopy vm1 vda /tmp/disk.copy --reuse-external
error: Requested operation is not valid: Setting different SELinux label on /tmp/disk.copy which is already in use

Comment 5 Michal Privoznik 2020-12-09 10:27:20 UTC
Patch proposed upstream:

https://www.redhat.com/archives/libvir-list/2020-December/msg00541.html

Comment 6 Michal Privoznik 2021-01-06 12:35:30 UTC
Merged upstream:

5ac2439a83 qemu_process: Release domain seclabel later in qemuProcessStop()

v6.10.0-322-g5ac2439a83

Comment 7 yisun 2021-01-08 04:04:20 UTC
PreVerified with libvirt-6.10.0-1.fc34.x86_64
result: PASS

➜  fedora virsh start pc
Domain 'pc' started

➜  fedora virsh undefine pc
Domain 'pc' has been undefined

➜  fedora virsh blockcopy pc vda /tmp/disk.copy
Block Copy started
➜  fedora virsh blockjob pc vda; virsh destroy pc
Block Copy: [ 20 %]

Domain 'pc' destroyed

➜  fedora getfattr -n trusted.libvirt.security.ref_selinux /tmp/disk.copy
/tmp/disk.copy: trusted.libvirt.security.ref_selinux: No such attribute

Comment 11 yisun 2021-01-19 07:51:38 UTC
PASSED: libvirt-7.0.0-1.module+el8.4.0+9464+3e71831a.x86_64

Comment 13 errata-xmlrpc 2021-05-25 06:41:20 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 (virt:av bug fix and enhancement update), 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://access.redhat.com/errata/RHBA-2021:2098