[libvirt] Entering freeze for libvirt-3.0.0
As planned, I tagged the RC1 in git and pushed signed tarball and rpms to the usual location: ftp://libvirt.org/libvirt/ This seems to work fine in my limited testing but as usual we need community feedback on it and especially testing on different systems and architectures, so please give it a try ! If everything works fine then I will push rc2 on Friday and hopefully 3.0.0 final on Monday, so please give it a try to make sure that 0.0 release is nonetheless a good one :-) thanks ! Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veillard@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/
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@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/
On Sat, Jan 14, 2017 at 11:02:37PM +0100, Daniel Veillard 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.
This series wants to change the public API for a constant just added: https://www.redhat.com/archives/libvir-list/2017-January/msg00678.html IMHO it is too late to change this, so instead I'm suggesting we revert that public API addition entirely https://www.redhat.com/archives/libvir-list/2017-January/msg00702.html and revisit it in 3.1.0 Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
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@redhat.com> 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@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Update: It's a SELinux labeling problem and seems to be introduced by the QEMU namespace patches. On Tue, Jan 17, 2017 at 11:18 AM +0100, Marc Hartmayer <mhartmay@linux.vnet.ibm.com> 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" /> <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@redhat.com> 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@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
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@redhat.com> AuthorDate: Fri Jan 13 10:03:23 2017 +0100 Commit: Michal Privoznik <mprivozn@redhat.com> 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@redhat.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
On Tue, Jan 17, 2017 at 11:18 AM +0100, Marc Hartmayer <mhartmay@linux.vnet.ibm.com> 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
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. -- Mit freundlichen Grüßen/Kind regards Boris Fiuczynski IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martina Köderitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
[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 Tue, Jan 17, 2017 at 03:28 PM +0100, Michal Privoznik <mprivozn@redhat.com> 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 | -- Beste Grüße / Kind regards Marc Hartmayer IBM Deutschland Research & Development GmbH Vorsitzende des Aufsichtsrats: Martina Koederitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
On 01/17/2017 04:28 PM, Marc Hartmayer wrote:
On Tue, Jan 17, 2017 at 03:28 PM +0100, Michal Privoznik <mprivozn@redhat.com> 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 Tue, Jan 17, 2017 at 04:41 PM +0100, Michal Privoznik <mprivozn@redhat.com> wrote:
On 01/17/2017 04:28 PM, Marc Hartmayer wrote:
On Tue, Jan 17, 2017 at 03:28 PM +0100, Michal Privoznik <mprivozn@redhat.com> 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
Hmm, I've just double checked it... and it works if I'm disabling only namespaces in qemu.conf (and restart libvirtd). -- Beste Grüße / Kind regards Marc Hartmayer IBM Deutschland Research & Development GmbH Vorsitzende des Aufsichtsrats: Martina Koederitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
On Tue, Jan 17, 2017 at 04:41:57PM +0100, Michal Privoznik wrote:
On 01/17/2017 04:28 PM, Marc Hartmayer wrote:
On Tue, Jan 17, 2017 at 03:28 PM +0100, Michal Privoznik <mprivozn@redhat.com> 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 see the same behaviour Marc is reporting. If namespaces are enabled, hotplug fails, if disabled, it works. When namespace are disabled I see 2 lines from the sec driver in the logs: 2017-01-17 16:05:50.539+0000: 21387: info : virSecuritySELinuxSetFileconHelper:1155 : Setting SELinux context on '/tmp/virtd-test_e3hnhh5/disk1.qcow2' to 'system_u:object_r:svirt_image_t:s0:c203,c529' 2017-01-17 16:05:50.540+0000: 21387: info : virSecurityDACSetOwnershipInternal:555 : Setting DAC user and group on '/tmp/virtd-test_e3hnhh5/disk1.qcow2' to '107:107' with namespaces enabled, those lines never appear and we get the permission problem. BTW, your test put the file directlry in /tmp - I'd suggest using a subdir like Marc has, since /tmp has some "special" behaviour with SELinux. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
On Tue, Jan 17, 2017 at 04:41:57PM +0100, Michal Privoznik wrote:
On 01/17/2017 04:28 PM, Marc Hartmayer wrote:
On Tue, Jan 17, 2017 at 03:28 PM +0100, Michal Privoznik <mprivozn@redhat.com> 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.
The problem is the qemuSecuritySetDiskLabel() method. It skips labelling the disk if namespace are enabled, with the claim that the namespace code already labelled stuff. This is not true though, the namespace code only labelled block devices, not file backed devices. I'm not seeing an immediately easy fix for this since we can't tell the security driver to only label file backed devices. I think we need to take the security manager code out of the qemuDomainAttachDeviceMknodHelper method, and the change the qemuSecuritySetDiskLabel() method to run inside the namespace. 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 Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
On 01/17/2017 05:39 PM, Daniel P. Berrange wrote:
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
Ack.
bugs to turn it back on by default in 3.1.0
On 01/17/2017 05:39 PM, Daniel P. Berrange wrote:
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
Daniel, I totally agree with your voting! As it looks this morning 3.0.0 has been released and namespaces have not been disabled. Have they been left enabled intentionally? -- Mit freundlichen Grüßen/Kind regards Boris Fiuczynski IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martina Köderitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
On Wed, Jan 18, 2017 at 08:35:27AM +0100, Boris Fiuczynski wrote:
On 01/17/2017 05:39 PM, Daniel P. Berrange wrote:
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
Daniel, I totally agree with your voting! As it looks this morning 3.0.0 has been released and namespaces have not been disabled. Have they been left enabled intentionally?
No, an oversight of the release person, i.e. me <grin/> Daniel
-- Mit freundlichen Grüßen/Kind regards Boris Fiuczynski
IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martina Köderitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
-- Daniel Veillard | Red Hat Developers Tools http://developer.redhat.com/ veillard@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/
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@redhat.com> AuthorDate: Fri Jan 13 10:03:23 2017 +0100 Commit: Michal Privoznik <mprivozn@redhat.com> 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@redhat.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
On Tue, Jan 17, 2017 at 11:18 AM +0100, Marc Hartmayer <mhartmay@linux.vnet.ibm.com> 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 Somewhat related: I built 3.0.0-rc2 on an x86 Ubuntu box and could not get it to run in conjunction with apparmor. By this I mean I could not start a simple KVM guest. I could get past the audit failures by adding an unconditional mount
On 17.01.2017 14:21, Michal Privoznik wrote: permission in /etc/apparmor.d/usr.sbin.libvirtd but ended up with a generic failure message doing a virsh start. Disabling namespaces helps (obviously). It would be nice if someone apparmor-savvy could have a look. Thanks!
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
-- Mit freundlichen Grüßen/Kind Regards Viktor Mihajlovski IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martina Köderitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
participants (7)
-
Boris Fiuczynski -
Christian Borntraeger -
Daniel P. Berrange -
Daniel Veillard -
Marc Hartmayer -
Michal Privoznik -
Viktor Mihajlovski