Bug 1169792

Now I'm just checking that qemu user can read the iso image and it seams to work correctly on the straight path.

Nir, do you know if also the VDSM user should be able to read the ISO image for any other purposes?

(In reply to Simone Tiraboschi from comment #1)
> Now I'm just checking that qemu user can read the iso image and it seams to
> work correctly on the straight path.
> 
> Nir, do you know if also the VDSM user should be able to read the ISO image
> for any other purposes?

I don't think that vdsm is trying to access the iso image, but it may have code that check permissions on the image that will fail and complain if the permissions are not expected.

Typically we use vdsm:qemu for vdsm images, so keeping the same permissions for files and devices accessed by vdsm or qemu would be the best way.

(In reply to Nir Soffer from comment #2)
> I don't think that vdsm is trying to access the iso image, but it may have
> code that check permissions on the image that will fail and complain if the
> permissions are not expected.
> 
> Typically we use vdsm:qemu for vdsm images, so keeping the same permissions
> for files and devices accessed by vdsm or qemu would be the best way.

It's exactly what we did but it's not correct.
At least qemu user should be able to access the iso file otherwise it's not able to start that VM.

If the iso file is 600 and vdsm:kvm, qemu cannot read it but our previous test didn't detect it.

Now we are simply checking about qemu.
If needed we can check for both qemu and vdsm.

Automated message: can you please update doctext or set it as not required?

Entering the ISO path it's up to the user.
Choose CDRom and than when asked the path you prefer

(In reply to Simone Tiraboschi from comment #7)
> Entering the ISO path it's up to the user.
> Choose CDRom and than when asked the path you prefer

That's indeed, but I have to have ISO of the image to be booted from, so in this case I need an ISO of the engine. Where can I get one?

On manual setup you are going to deploy the engine VM installing the OS and only after installing oVirt engine and then manually executing engine-setup.
So this one is just a RHEL/Centos/Fedora ISO from a supported release.

(In reply to Simone Tiraboschi from comment #9)
> On manual setup you are going to deploy the engine VM installing the OS and
> only after installing oVirt engine and then manually executing engine-setup.
> So this one is just a RHEL/Centos/Fedora ISO from a supported release.

Steps to Reproduce:
1. copy an iso image to the host
2. set the ownership of that file to vdsm:kvm and its permission to 600 
3. launch hosted-engine --deploy selecting that iso

1.Again, I need a link to relevant ISO for the installation.
2.chmod 600
3.launch hosted-engine --deploy selecting that iso by linking the installation via CDROM path to local directory in which image is located.

We're installing all images using PXE, so for this one I need and ISO file link.

(In reply to Nikolai Sednev from comment #10)
> (In reply to Simone Tiraboschi from comment #9)
> > On manual setup you are going to deploy the engine VM installing the OS and
> > only after installing oVirt engine and then manually executing engine-setup.
> > So this one is just a RHEL/Centos/Fedora ISO from a supported release.
> 
> Steps to Reproduce:
> 1. copy an iso image to the host
> 2. set the ownership of that file to vdsm:kvm and its permission to 600 
> 3. launch hosted-engine --deploy selecting that iso
> 
> 1.Again, I need a link to relevant ISO for the installation.

http://it.centos.contactlab.it/7/isos/x86_64/CentOS-7-x86_64-DVD-1503-01.iso

> 2.chmod 600
> 3.launch hosted-engine --deploy selecting that iso by linking the
> installation via CDROM path to local directory in which image is located.
> 
> We're installing all images using PXE, so for this one I need and ISO file
> link.

Tested on these components:
ovirt-hosted-engine-setup-1.3.0-0.4.beta.git42eb801.el7ev.noarch
mom-0.5.0-1.el7ev.noarch
vdsm-4.17.3-1.el7ev.noarch
libvirt-client-1.2.17-6.el7.x86_64
qemu-kvm-rhev-2.3.0-19.el7.x86_64
sanlock-3.2.4-1.el7.x86_64
Red Hat Enterprise Linux Server release 7.2 Beta (Maipo)

Got this error:
[ ERROR ] The specified installation media is not valid or not readable. Please ensure that /tmp is valid and could be read by qemu user or kvm group or specify another installation media.

Logs from deployment attached.




wget http://it.centos.contactlab.it/7/isos/x86_64/CentOS-7-x86_64-DVD-1503-01.iso
# id vdsm
uid=36(vdsm) gid=36(kvm) groups=36(kvm),179(sanlock),107(qemu)
# chown -R vdsm:kvm CentOS-7-x86_64-DVD-1503-01.iso
# chmod 600 CentOS-7-x86_64-DVD-1503-01.iso
# ls -ld /tmp/CentOS-7-x86_64-DVD-1503-01.iso
-rw-------. 1 vdsm kvm 4310695936 Aug 27 14:51 /tmp/CentOS-7-x86_64-DVD-1503-01.iso

Created attachment 1067717 [details]
logs_from_host

(In reply to Nikolai Sednev from comment #12)
> Tested on these components:
> ovirt-hosted-engine-setup-1.3.0-0.4.beta.git42eb801.el7ev.noarch
> mom-0.5.0-1.el7ev.noarch
> vdsm-4.17.3-1.el7ev.noarch
> libvirt-client-1.2.17-6.el7.x86_64
> qemu-kvm-rhev-2.3.0-19.el7.x86_64
> sanlock-3.2.4-1.el7.x86_64
> Red Hat Enterprise Linux Server release 7.2 Beta (Maipo)
> 
> Got this error:
> [ ERROR ] The specified installation media is not valid or not readable.
> Please ensure that /tmp is valid and could be read by qemu user or kvm group
> or specify another installation media.

Expected results:
An error about the ISO permission is reported to the user

It was the expected result: in order to start the the VM from the iso image, qemu user or kvm group should be able to read the CDROM otherwise it will fail. In the past we where checking for vdsm user which was wrong.

(In reply to Simone Tiraboschi from comment #14)
> Expected results:
> An error about the ISO permission is reported to the user
> 
> It was the expected result: in order to start the the VM from the iso image,
> qemu user or kvm group should be able to read the CDROM otherwise it will
> fail. In the past we where checking for vdsm user which was wrong.

Please retry also the positive flow having its owner to qemu:kvm and its permission to 600 and it should pass the test and than work

(In reply to Simone Tiraboschi from comment #15)
> (In reply to Simone Tiraboschi from comment #14)
> > Expected results:
> > An error about the ISO permission is reported to the user
> > 
> > It was the expected result: in order to start the the VM from the iso image,
> > qemu user or kvm group should be able to read the CDROM otherwise it will
> > fail. In the past we where checking for vdsm user which was wrong.
> 
> Please retry also the positive flow having its owner to qemu:kvm and its
> permission to 600 and it should pass the test and than work

Works for me on these components:
mom-0.5.0-1.el7ev.noarch
ovirt-host-deploy-1.4.0-0.0.4.master.el7ev.noarch
vdsm-4.17.3-1.el7ev.noarch
ovirt-setup-lib-1.0.0-0.1.master.git6a54bc0.el7ev.noarch
libvirt-client-1.2.17-6.el7.x86_64
qemu-kvm-rhev-2.3.0-19.el7.x86_64
ovirt-vmconsole-1.0.0-0.0.master.el7ev.noarch
ovirt-vmconsole-host-1.0.0-0.0.master.el7ev.noarch
sanlock-3.2.4-1.el7.x86_64
ovirt-hosted-engine-ha-1.3.0-0.3.beta.git183a4ff.el7ev.noarch
ovirt-hosted-engine-setup-1.3.0-0.4.beta.git42eb801.el7ev.noarch
Red Hat Enterprise Linux Server release 7.2 Beta (Maipo)


Setup was able to successfully continue to next steps after receiving CDROM path with following access restrictions:
chown qemu:kvm /tmp/CentOS-7-x86_64-DVD-1503-01.iso
chmod 600 CentOS-7-x86_64-DVD-1503-01.iso
# ls -ld /tmp/CentOS-7-x86_64-DVD-1503-01.iso
-rw-------. 1 qemu kvm 4310695936 Aug 27 14:51 /tmp/CentOS-7-x86_64-DVD-1503-01.iso
# id qemu
uid=107(qemu) gid=107(qemu) groups=107(qemu),11(cdrom),36(kvm)

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2016-0375.html

I wanted to point this out, since I ran into this issue and came searching for the answer, and resolved the issue when I realized that the user 'vdsm' and group 'kvm' do not have read access to /root which is where I was downloading the ISO.

Perhaps the initial reporter had the same issue.