(In reply to Yedidyah Bar David from comment #0)
> vdsm log says:
> 
> Thread-51::DEBUG::2013-10-28 14:37:33,327::vm::2557::vm.Vm::(setDownStatus)
> vmId=`a4d38589-9ff3-4d51-a963-6fbf7fc49703`::Changed state to Down: unable
> to set security context 'system_u:object_r:virt_content_t:s0' on
> '/iso/rhel6/rhel-server-6.4-x86_64-dvd.iso': Read-only file system

Why VDSM is trying to change a context on a readonly FS?
However, I can solve this one in 2 ways:

 - refuse to accept iso image on readonly mounts
 - accept readonly mount but ensure security context is correct.

In the second case I need to be sure that VDSM will not try to change that context if already set (and hopefully doesn't change the required context in the future)

(In reply to Sandro Bonazzola from comment #1)
> (In reply to Yedidyah Bar David from comment #0)
> > vdsm log says:
> > 
> > Thread-51::DEBUG::2013-10-28 14:37:33,327::vm::2557::vm.Vm::(setDownStatus)
> > vmId=`a4d38589-9ff3-4d51-a963-6fbf7fc49703`::Changed state to Down: unable
> > to set security context 'system_u:object_r:virt_content_t:s0' on
> > '/iso/rhel6/rhel-server-6.4-x86_64-dvd.iso': Read-only file system
> 
> Why VDSM is trying to change a context on a readonly FS?
> However, I can solve this one in 2 ways:
> 
>  - refuse to accept iso image on readonly mounts
>  - accept readonly mount but ensure security context is correct.
> 
> In the second case I need to be sure that VDSM will not try to change that
> context if already set (and hopefully doesn't change the required context in
> the future)

It's hard to tell what happened without any log attached. From the single error line we have I can tell that it's a libvirt error message (it has nothing to do with VDSM):

system_u:object_r:virt_content_t:s0' on '/iso/rhel6/rhel-server-6.4-x86_64-dvd.iso

maybe something related to bug 910859 (currently on fedora but I suppose it could be in rhel as well).

Anybody from libvirt can advise?

Could you attach the domain XML?

Created attachment 834355 [details]
vdsm.log.gz

You can see the domain xml inside the vdsm log, attached.

Thanks, the important part of the XML is

    <disk device="cdrom" snapshot="no" type="file">
        <address bus="1" controller="0" target="0" type="drive" unit="0"/>
        <source file="/iso/Fedora-18-x86_64-netinst.iso" startupPolicy="optional"/>
        <target bus="ide" dev="hdc"/>
        <readonly/>
        <serial/>
        <boot order="1"/>
    </disk>

I guess the ISO image already had the right SELinux label and libvirt just wanted to do something that wasn't really necessary, right? To confirm that what does "ls -lZ" say about the DVD image?

In any case, it's either not a bug a libvirt bug. Could you move this bug to RHEL/libvirt depending on what the underlying RHEL version is (6.5 I guess)?

I do not remember anymore the exact details of this setup. IIRC it was a fedora 19 host and a Debian 7 nfs server.

Anyway, I think that we should support also nfs mounts with no special security contexts - we only need to read the image, it's enough if we can do that. If for some reason we decide to try to change stuff there, to try and make sure it's readable by qemu, I think we should not fail on that - perhaps warn, but fail only if eventually the image is unreadable to qemu.

I can easily reproduce if this will help.

I guess most if not all testing was done with a locally-hosted images, but guess that many users have some read-only nfs export with a bunch of iso images that they might want to use (also) for hosted-engine VM installation.

I wonder if this is the same problem as solved in bug 996543

(In reply to Eric Blake from comment #8)
> I wonder if this is the same problem as solved in bug 996543

Seems so. Thanks!

*** This bug has been marked as a duplicate of bug 996543 ***