Bug 1742877 - virt-manager couldn't start the virtual machine
Summary: virt-manager couldn't start the virtual machine
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: virt-manager
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Cole Robinson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-08-17 07:38 UTC by Mikhail
Modified: 2020-01-15 20:37 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-01-15 20:37:57 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Mikhail 2019-08-17 07:38:46 UTC
Description of problem:
virt-manager couldn't start the virtual machine

Error starting domain: internal error: child reported (status=125): Requested operation is not valid: Setting different SELinux label on /home/mikhail/win10 which is already in use

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 75, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 111, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 66, in newfn
    ret = fn(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/object/domain.py", line 1279, in startup
    self._backend.create()
  File "/usr/lib64/python3.7/site-packages/libvirt.py", line 1136, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirt.libvirtError: internal error: child reported (status=125): Requested operation is not valid: Setting different SELinux label on /home/mikhail/win10 which is already in use


$ ls -laZ /home/mikhail/win10
-rw-------. 1 qemu qemu system_u:object_r:svirt_image_t:s0:c10,c48 42956488704 Aug 16 21:14 /home/mikhail/win10


[33437.037820] virbr0: port 2(vnet0) entered blocking state
[33437.037825] virbr0: port 2(vnet0) entered disabled state
[33437.037924] device vnet0 entered promiscuous mode
[33437.038338] virbr0: port 2(vnet0) entered blocking state
[33437.038349] virbr0: port 2(vnet0) entered listening state
[33437.130109] virbr0: port 2(vnet0) entered disabled state
[33437.147776] device vnet0 left promiscuous mode
[33437.147811] virbr0: port 2(vnet0) entered disabled state

Version-Release number of selected component (if applicable):
$ rpm -q virt-manager
virt-manager-2.2.1-2.fc31.noarch

Comment 1 Mikhail 2019-08-17 12:35:48 UTC
It's very weird, but I made copy win10 to win101 and create a new VM.
The new VM starts fine.
Ok, I removed old VM without removing the image and create a new VM with old (win10) image and the new VM didn't start.
I still didn't understand why VM with win10 image didn't start. All attributes both files look same:

$ ls -laZ /home/mikhail/win10*
-rw----rw-. 1 qemu qemu system_u:object_r:svirt_image_t:s0:c10,c48   42956488704 Aug 17 16:00 /home/mikhail/win10
-rw----rw-. 1 qemu qemu system_u:object_r:svirt_image_t:s0:c318,c938 42956488704 Aug 17 17:21 /home/mikhail/win101

Comment 2 Cole Robinson 2019-08-19 21:25:52 UTC
Try this to see the likely culprit: sudo getfattr -d -m- --absolute-names $FILENAME

Latest libvirt will use some xattr magic to track what the original label of the disk image should be, and use that stored data to restore the label when the VM is stopped. But it has some issues that will be fixed in the next libvirt version. You can turn it off with the remember_owner setting in /etc/libvirt/qemu.conf

Comment 3 Mikhail 2019-08-20 03:35:53 UTC
# getfattr -d -m- --absolute-names /home/mikhail/win10*
# file: /home/mikhail/win10
security.selinux="system_u:object_r:svirt_image_t:s0:c10,c48"
trusted.libvirt.security.dac="+0:+0"
trusted.libvirt.security.ref_dac="34"
trusted.libvirt.security.ref_selinux="34"
trusted.libvirt.security.selinux="system_u:object_r:user_home_t:s0"

# file: /home/mikhail/win101
security.selinux="system_u:object_r:svirt_image_t:s0:c235,c679"
trusted.libvirt.security.dac="+1000:+1000"
trusted.libvirt.security.ref_dac="1"
trusted.libvirt.security.ref_selinux="1"
trusted.libvirt.security.selinux="unconfined_u:object_r:user_home_t:s0"


> You can turn it off with the remember_owner setting in /etc/libvirt/qemu.conf
Yes, I confirm that issue was gone after adding the line:
remember_owner = 0

Comment 4 Cole Robinson 2020-01-15 20:37:57 UTC
This was a temporary remember_owner issue, so it should be fixed with later libvirt


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