Re: Availability of libvirt-3.0.0 release candidate 2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]
  Powered by Linux