latest F19 policy update killed qemu ?

[Dmitry S. Makovey]

On 12/17/2013 07:59 AM, Daniel J Walsh wrote:
>> after some tinkering I've applied svirt_image_t to /var/lib/libvirt/images
>> and everything is functioning, however "restorecon -RF
>> /var/lib/libvirt/images" brings everything back to virt_image_t , hmm?
>>
> libvirt is supposed to change the label of a virt_image_t to
> svirt_image_t:MCSLABEL  when the virtual machine is running, and then change
> it back to virt_image_t when the VM is finished.  Running VMs can only
> read/write svirt_image_t.  The problem is you should not be running restorecon
> on this directory.
>
> svirt_image_t is supposed to be in a type that restorecon will not change.
>
> If you stop and restart the VM everything should be labeled correctly.

Thanks for the explanation Daniel, now it makes sence why it's refusing 
to startup those vm's - I'm using qcow2 external snapshots :

$ qemu-img create -f qcow2 -b foo.qcow2 foo-snap.qcow2

and apparently that is causing issues as either libvirt is not 
relabeling things properly or something else is wrong but at the start 
time VM has no access to base image[s] (sometimes I daisy-chain 
snapshots up to 3 levels). However the fact is - it stopped working 
yesterday, and this box was always in enforcing mode and functioning 
properly. I did not notice any updates to virtualization layer, however 
there was selinux-policy* version bump, thus I'm here.

At the moment I had to switch to the Permissive since only with "wrong" 
labels I can start VMs.

I will change labels back to virt_image_t in the meantime...

Should I be filing a bug or is there something else that could be done 
to eliminate the issue?


-- 
    This communication is intended for the use of the recipient to whom it
    is addressed, and may contain confidential, personal, and or privileged
    information. Please contact us immediately if you are not the intended
    recipient of this communication, and do not copy, distribute, or take
    action relying on it. Any communications received in error, or
    subsequent reply, should be deleted or destroyed.
---