Just an FYI I am using ovirt as an NFS Data Center MAIN,ISO,and EXPORT. I updated ovirt to newest rpms and reinstalled. I added one host machine. I then created another node (machine) using Openfiler and created NFS shares on that machine. Once permissions were set I was able to create Main storage (NFS), ISO (NFS), and Export (NFS). I mounted the ISO folder locally to one of my linux boxes and dropped Ubuntu and Fedora into the folder. It copied fine and I was able to see the new iso's in my attach a drive area when I went to install operating systems. I have just done all of that today.
Dominic On Wed, Feb 8, 2012 at 11:17 PM, Spyro Polymiadis <[email protected]> wrote: > sorry to jump on the bandwagon here - ive also uploaded an iso to the ISO > domain - which i said yes to create it locally on the engine-management > host. > default exported as /mnt/iso - i didnt have to manually do anything to add > it to the domain, only activate it. > > cat /etc/exports > /mnt/iso 0.0.0.0/0.0.0.0(rw) #rhev installer > > > i uploaded my iso like so: > > /usr/bin/engine-iso-uploader -i ISO -u admin@internal -r > ovirtmgr.foo.com:8443 upload os_2.0-784729f4-19.iso > > It finished successfully, the iso is owned vdsm.kvm and has the default > 640 permissions. > I tried setting them to 755 as mentioned in one of these threads - but > that didnt help.. > > $ tree -pug /mnt/iso > > /mnt/iso > └── [drwxr-xr-x vdsm kvm ] 23340f35-95ca-4b46-90ec-0c8b83a82786 > ├── [drwxr-xr-x vdsm kvm ] dom_md > │ ├── [-rw-r--r-- vdsm kvm ] ids > │ ├── [-rw-r--r-- vdsm kvm ] inbox > │ ├── [-rw-r--r-- vdsm kvm ] leases > │ ├── [-rw-r--r-- vdsm kvm ] metadata > │ └── [-rw-r--r-- vdsm kvm ] outbox > └── [drwxr-xr-x vdsm kvm ] images > └── [drwxr-xr-x vdsm kvm ] > 11111111-1111-1111-1111-111111111111 > └── [-rw-r----- vdsm kvm ] os_2.0-784729f4-19.iso > > I havent rebooted the ovirtmgr host yet incase that "fixes" it > > Any ideas? > > > ----- Original Message ----- > From: "Keith Robertson" <[email protected]> > To: "Andrew Dunlop" <[email protected]>, "Chris Brown (GE Healthcare)" < > [email protected]> > Cc: [email protected] > Sent: Saturday, 4 February, 2012 1:28:20 AM > Subject: Re: [Users] Unable to add ISOs to default ISO storage domain > > Andrew and Chris, > > You shouldn't need to manually place images on the NFS share and > subsequently chmod them. The ISO uploader should be doing both the > uploading and the chmod-ing for you, and if it is not doing this then > it's a bug. > > Here is a Successful Example: > [root@ovirt ~]# vim keith.iso <-- Create a junk file. > [root@ovirt ~]# chmod 400 keith.iso <-- Set restrictive perms on it. > [root@ovirt ~]# ovirt-iso-uploader -i iso1 upload keith.iso > Please provide the REST API password for RHEV-M (CTRL+D to abort): > > // Let's check our work... > [root@ovirt ~]# mount <ip scrubbed>:/data/ovirt/iso1 /mnt/isodomain/ <-- > mount the iso export domain > [root@ovirt ~]# su - vdsm > -bash-4.1$ ll > > /mnt/isodomain/92cf90c2-3698-48b5-84fd-d8e4f8684547/images/11111111-1111-1111-1111-111111111111/keith.iso > -rw-r-----. 1 vdsm kvm 10 Feb 3 07:45 > > /mnt/isodomain/92cf90c2-3698-48b5-84fd-d8e4f8684547/images/11111111-1111-1111-1111-111111111111/keith.iso > <-- w00t! > > > Andrew, to help me debug, could you... > 1. Is your ISO export domain being exported by a *nix system? If so can > you reply with the line in /etc/exports that does the exporting. It > looks something like mine below... > [root@inductor ~]# cat /etc/exports > /export *(rw,sync,no_root_squash) > > 2. Send me the output of "tree -pug" from the iso domain: > [root@ovirt ~]# su - vdsm > -bash-4.1$ cd /mnt/isodomain/92cf90c2-3698-48b5-84fd-d8e4f8684547/ > -bash-4.1$ tree -pug > dom_md/ images/ > -bash-4.1$ tree -pug images > images > └── [drwxr-xr-x vdsm kvm ] 11111111-1111-1111-1111-111111111111 > <snip> > > Cheers, > Keith > > > > > > > > > > On 02/03/2012 05:31 AM, Itamar Heim wrote: > > On 02/03/2012 11:26 AM, Andrew Dunlop wrote: > >> It would appear that the problem was the permissions on the files. > >> after I did a chmod 0755 to the .iso it appeared almost immediately in > >> the web admin. > >> Should the iso-uploader script not have changed the permissions of the > >> file? It appears to have set the correct owner. > > > > Keith ---^ ? > > > >> > >> On 2 February 2012 17:09, Brown, Chris (GE Healthcare) > >> <[email protected]> wrote: > >>> Easiest way to go about this, at least the way I go about it... > >>> Manually > >>> place your iso images on the NFS ISO share. > >>> This can be accomplished two ways: > >>> > >>> Example 1: If you have direct access to your fileserver EG: NAS/etc and > >>> it is linux based. > >>> Simply login and sftp/scp/NFS/CIFS retrieve and/or copy the images into > >>> > /export/path/to/iso/domain/<domUUID/images/11111111-1111-1111-1111-11111 > >>> > >>> 1111111 > >>> Then chown 36:36 > >>> > /export/path/to/iso/domain/<domUUID/images/11111111-1111-1111-1111-11111 > >>> > >>> 1111111/* > >>> > >>> Example 2: Mount said NFS mount point on another client and copy the > >>> images into it. > >>> Export on NFS server is for example /rhev/iso --> mount > >>> <servername_or_ip>:/rhev/iso /mnt > >>> Copy the images into > >>> /mnt/<domUUID/images/11111111-1111-1111-1111-111111111111/ > >>> Then chown 36:36 > >>> /mnt/<domUUID/images/11111111-1111-1111-1111-111111111111/* > >>> > >>> - Chris > >>> > >>> -----Original Message----- > >>> From: [email protected] [mailto:[email protected]] On > >>> Behalf > >>> Of Andrew Dunlop > >>> Sent: Thursday, February 02, 2012 10:59 AM > >>> To: [email protected] > >>> Subject: [Users] Unable to add ISOs to default ISO storage domain > >>> > >>> I have been trying to upload ISOs onto my ISO Storage Domain, set up > >>> when I ran engine-setup. > >>> I can run the command and the .iso file is correctly put in place, > >>> however this never appears in the available images for this domain on > >>> the web-admin. > >>> I notice that there are no file entries in > >>> > https://xxxx.xxxx.co.uk:8443/api/storagedomains/a677acff-601b-4b6d-86ce- > >>> > >>> 0798f3833629/files/ > >>> just what is given in the verbose output from the uploader. > >>> Any ideas what the problem might be? I have tried a couple of ISOs and > >>> have also done a cleanup and setup. > >>> > >>> Below is the verbose output from the uploader: > >>> > >>> [admin@xxxx ~]$ sudo engine-iso-uploader -v -f -i ISOs upload > >>> Downloads/TinyCore-current.iso [sudo] password for admin: > >>> Please provide the REST API password for the admin@internal oVirt > >>> Engine > >>> user (CTRL+D to abort): > >>> DEBUG: URL is > >>> https://xxxx.xxxx.co.uk:8443/api/storagedomains?search=name%3DISOs > >>> DEBUG: Returned XML is > >>> <?xml version="1.0" encoding="UTF-8" standalone="yes"?> > >>> <storage_domains> > >>> <storage_domain > >>> href="/api/storagedomains/a677acff-601b-4b6d-86ce-0798f3833629" > >>> id="a677acff-601b-4b6d-86ce-0798f3833629"> > >>> <name>ISOs</name> > >>> <link > >>> > href="/api/storagedomains/a677acff-601b-4b6d-86ce-0798f3833629/permissio > >>> > >>> ns" > >>> rel="permissions"/> > >>> <link > >>> href="/api/storagedomains/a677acff-601b-4b6d-86ce-0798f3833629/files" > >>> rel="files"/> > >>> <type>iso</type> > >>> <master>false</master> > >>> <storage> > >>> <type>nfs</type>srmr > >>> <address>xxxx.xxxx.co.uk</address> > >>> <path>/isos</path> > >>> </storage>users@ > >>> <available>48318382080</available> > >>> <used>4294967296</used> > >>> <committed>0</committed> > >>> <storage_format>v1</storage_format> > >>> </storage_domain> > >>> </storage_domains> > >>> > >>> DEBUG: id=a677acff-601b-4b6d-86ce-0798f3833629 address=xxxx.xxxx.co.uk > >>> path=/isos > >>> DEBUG: local NFS mount point is /tmp/tmpX03eVj > >>> DEBUG: NFS mount command (/bin/mount -t nfs -o rw,sync,soft > >>> xxxx.xxxx.co.uk:/isos /tmp/tmpX03eVj) > >>> DEBUG: /bin/mount -t nfs -o rw,sync,soft xxxx.xxxx.co.uk:/isos > >>> /tmp/tmpX03eVj > >>> DEBUG: _cmds(['/bin/mount', '-t', 'nfs', '-o', 'rw,sync,soft', > >>> 'xxxx.xxxx.co.uk:/isos', '/tmp/tmpX03eVj']) > >>> DEBUG: returncode(0) > >>> DEBUG: STDOUT() > >>> DEBUG: STDERR() > >>> DEBUG: Size of Downloads/TinyCore-current.iso: 12507136 bytes 12214.0 > >>> 1K-blocks 11.0 MB > >>> DEBUG: Available space in > >>> > /tmp/tmpX03eVj/a677acff-601b-4b6d-86ce-0798f3833629/images/11111111-1111 > >>> > >>> -1111-1111-111111111111: 48557457408 > >>> bytes 47419392.0 1K-blocks 46308.0 MB > >>> DEBUG: euid(0) egid(0) > >>> DEBUG: euid(0) egid(0) > >>> DEBUG: URL is > >>> > https://xxxx.xxxx.co.uk:8443/api/storagedomains/a677acff-601b-4b6d-86ce- > >>> > >>> 0798f3833629/files > >>> DEBUG: Returned XML is > >>> <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <files/> > >>> > >>> DEBUG: /bin/umount -t nfs -f /tmp/tmpX03eVj > >>> DEBUG: /bin/umount -t nfs -f /tmp/tmpX03eVj > >>> DEBUG: _cmds(['/bin/umount', '-t', 'nfs', '-f', '/tmp/tmpX03eVj']) > >>> DEBUG: returncode(0) > >>> DEBUG: STDOUT() > >>> DEBUG: STDERR() > >>> _______________________________________________ > >>> Users mailing list > >>> [email protected] > >>> http://lists.ovirt.org/mailman/listinfo/users > >> _______________________________________________ > >> Users mailing list > >> [email protected] > >> http://lists.ovirt.org/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/users > _______________________________________________ > Users mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/users > -- Dominic Kaiser Greater Boston Vineyard Director of Operations cell: 617-230-1412 fax: 617-252-0238 email: [email protected]
_______________________________________________ Users mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/users
