On 17.01.2017 14:21, Michal Privoznik wrote: > 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@xxxxxxxxxx> > AuthorDate: Fri Jan 13 10:03:23 2017 +0100 > Commit: Michal Privoznik <mprivozn@xxxxxxxxxx> > 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@xxxxxxxxxx> > Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> > > >> On Tue, Jan 17, 2017 at 11:18 AM +0100, Marc Hartmayer <mhartmay@xxxxxxxxxxxxxxxxxx> 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 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@xxxxxxxxxx > 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
