Bug 1138203

Created attachment 934335 [details]
screenshot-1

Created attachment 934336 [details]
screenshot-2

Created attachment 934337 [details]
screenshot-3

Created attachment 934338 [details]
log file when installation failed

The logs you have attached do not match the problem you have described. The screenshots indicate a problem writing to a virtio disk, /dev/vda, while the traceback you have attached indicates a problem with /dev/sda and has not mention of /dev/vda. Please attach the log files from /tmp at the time of the problem as individual, text/plain attachments.

Created attachment 934654 [details]
New log file in /tmp

Sorry for the last attachment, the old one got when i tried choosing ide disk type, please use the new attachment, thanks.

Hi David Shea,
I found this bug issue can reproduce with any disk type, and pool type, it's a common issue, what i want to say is when the guest installation turn to make partition, it will meet such error as the attachment said.

I cannot reproduce this issue with version:
anaconda-widgets-19.31.79-1.el7.x86_64
anaconda-19.31.79-1.el7.x86_64
and the previous version:
anaconda-widgets-19.31.86-1.el7.x86_64
anaconda-19.31.86-1.el7.x86_64

so i think the key problem is new anaconda package, and duing to i cannot install guest now, also changed the bug Priority to high.

Created attachment 934900 [details]
anaconda-tb

01:36:26,651 ERR kernel:Buffer I/O error on device vda, logical block 0
01:36:26,652 WARNING kernel:lost page write due to I/O error on vda
01:36:26,652 ERR kernel:Buffer I/O error on device vda, logical block 1
01:36:26,652 WARNING kernel:lost page write due to I/O error on vda
01:36:26,652 ERR kernel:Buffer I/O error on device vda, logical block 2
01:36:26,652 WARNING kernel:lost page write due to I/O error on vda
01:36:26,652 ERR kernel:Buffer I/O error on device vda, logical block 3
01:36:26,652 WARNING kernel:lost page write due to I/O error on vda
01:36:26,652 ERR kernel:Buffer I/O error on device vda, logical block 4
01:36:26,652 WARNING kernel:lost page write due to I/O error on vda
01:36:26,652 ERR kernel:Buffer I/O error on device vda, logical block 5
01:36:26,652 WARNING kernel:lost page write due to I/O error on vda
01:36:26,652 ERR kernel:Buffer I/O error on device vda, logical block 6
01:36:26,652 WARNING kernel:lost page write due to I/O error on vda
01:36:26,652 ERR kernel:Buffer I/O error on device vda, logical block 7
01:36:26,652 WARNING kernel:lost page write due to I/O error on vda
01:36:26,652 ERR kernel:Buffer I/O error on device vda, logical block 8
01:36:26,652 WARNING kernel:lost page write due to I/O error on vda


This is most likely a kernel bug, or possibly a bug in qemu on the host, or possibly a hardware problem on the host.

Do you have access to the host dmesg and libvirt domain logs (/var/lib/libvirt/qemu/<domain>.log)?

Are there any I/O error messages in there?

(In reply to Stefan Hajnoczi from comment #12)
> Do you have access to the host dmesg and libvirt domain logs
> (/var/lib/libvirt/qemu/<domain>.log)?
> 
> Are there any I/O error messages in there?

Not see flag "needinfo", i just guess you ask me then i tried again.
1.
# rpm -q libvirt anaconda ;uname -r 
libvirt-1.2.8-4.el7.x86_64
anaconda-19.31.94-1.el7.x86_64
3.10.0-171.el7.x86_64
virt-manager-1.1.0-3.el7.noarch

2.Try to install a domain via virt-manager, failed when disk partition.
as you said while installation fail, i check host dmesg

# dmesg |grep error
[20541.057886] traps: virt-manager[17377] trap stack segment ip:7fd82b1a0c1a sp:7fff78198a00 error:0

Result: no I/O error showing.

check the domain.log (/var/log/libvirt/qemu/rhel6.5-3.log)
# grep error rhel6.5-3.log 
block I/O error in device 'drive-virtio-disk0': Permission denied (13)
block I/O error in device 'drive-virtio-disk0': Permission denied (13)
block I/O error in device 'drive-virtio-disk0': Permission denied (13)
block I/O error in device 'drive-virtio-disk0': Permission denied (13)
block I/O error in device 'drive-virtio-disk0': Permission denied (13)
block I/O error in device 'drive-virtio-disk0': Permission denied (13)
block I/O error in device 'drive-virtio-disk0': Permission denied (13)
block I/O error in device 'drive-virtio-disk0': Permission denied (13)
block I/O error in device 'drive-virtio-disk0': Permission denied (13)
block I/O error in device 'drive-virtio-disk0': Permission denied (13)

Result: I/O error showing.

I will attach all the log file later.

Created attachment 942580 [details]
tar file got from guest when installation failed

Created attachment 942581 [details]
/var/log/libvirt/qemu/rhel6.5-3.log

Created attachment 942582 [details]
the host dmesg message

(In reply to zhoujunqin from comment #15)
> Created attachment 942581 [details]
> /var/log/libvirt/qemu/rhel6.5-3.log

The QEMU command-line in this log file does not correspond to your description of the issue in Comment 1.

The QEMU command-line:

-drive file=/var/lib/libvirt/images/rhel6.5-3.qcow2,if=none,id=drive-virtio-disk0,format=qcow2

Was not generated from the libvirt domain XML:

<disk type='block' device='disk'>
      <driver name='qemu' type='raw' cache='none' io='native'/>
      <source dev='/dev/sdb1'/>

Why are they different?

Based on the EPERM errors in the log, it seems the QEMU process is unable to access /var/lib/libvirt/images/rhel6.5-3.qcow2 and you need to verify the file permissions and SELinux configuration.

(In reply to Stefan Hajnoczi from comment #17)
> The QEMU command-line in this log file does not correspond to your
> description of the issue in Comment 1.
   <source dev='/dev/sdb1'/>
...
> Why are they different?
> 
Yes, in fact they are different, the reason is that when i send this bug i just focus on installing a guest with disk pool and met the issue as bug described.
Later i met the issue Comment 8, i think they are the same issue, then when i reply your question, i just reproduce it in Comment 13 way.

libvirt domain XML:
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/rhel6.5-3.qcow2'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
    </disk>

The QEMU command-line:
-drive file=/var/lib/libvirt/images/rhel6.5-2.qcow2,if=none,id=drive-virtio-disk0,format=qcow2

> Based on the EPERM errors in the log, it seems the QEMU process is unable to
> access /var/lib/libvirt/images/rhel6.5-3.qcow2 and you need to verify the
> file permissions and SELinux configuration.

selinux-policy-3.12.1-153.el7.3.noarch
# getenforce 
Enforcing

# ll -Z /var/lib/libvirt/images/
-rw-r--r--. qemu qemu system_u:object_r:virt_content_t:s0 rhel6.5-3.qcow2

Above is about installing a guest with "default" pool storage (Comment 13), and this time i also tried with disk pool type as bug described, installation also failed.
# virsh dumpxml rhel6.5-5 |grep -A9 disk

    <disk type='block' device='disk'>
      <driver name='qemu' type='raw' cache='none' io='native'/>
      <source dev='/dev/sdc1'/>
      <backingStore/>
      <target dev='vda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
    </disk>

# virsh vol-dumpxml --pool sdcpool /dev/sdc1
<volume type='block'>
  <name>sdc1</name>
  <key>/dev/sdc1</key>
  <source>
    <device path='/dev/sdc'>
      <extent start='32256' end='3221257728'/>
    </device>
  </source>
  <capacity unit='bytes'>3221225472</capacity>
  <allocation unit='bytes'>3221225472</allocation>
  <target>
    <path>/dev/sdc1</path>
    <format type='none'/>
    <permissions>
      <mode>0660</mode>
      <owner>0</owner>
      <group>6</group>
      <label>system_u:object_r:fixed_disk_device_t:s0</label>
    </permissions>
    <timestamps>
      <atime>1412738467.714843354</atime>
      <mtime>1412738467.714843354</mtime>
      <ctime>1412738467.714843354</ctime>
    </timestamps>
  </target>
</volume>


The QEMU command-line:
-drive file=/dev/sdc1,if=none,id=drive-virtio
disk0,format=raw,cache=none,aio=native

Check selinux status
selinux-policy-3.13.1-2.el7.noarch
# getenforce 
Enforcing

# dmesg |grep error

I will attach the /var/log/libvirt/qemu/rhel6.5-5.log later.

Created attachment 944849 [details]
/var/log/libvirt/qemu/rhel6.5-5.log

(In reply to Stefan Hajnoczi from comment #21)
Hi Stefan Hajnoczi,
I have said i can reproduce this issue not only with disk pool, but also a common pool(eg.default) on my host.

[with default pool]
1.1 
# getenforce
Enforcing

Steps:
Launch virt-manager to install a guest with choosing Network Install(Http used), other configuration just as default, it will report when distribute partitions.

Guest called: rhel6.5

# ll -Z /var/lib/libvirt/images/rhel6.5.qcow2
-rw-------. qemu qemu system_u:object_r:virt_content_t:s0 /var/lib/libvirt/images/rhel6.5.qcow2

1.2
# ps -ef |grep qemu-kvm
qemu     29553     1  2 15:35 ?        00:00:21 /usr/libexec/qemu-kvm -name rhel6.5 -S -machine pc-i440fx-rhel7.1.0,accel=kvm,usb=off -cpu SandyBridge -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid e9880bf7-f875-4bde-bfdb-f593a3bfe96b -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/rhel6.5.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-reboot -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -kernel /var/lib/libvirt/boot/virtinst-vmlinuz.v8gTT2 -initrd /var/lib/libvirt/boot/virtinst-initrd.img._g5UHS -append method=http://download.englab.nay.redhat.com/pub/rhel/released/RHEL-6/6.5/Server/x86_64/os/ -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/var/lib/libvirt/images/rhel6.5.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=25,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:fe:00:b1,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -chardev spicevmc,id=charredir2,name=usbredir -device usb-redir,chardev=charredir2,id=redir2 -chardev spicevmc,id=charredir3,name=usbredir -device usb-redir,chardev=charredir3,id=redir3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -msg timestamp=on
root     32298  5289  0 15:49 pts/2    00:00:00 grep --color=auto qemu-kvm

1.3
# dmesg  |grep error
output nothing.

1.4
Attach log named rhel6.5-20141113.tar.gz


2. disabled selinux:
# setenforce 0
# getenforce 
Permissive

2.1 try to install a guest again, guest can be installed successfully.

[with disk pool]
steps
3. disabled selinux:
# setenforce 0
# getenforce 
Permissive

3.1 try to install a guest again, guest can be installed successfully.
...
    <disk type='block' device='disk'>
      <driver name='qemu' type='raw' cache='none' io='native'/>
      <source dev='/dev/sdc1'/>
      <backingStore/>
      <target dev='vda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
    </disk>
...
# virsh vol-dumpxml sdc1 pooldisk 
<volume type='block'>
  <name>sdc1</name>
  <key>/dev/sdc1</key>
  <source>
    <device path='/dev/sdc'>
      <extent start='32256' end='8589966848'/>
    </device>
  </source>
  <capacity unit='bytes'>8589934592</capacity>
  <allocation unit='bytes'>8589934592</allocation>
  <target>
    <path>/dev/sdc1</path>
    <format type='none'/>
    <permissions>
      <mode>0660</mode>
      <owner>0</owner>
      <group>6</group>
      <label>system_u:object_r:fixed_disk_device_t:s0</label>
    </permissions>
    <timestamps>
      <atime>1415869929.541666574</atime>
      <mtime>1415869929.541666574</mtime>
      <ctime>1415869929.541666574</ctime>
    </timestamps>
  </target>
</volume>

4. with enable selinux
# setenforce  1
# getenforce
Enforcing

4.1
Install a guest, named rhel6.5-7, installation failed.

4.2
Will attach debug log: rhel6.5-7-diskpool.tar.gz

As a summary i will put all releated logs to one file, i think it's easy for you to check.

And my package version: selinux-policy-3.13.1-6.el7.noarch i konow it's not the latest, i just want you help me find the key problem for this bug, thanks.

Created attachment 957060 [details]
totally log in bug_1138203_debug.tar.gz

(In reply to zhoujunqin from comment #22)
> 2. disabled selinux:
> # setenforce 0
> # getenforce 
> Permissive
> 
> 2.1 try to install a guest again, guest can be installed successfully.

Thanks for confirming it is an SELinux issue.

I have reassigned the bug to libvirt because I don't know the details of libvirt's SELinux usage.

I find the most important log, libvirtd.log missing.  Could you set up debug logs ( http://wiki.libvirt.org/page/DebugLogs ) and reproduce the issue?  I see nothing uncommon in this scenario and it's just weird that libvirt doesn't label those files.

(In reply to Martin Kletzander from comment #25)
> I find the most important log, libvirtd.log missing.  Could you set up debug
> logs ( http://wiki.libvirt.org/page/DebugLogs ) and reproduce the issue?  I
> see nothing uncommon in this scenario and it's just weird that libvirt
> doesn't label those files.

I reproduce this issue again and will attach logs you need:

libvirt-1.2.8-10.el7.x86_64
kernel-3.10.0-201.el7.x86_64
qemu-kvm-rhev-2.1.2-13.el7.x86_64
selinux-policy-3.13.1-12.el7.noarch

steps:
1. Enable selinux(we test virt-manager under this scenario usually):
# setenforce  1
# getenforce
Enforcing
2. Launch virt-manager, install a new guest named "diskpool-rhel6.6-x64".


Result: Installation failed when make partitions.

3. I will attach logs following:
xml file: diskpool-rhel6.6-x64.xml
qemu.log: diskpool-rhel6.6-x64.qemu_log
libvirtd.log: libvirtd_installation.log
guest log: diskpool-rhel6.6-x64.tar.gz

4. Disable selinux and do following steps again:
# getenforce  
Enforcing
# setenforce  0 
# getenforce  
Permissive

Result: Installation successfully.

Created attachment 963479 [details]
diskpool-rhel6.6-x64.xml

Created attachment 963480 [details]
diskpool-rhel6.6-x64.qemu_log

Created attachment 963481 [details]
libvirtd_installation.log

Created attachment 963482 [details]
diskpool-rhel6.6-x64.tar.gz

So according to the logs the file /dev/sdb1 was properly labelled:

  2014-12-02 02:36:01.837+0000: 7396: info : virSecuritySELinuxSetFileconHelper:884 : Setting SELinux context on '/dev/sdb1' to 'system_u:object_r:svirt_image_t:s0:c87,c717'
  ...
  2014-12-02 02:36:01.837+0000: 7396: info : virSecurityDACSetOwnershipInternal:243 : Setting DAC user and group on '/dev/sdb1' to '107:107'

And according to "sesearch -A -s svirt_t -t svirt_image_t | grep blk_file" it should have access for everything it needs:

  allow virt_domain svirt_image_t : blk_file { ioctl read write getattr lock append open } ;

I wonder what qemu needed to know for it to be disabled.  Would you find the error message from audit.log from the host anywhere, please?  That should be the last thing we need to solve this, unless there's some other hidden surprise anywhere.

(In reply to Martin Kletzander from comment #31)
I will attach the audit.log later, anything you need please needinfo me, i hope we can fixed it asap, thanks.

Created attachment 963585 [details]
the whole audit.log in my host

Well, so, libvirt changes the context properly to svirt_image_t and it does *not* change it to virt_content_t.  However it has the context virt_content_t when qemu is trying to write to it and that's why it fails.  We need to find out what changes the context when it's not libvirt.

Could you run the following command as root with systemtap and kernel-debuginfo installed (replace ASDF with the filename of the disk, e.g. /var/log/libvirt/images/rhel-something.img):

# stap -ve 'probe syscall.lsetxattr, syscall.setxattr { if (path != "\"ASDF\"") { next }; printf("\nexecname: %s\npath: %s\nname: %s\nvalue:  %s\n", execname(), path, name_str, user_string_quoted(value_uaddr)); }'

You should get output similar to the following one:

Pass 1: parsed user script and 114 library script(s) using 224496virt/41820res/3076shr/39380data kb, in 110usr/10sys/129real ms.
Pass 2: analyzed script: 2 probe(s), 6 function(s), 3 embed(s), 0 global(s) using 262236virt/80628res/4200shr/77120data kb, in 520usr/100sys/621real ms.
Pass 3: translated to C into "/tmp/stap2j6KGo/stap_ab30f868aa6d00f052ed2f24ca879ac0_5499_src.c" using 262236virt/80916res/4488shr/77120data kb, in 10usr/40sys/42real ms.
Pass 4: compiled C into "stap_ab30f868aa6d00f052ed2f24ca879ac0_5499.ko" in 1020usr/260sys/1197real ms.
Pass 5: starting run.

After you see the last line, reproduce the bug.  You should see the ouput continues with lines similar to these:

execname: libvirtd
path:  "/path/to/image"
name:  "security.selinux"
value: "system_u:object_r:svirt_image_t:s0:c87,c717"

execname: something
path:  "/path/to/image"
name:  "security.selinux"
value: "system_u:object_r:virt_content_t:s0:c87,c717"

After the issue comes up again, you can Ctrl+C the script and paste the output here (the lines with execname, path, name and value are enough).

Reproduce with packages:
virt-manager-1.1.0-9.el7.noarch
kernel-3.10.0-212.el7.x86_64
kernel-debuginfo-3.10.0-212.el7.x86_64
systemd-208-18.el7.x86_64
selinux-policy-3.13.1-12.el7.noarch

Steps:
1. Check selinux status.
# getenforce 
Enforcing------------------->>enabled

2.
# stap -ve 'probe syscall.lsetxattr, syscall.setxattr { if (path != "\"/dev/sdb1\"") { next }; printf("\nexecname: %s\npath: %s\nname: %s\nvalue:  %s\n", execname(), path, name_str, user_string_quoted(value_uaddr)); }'Pass 1: parsed user script and 112 library script(s) using 224328virt/41660res/3076shr/39216data kb, in 140usr/10sys/533real ms.
Pass 2: analyzed script: 2 probe(s), 6 function(s), 3 embed(s), 0 global(s) using 262072virt/80540res/4260shr/76960data kb, in 870usr/400sys/5513real ms.
Pass 3: translated to C into "/tmp/stapOUqpcA/stap_1699a11dad7256baef19b626390c3fc3_5501_src.c" using 262072virt/80824res/4544shr/76960data kb, in 10usr/40sys/44real ms.
Pass 4: compiled C into "stap_1699a11dad7256baef19b626390c3fc3_5501.ko" in 4200usr/730sys/6532real ms.
Pass 5: starting run.

execname: libvirtd
path: "/dev/sdb1"
name: "security.selinux"
value:  "system_u:object_r:svirt_image_t:s0:c447,c762"

execname: libvirtd
path: "/dev/sdb1"
name: "security.selinux"
value:  "system_u:object_r:virt_content_t:s0"--->reproduce issue, than ctrl+c exit
^CWARNING: Number of errors: 0, skipped probes: 7
Pass 5: run completed in 10usr/50sys/244702real ms.

Is it enough, thanks.

Thank you very much for going through all the debugging.  So libvirt daemon itself changes the context.  And it looks like it is due to libguestfs.  So if you had virtlockd installed and configured, it would not happen, but default installation does not have it; but that's not the problem.  The problem is that virt-manager should not run libguestfs probes on domains that are running.  Libguestfs starts up the domain with readonly disk and the readonly disk gets virt_content_t context and hence the consequential write from qemu fails.

Moving to virt-manager (even though this could be a libguestfs problem).

can you please try to reproduce the issue as:

$ sudo virsh start $YOUR_VM
$ sudo virt-viewer $YOUR_VM

(from the VM try to write to the disk, a "while sleep 1; do echo a > ~/output; done" is fine)

and from the host run this command:

$ sudo guestfish --ro -i /path/to/your/image.qcow2

Where /path/to/your/image.qcow2 is the image disk used by $YOUR_VM.

Is it failing for you?

virt-manager could check if the VM is running before attempt to mount the image through libguestfs, but that is not a correct solution as it will introduce a race condition (i.e. run the VM between the check and the mount).

If you confirm these steps cause the same issue for you, please move to libguestfs.

(In reply to Giuseppe Scrivano from comment #37)

Hi Giuseppe Scrivano,
i try to reproduce it in your way, please have a look about my steps:

1. Prepare a guest with os already installed on it. 
# virsh start kvm-rhel6.6-i386 
Domain kvm-rhel6.6-i386 started

# virt-viewer  kvm-rhel6.6-i386 

2. Login guest and try to  write to the disk:
# while sleep 1; do echo a > ~/output; done

3. On host run following command:
# guestfish --ro -i /var/lib/libvirt/images/kvm-rhel6.6-i386 

Welcome to guestfish, the guest filesystem shell for
editing virtual machine filesystems and disk images.

Type: 'help' for help on commands
      'man' to read the manual
      'quit' to quit the shell

Operating system: Red Hat Enterprise Linux Server release 6.6 (Santiago)
/dev/sda1 mounted on /

><fs> 

....

Result: In guest got the following message:

# while sleep 1; do echo a > ~/output; done
Message from syslogd@localhost at Dec  8 03:44:01 ...
 kernel:journal commit I/O error

bash: /root/output: Read-only file system
bash: /root/output: Read-only file system
bash: /root/output: Read-only file system
bash: /root/output: Read-only file system
bash: /root/output: Read-only file system
bash: /root/output: Read-only file system
...

please help me check it, whether it's enough to reproduce my issue, thanks.

yes, the steps are enough as you are hitting the write issue in the guest.

I suspect this is:
https://bugzilla.redhat.com/show_bug.cgi?id=1075143
which in turn depends on a libguestfs RFE:
https://bugzilla.redhat.com/show_bug.cgi?id=1075164

Junqin: Does it still happen if you have SELinux enabled
and you uninstall the libguestfs-python package?

you cannot hit this issue, AFAICS, if libguestfs-python is not installed as virt-manager won't attempt any guest inspection.

what about using "<disk>....<seclabel relabel='no'/></disk>" when mounting an image through libvirt?

(In reply to Giuseppe Scrivano from comment #42)
> what about using "<disk>....<seclabel relabel='no'/></disk>" when mounting
> an image through libvirt?

Not sure if that was directed at me, but anyway, because we want
to use sVirt for protection against rogue disk images.  There
would be no point in having libvirt set up all the labelling for
virt-manager, if libguestfs comes along and provides a "backdoor"
for attackers.

There are ways we could pass SELinux labels around and so on, but
by far the cleanest thing is to pass the libvirt virDomainPtr.  However
it's not very easy to implement otherwise we would have done it
already.

ok, I see.  As it doesn't seem there is an easy way to fix this issue, should we disable for now guests inspection altogether in virt-manager?

Disturbingly few people hit this bug.  It may indicate a lot of
people still disable SELinux.

Don't disable it for now.  I'll see how hard it's going to be to
fix this.

This is not complete, but it's a start:

https://www.redhat.com/archives/libguestfs/2014-December/thread.html#00089

More complete and tested implementation of the libguestfs
part of this.  Still requires a virt-manager change, but
that's trivial in comparison.

https://www.redhat.com/archives/libguestfs/2014-December/thread.html#00092

I can reproduce this bug with:
libvirt-1.2.8-12.el7.x86_64
virt-manager-1.1.0-11.el7.noarch
python-libguestfs-1.28.1-1.18.el7.x86_64

Tested pass with:
libvirt-1.2.8-12.el7.x86_64
virt-manager-1.1.0-12.el7.noarch
python-libguestfs-1.28.1-1.18.el7.x86_64

Steps:
1. Prepare a guest with os already installed on it. 
# virsh start kvm-rhel6.6-i386 
Domain kvm-rhel6.6-i386 started

# virt-viewer  kvm-rhel6.6-i386 

2. Login guest and try to  write to the disk:
# while sleep 1; do echo a > ~/output; done

3. On host run following command:
# guestfish --ro -i /var/lib/libvirt/images/kvm-rhel6.6-i386 

No "bash: /root/output: Read-only file system" error shows in guest as comment 38.

4.Use virt-manager to install a guest,it can be installed successfully.

Refer to the above comments,move the bug 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-0427.html

*** Bug 1241037 has been marked as a duplicate of this bug. ***