Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1065726

Summary:	The ISO uploader assumes that the storage domain uses NFS
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Ilia Meerovich <iliam>
Component:	ovirt-engine-iso-uploader	Assignee:	Sandro Bonazzola <sbonazzo>
Status:	CLOSED ERRATA	QA Contact:	Petr Beňas <pbenas>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	3.3.0	CC:	aberezin, acathrow, bazulay, dfediuck, didi, gklein, iheim, juan.hernandez, oramraz, pstehlik, Rhev-m-bugs, tpoitras, yeylon
Target Milestone:	---	Keywords:	ZStream
Target Release:	3.4.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	integration
Fixed In Version:	rhevm-iso-uploader-3.4.0-3.el6ev	Doc Type:	Bug Fix
Doc Text:	Previously, the ISO uploader failed to upload ISO images to local storage domains, wrongly assuming that all domains were NFS domains using NFS uploader backend. Now, users are notified that in order to upload to a local storage domain, they must supply SSH credentials and use SSH uploader backend.	Story Points:	---
Clone Of:
Clones:	1094632 (view as bug list)		Environment:
Last Closed:	2014-06-09 14:16:06 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1094632

Description Ilia Meerovich 2014-02-16 11:02:00 UTC

I tried to upload an image with rhevm-iso-domain without any success.
So I debugged rhevm-iso-domain with pdb and found that storage.get_address() in line 623 in https://github.com/oVirt/ovirt-iso-uploader/blob/master/src/__main__.py returns None. It seems that it should return host address.

So it seems sdk/api bug...

[root@ilia-rhevm ~]# rhevm-iso-uploader list
Please provide the REST API password for the admin@internal oVirt Engine user (CTRL+D to abort): 
ISO Storage Domain Name   | Datacenter                | ISO Domain Status
local_iso                 | local                     | active

[root@ilia-rhevm ~]# rhevm-iso-uploader upload -i local_iso  /mnt/iso/en_windows_7_ultimate_with_sp1_x64_dvd_u_677332.iso -v
Please provide the REST API password for the admin@internal oVirt Engine user (CTRL+D to abort): 
DEBUG: API Vendor(Red Hat)	API Version(3.3.0)
DEBUG: id=57469967-9b2e-4b9a-9f56-3efc2b4ddfaa address=None path=/data/images1
Uploading, please wait...
DEBUG: local NFS mount point is /tmp/tmpke4Gvc
DEBUG: NFS mount command (/bin/mount -t nfs -o rw,sync,soft None:/data/images1 /tmp/tmpke4Gvc)
DEBUG: /bin/mount -t nfs -o rw,sync,soft None:/data/images1 /tmp/tmpke4Gvc
DEBUG: _cmds(['/bin/mount', '-t', 'nfs', '-o', 'rw,sync,soft', 'None:/data/images1', '/tmp/tmpke4Gvc'])
DEBUG: returncode(32)
DEBUG: STDOUT()
DEBUG: STDERR(mount.nfs: Failed to resolve server None: Name or service not known
)
ERROR: mount.nfs: Failed to resolve server None: Name or service not known

DEBUG: /bin/umount -t nfs -f  /tmp/tmpke4Gvc
DEBUG: /bin/umount -t nfs -f  /tmp/tmpke4Gvc
DEBUG: _cmds(['/bin/umount', '-t', 'nfs', '-f', '/tmp/tmpke4Gvc'])
DEBUG: returncode(1)
DEBUG: STDOUT()
DEBUG: STDERR(umount2: Invalid argument
umount: /tmp/tmpke4Gvc: not mounted
)
DEBUG: umount2: Invalid argument
umount: /tmp/tmpke4Gvc: not mounted

[root@ilia-rhevm ~]# rpm -qa | grep rhevm
rhevm-branding-rhev-3.3.0-1.5.el6ev.noarch
rhevm-doc-3.3.0-3.el6eng.noarch
rhevm-spice-client-x86-msi-3.3-8.el6_5.noarch
rhevm-lib-3.3.1-0.47.el6ev.noarch
rhevm-webadmin-portal-3.3.1-0.47.el6ev.noarch
rhevm-iso-uploader-3.3.1-1.el6ev.noarch
rhevm-log-collector-3.3.1-6.el6ev.noarch
rhevm-setup-plugins-3.3.1-1.el6ev.noarch
rhevm-tools-3.3.1-0.47.el6ev.noarch
rhevm-restapi-3.3.1-0.47.el6ev.noarch
rhevm-spice-client-x64-cab-3.3-8.el6_5.noarch
rhevm-3.3.1-0.47.el6ev.noarch
rhevm-sdk-python-3.3.0.21-1.el6ev.noarch
rhevm-image-uploader-3.3.1-3.el6ev.noarch
rhevm-dependencies-3.3.5-1.el6ev.noarch
rhevm-websocket-proxy-3.3.1-0.47.el6ev.noarch
rhevm-backend-3.3.1-0.47.el6ev.noarch
rhevm-spice-client-x86-cab-3.3-8.el6_5.noarch
rhevm-userportal-3.3.1-0.47.el6ev.noarch
rhevm-cli-3.3.0.13-1.el6ev.noarch
rhevm-dbscripts-3.3.1-0.47.el6ev.noarch
rhevm-setup-3.3.1-0.47.el6ev.noarch
rhevm-spice-client-x64-msi-3.3-8.el6_5.noarch
[root@ilia-rhevm ~]#

Comment 1 Juan Hernández 2014-02-17 10:20:32 UTC

What kind of storage is using this "local_iso" domain? NFS? Can you connect to the REST API directly and provide the output for that storage domain?

curl \
-k \
-H "Accept: application/xml" \
-u admin@internal:your_password \
'https://your_host/api/storagedomains?search=ISOs'

Comment 2 Ilia Meerovich 2014-02-17 10:34:44 UTC

storage type: local

I don't have this setup alive now...

Comment 3 Juan Hernández 2014-02-17 10:41:58 UTC

Local storage domains can't be accessed from outside the machine. Assuming that it can be accessed using NFS is wrong in general (it could be accessible, if manually exported by the user). The RESTAPI doesn't provide any address for this kind of storage domain, as the RESTAPI doesn't know if/how the storage is exported with NFS.

I'm moving the bug to the ISO uploader, as it should check the type of the storage and refuse to use it if it isn't NFS.

Comment 4 Sandro Bonazzola 2014-02-17 16:04:51 UTC

I didn't know it was possible to define a local, non shared, iso domain.
And I don't think it works since for booting a VM on an hypervisor from an iso stored on a local storage on another system won't work AFAIK.

However, iso-uploader supports upload through ssh. 
It should fail gracefully if it can't upload using NFS and tell the user to use ssh.

I think we'll have similar issues also if the iso domain is on NFS but the ACL doesn't allow to mount it.

Comment 5 Juan Hernández 2014-02-17 16:14:40 UTC

A local ISO domain works because the data domain will also be local, thus machines can't move to any other host.

Comment 6 Ilia Meerovich 2014-02-18 06:20:15 UTC

I renamed the bug back since from customer point of view iso uploader should provide an option to upload iso files to local iso domain

Comment 7 Sandro Bonazzola 2014-05-05 15:41:43 UTC

iso-uploader has been designed thinking only at
NFS storage for iso images uploaded using nfs upload backend.
All other storage types have been delegated to ssh upload backend.
Added a check on localfs explaining that for that storage only
ssh upload is supported.

I considered adding a local file backend, but doing that is a large enough change to be considered an RFE.

Comment 10 Petr Beňas 2014-05-07 12:52:15 UTC

[root@pb-rh34 ~]# rpm -qa rhevm-iso-uploader
rhevm-iso-uploader-3.4.0-2.el6ev.noarch
[root@pb-rh34 ~]# rhevm-iso-uploader list
Please provide the REST API password for the admin@internal oVirt Engine user (CTRL+D to abort): 
ISO Storage Domain Name   | Datacenter                | ISO Domain Status
local_iso                 | local                     | active
[root@pb-rh34 ~]# rhevm-iso-uploader upload -i local_iso qwerty.iso 
Please provide the REST API password for the admin@internal oVirt Engine user (CTRL+D to abort): 
Uploading, please wait...
ERROR: mount.nfs: Failed to resolve server None: Name or service not known

[root@pb-rh34 ~]# rpm -qa rhevm-iso-uploader
rhevm-iso-uploader-3.4.0-3.el6ev.noarch
[root@pb-rh34 ~]# rhevm-iso-uploader list
Please provide the REST API password for the admin@internal oVirt Engine user (CTRL+D to abort): 
ISO Storage Domain Name   | Datacenter                | ISO Domain Status
local_iso                 | local                     | active
[root@pb-rh34 ~]# rhevm-iso-uploader upload -i local_iso qwerty.iso Please provide the REST API password for the admin@internal oVirt Engine user (CTRL+D to abort): 
Uploading, please wait...
ERROR: Upload to a local storage domain is supported only through SSH

Comment 12 errata-xmlrpc 2014-06-09 14:16:06 UTC

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.

http://rhn.redhat.com/errata/RHBA-2014-0666.html