+++ This bug was initially created as a clone of Bug #1152661 +++ Description of problem: Before plugging external luns to vms, we setup up a temporary udev rule for setting device permissions. Using this rule will cause the device to loose the libvirt selinux label if a device has a change event, and running with recent systemd-udevd (e.g. Fedora 19 and later, EL 7). This is the same issue we had with vdsm images, (bug 1127460) but with external luns we do not trigger change events, so the issue is unlikely. However, if it happens, it will cause a vm to pause. Version-Release number of selected component (if applicable): vdsm master Oct 10. How reproducible: Always Steps to Reproduce: 1. Start a vm using an external lun for one of the disks 2. Trigger a change event on a device used as external lun udevadm trigger --verbose --action change \ --property-match=DM_NAME=1IET_0006000a You need to replace 1IET_0006000a with the actual device name, can be found using multipath -ll. Actual results: The device will loose the svirt_image_t:s0:cxxx,cyyy label, and will get the default label fixed_disk_device_t:s0 intead. This will cause the vm to pause. Expected results: Libvirt sexlinux label kept and vm keep running.
The 3.5 patch is merged. Moving to MODIFIED.
SElinux label is kept for a direct LUN while it is attached to a running VM. [root@green-vdsb dev]# multipath -ll |grep 3514f0c5447600438 3514f0c5447600438 dm-21 XtremIO ,XtremApp [root@green-vdsb dev]# ls -Z |grep dm-21 brw-rw----. root disk system_u:object_r:fixed_disk_device_t:s0 dm-21 Started the VM: [root@green-vdsb dev]# ls -Z |grep dm-21 brw-rw----. vdsm qemu system_u:object_r:svirt_image_t:s0:c203,c878 dm-21 Changed label: [root@green-vdsb dev]# udevadm trigger --verbose --action change --property-match=3514f0c5447600438 [root@green-vdsb dev]# ls -Z |grep dm-21 brw-rw----. vdsm qemu system_u:object_r:svirt_image_t:s0:c203,c878 dm-21 Checked on iSCSI and FC Verified using rhev 3.5 vt11
Nit, iiuc, there is nothing customer-facing to document here. Can you please either confirm and set requires-doctext-, or provide the relevant documentation? Thanks!
(In reply to Allon Mureinik from comment #4) > Nit, iiuc, there is nothing customer-facing to document here. > Can you please either confirm and set requires-doctext-, or provide the > relevant documentation? I agree.