Bug 1023970 - hosted-engine fails if ISO image is on a read-only mount, with a non-helpful message
hosted-engine fails if ISO image is on a read-only mount, with a non-helpful ...
Status: CLOSED DUPLICATE of bug 996543
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-hosted-engine-setup (Show other bugs)
3.3.0
Unspecified Unspecified
medium Severity medium
: ---
: 3.4.0
Assigned To: Sandro Bonazzola
Leonid Natapov
integration
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-28 09:14 EDT by Yedidyah Bar David
Modified: 2014-02-05 00:51 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-01-30 03:04:03 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
didi: needinfo-


Attachments (Terms of Use)
vdsm.log.gz (462.54 KB, application/x-gzip)
2013-12-09 10:10 EST, Yedidyah Bar David
no flags Details

  None (edit)
Description Yedidyah Bar David 2013-10-28 09:14:04 EDT
Description of problem:

hosted-engine fails if ISO image is on a read-only mount.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. hosted-engine --deploy
2. Provide an ISO image path that is on a read-only mount

Actual results:

[ ERROR ] Failed to execute stage 'Closing up': Cannot set temporary password for console connection. The VM may not have been created: please check VDSM logs

Expected results:

Should not fail.

Also, if the VM creation/startup fails due to other reasons, a more helpful error message should be displayed.

Additional info:

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
Comment 1 Sandro Bonazzola 2013-10-28 09:51:32 EDT
(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)
Comment 2 Federico Simoncelli 2013-11-29 05:28:57 EST
(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).
Comment 3 Sandro Bonazzola 2013-11-29 10:47:51 EST
Anybody from libvirt can advise?
Comment 4 Jiri Denemark 2013-12-03 04:49:44 EST
Could you attach the domain XML?
Comment 5 Yedidyah Bar David 2013-12-09 10:10:18 EST
Created attachment 834355 [details]
vdsm.log.gz

You can see the domain xml inside the vdsm log, attached.
Comment 6 Jiri Denemark 2013-12-09 11:43:58 EST
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)?
Comment 7 Yedidyah Bar David 2014-01-15 04:37:26 EST
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.
Comment 8 Eric Blake 2014-01-29 12:55:06 EST
I wonder if this is the same problem as solved in bug 996543
Comment 9 Yedidyah Bar David 2014-01-30 03:04:03 EST
(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 ***

Note You need to log in before you can comment on or make changes to this bug.