I missed the Friday deadline ot push it, so did it today. It's now tagged in git, signed tarball and rpms are at the usual place: ftp://libvirt.org/libvirt/ As a result I think GA should happen on Tuesday to give at least one working day to raise critical issues. Nothing seems to have been reported on rc1 neither positive nor negative, so please give it some testing.

Hey, I have tried to live hot plug a disk backed on a qcow2 disk (see XML snippet below) on a s390 system and I've got the following error message: <error_message> internal error: unable to execute QEMU command 'device_add': Property 'scsi-hd.drive' can't find value 'drive-scsi0-0-0-0' </error_message> <xml_snippet> <disk type="file"> <driver name="qemu" type="qcow2"/> <source file="/tmp/virtd-test_e3hnhh5/disk1.qcow2" /> <target bus="scsi" dev="sda" /> </disk> </xml_snippet> With v2.5.0 everything has worked. I'll take a closer look to it today. Thanks, Marc On Sat, Jan 14, 2017 at 11:02 PM +0100, Daniel Veillard <veillard(a)redhat.com&gt; wrote: > I missed the Friday deadline ot push it, so did it today. It's now tagged > in git, signed tarball and rpms are at the usual place: > ftp://libvirt.org/libvirt/ > > As a result I think GA should happen on Tuesday to give at least one > working day to raise critical issues. Nothing seems to have been reported > on rc1 neither positive nor negative, so please give it some testing. > > thanks in advance, > > Daniel > > -- > Daniel Veillard | Open Source and Standards, Red Hat > veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ > http://veillard.com/ | virtualization library http://libvirt.org/ > > -- > libvir-list mailing list > libvir-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list

>> <target bus="scsi" dev="sda" /> >> </disk> >> </xml_snippet> >> >> With v2.5.0 everything has worked. I'll take a closer look to it today. You can try and see if this is a namespace caused issue. Just disable the namespaces and retry. If it succeeds with namespaces disabled, the bug indeed is in my namespaces patches. btw: to disable namespaces set: namespaces=[] in /etc/libvirt/qemu.conf Michal

[Dropping libvirt-announce] On 01/17/2017 02:51 PM, Boris Fiuczynski wrote: > On 01/17/2017 02:21 PM, Michal Privoznik wrote: >>>> <target bus="scsi" dev="sda" /> >>>> </disk> >>>> </xml_snippet> >>>> >>>> With v2.5.0 everything has worked. I'll take a closer look to it today. >> You can try and see if this is a namespace caused issue. Just disable >> the namespaces and retry. If it succeeds with namespaces disabled, the >> bug indeed is in my namespaces patches. >> >> btw: to disable namespaces set: namespaces=[] in /etc/libvirt/qemu.conf >> >> Michal > > With disabled namespaces the problem does NOT occur. > > Okay, can you share the debug logs then please? Both daemon and domain logs. Michal

On 01/17/2017 04:28 PM, Marc Hartmayer wrote: > On Tue, Jan 17, 2017 at 03:28 PM +0100, Michal Privoznik <mprivozn(a)redhat.com&gt; wrote: >> [Dropping libvirt-announce] >> >> On 01/17/2017 02:51 PM, Boris Fiuczynski wrote: >>> On 01/17/2017 02:21 PM, Michal Privoznik wrote: >>>>>> <target bus="scsi" dev="sda" /> >>>>>> </disk> >>>>>> </xml_snippet> >>>>>> >>>>>> With v2.5.0 everything has worked. I'll take a closer look to it today. >>>> You can try and see if this is a namespace caused issue. Just disable >>>> the namespaces and retry. If it succeeds with namespaces disabled, the >>>> bug indeed is in my namespaces patches. >>>> >>>> btw: to disable namespaces set: namespaces=[] in /etc/libvirt/qemu.conf >>>> >>>> Michal >>> >>> With disabled namespaces the problem does NOT occur. >>> >>> >> >> Okay, can you share the debug logs then please? Both daemon and domain logs. >> >> Michal > > Yes - I'll send you also the important part of audit.log (with SELINUX > permissive). > > Evaluation with some combinations (0 = no, 1 = yes): > > | namespace enabled | SELinux enabled | works | > |-------------------|-----------------|-------| > | 0 | 0 | 1 | > | 0 | 1 | 1 | > | 1 | 0 | 1 | > | 1 | 1 | 0 | Yeah, I've just managed to reproduce this issue in my environment. And something interesting is happening here: # grep avc /var/log/audit/audit.log type=AVC msg=audit(1484667144.960:323): avc: denied { open } for pid=32367 comm="qemu-kvm" path="/tmp/disk1.qcow2" dev="vda2" ino=17080167 scontext=system_u:system_r:svirt_tcg_t:s0:c551,c756 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file (I've simplified the disk path in my testing compared to your XML). Although, if I disable namespaces I'm still unable to attach the disk. I mean the SELinux is still denying the operation. Michal

On 01/17/2017 04:28 PM, Marc Hartmayer wrote: > On Tue, Jan 17, 2017 at 03:28 PM +0100, Michal Privoznik <mprivozn(a)redhat.com&gt; wrote: >> [Dropping libvirt-announce] >> >> On 01/17/2017 02:51 PM, Boris Fiuczynski wrote: >>> On 01/17/2017 02:21 PM, Michal Privoznik wrote: >>>>>> <target bus="scsi" dev="sda" /> >>>>>> </disk> >>>>>> </xml_snippet> >>>>>> >>>>>> With v2.5.0 everything has worked. I'll take a closer look to it today. >>>> You can try and see if this is a namespace caused issue. Just disable >>>> the namespaces and retry. If it succeeds with namespaces disabled, the >>>> bug indeed is in my namespaces patches. >>>> >>>> btw: to disable namespaces set: namespaces=[] in /etc/libvirt/qemu.conf >>>> >>>> Michal >>> >>> With disabled namespaces the problem does NOT occur. >>> >>> >> >> Okay, can you share the debug logs then please? Both daemon and domain logs. >> >> Michal > > Yes - I'll send you also the important part of audit.log (with SELINUX > permissive). > > Evaluation with some combinations (0 = no, 1 = yes): > > | namespace enabled | SELinux enabled | works | > |-------------------|-----------------|-------| > | 0 | 0 | 1 | > | 0 | 1 | 1 | > | 1 | 0 | 1 | > | 1 | 1 | 0 | Yeah, I've just managed to reproduce this issue in my environment. And something interesting is happening here: # grep avc /var/log/audit/audit.log type=AVC msg=audit(1484667144.960:323): avc: denied { open } for pid=32367 comm="qemu-kvm" path="/tmp/disk1.qcow2" dev="vda2" ino=17080167 scontext=system_u:system_r:svirt_tcg_t:s0:c551,c756 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file (I've simplified the disk path in my testing compared to your XML). Although, if I disable namespaces I'm still unable to attach the disk. I mean the SELinux is still denying the operation.

I'm thinking we've hit the limit of what we should try to force into the 3.0.0 release. My vote at this poiint is to change the code so that namespaces are disabled out of the box, and do a 3.0.0 release. Look at fixing the bugs to turn it back on by default in 3.1.0

On 01/17/2017 02:13 PM, Marc Hartmayer wrote: > Update: > It's a SELinux labeling problem and seems to be introduced by the > QEMU namespace patches. > I wouldn't guess from the error message that qemu is getting EPERM. Anyway, the SELinux issue is fixed in -rc2: commit 93a062c3b293685024d60e841a37e93e303f4943 Author: Michal Privoznik <mprivozn(a)redhat.com&gt; AuthorDate: Fri Jan 13 10:03:23 2017 +0100 Commit: Michal Privoznik <mprivozn(a)redhat.com&gt; CommitDate: Fri Jan 13 14:45:52 2017 +0100 qemu: Copy SELinux labels for namespace too When creating new /dev/* for qemu, we do chown() and copy ACLs to create the exact copy from the original /dev. I though that copying SELinux labels is not necessary as SELinux will chose the sane defaults. Surprisingly, it does not leaving namespace with the following labels: crw-rw-rw-. root root system_u:object_r:tmpfs_t:s0 random crw-------. root root system_u:object_r:tmpfs_t:s0 rtc0 drwxrwxrwt. root root system_u:object_r:tmpfs_t:s0 shm crw-rw-rw-. root root system_u:object_r:tmpfs_t:s0 urandom As a result, domain is unable to start: error: internal error: process exited while connecting to monitor: Error in GnuTLS initialization: Failed to acquire random data. qemu-kvm: cannot initialize crypto: Unable to initialize GNUTLS library: Failed to acquire random data. The solution is to copy the SELinux labels as well. Reported-by: Andrea Bolognani <abologna(a)redhat.com&gt; Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com&gt; > On Tue, Jan 17, 2017 at 11:18 AM +0100, Marc Hartmayer <mhartmay(a)linux.vnet.ibm.com&gt; wrote: >> Hey, >> >> I have tried to live hot plug a disk backed on a qcow2 disk (see XML >> snippet below) on a s390 system and I've got the following error >> message: >> >> <error_message> >> internal error: unable to execute QEMU command 'device_add': Property >> 'scsi-hd.drive' can't find value 'drive-scsi0-0-0-0' >> </error_message> >> >> <xml_snippet> >> <disk type="file"> >> <driver name="qemu" type="qcow2"/> >> <source file="/tmp/virtd-test_e3hnhh5/disk1.qcow2" /> My namespace patches should not clash with this as this isn't a device from /dev/*. In the namespace, it's just /dev that is different to the parent namespace. So anything else (e.g. under /tmp) is "shared" with the parent namespace (it is the same mount in fact). >> <target bus="scsi" dev="sda" /> >> </disk> >> </xml_snippet> >> >> With v2.5.0 everything has worked. I'll take a closer look to it today. You can try and see if this is a namespace caused issue. Just disable the namespaces and retry. If it succeeds with namespaces disabled, the bug indeed is in my namespaces patches. btw: to disable namespaces set: namespaces=[] in /etc/libvirt/qemu.conf Michal

-- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list