Re: [ovirt-users] Import storage domain - disks not listed

On 05/01/2016 05:33 AM, Maor Lipchuk wrote: Hi Sahina, The disks with snapshots should be part of the VMs, once you will register those VMs you should see those disks in the disks sub tab. Maor, I was unable to import VM which prompted question - I assumed we had to register disks first. So maybe I need to troubleshoot why I could not import VMs from the domain first. It fails with an error "Image does not exist". Where does it look for volume IDs to pass to GetImageInfoVDSCommand - the OVF disk?

In engine.log 2016-05-02 04:15:14,812 ERROR [org.ovirt.engine.core.vdsbroker.irsbroker.GetImageInfoVDSCommand] (ajp-/127.0.0.1:8702-1) [32f0b27c] Ir sBroker::getImageInfo::Failed getting image info imageId='6f4da17a-05a2-4d77-8091-d2fca3bbea1c' does not exist on domainName='sahinasl ave', domainId='5e1a37cf-933d-424c-8e3d-eb9e40b690a7', error code: 'VolumeDoesNotExist', message: Volume does not exist: (u'6f4da17a-0 5a2-4d77-8091-d2fca3bbea1c',) 2016-05-02 04:15:14,814 WARN [org.ovirt.engine.core.vdsbroker.irsbroker.DoesImageExistVDSCommand] (ajp-/127.0.0.1:8702-1) [32f0b27c] executeIrsBrokerCommand: getImageInfo on '6f4da17a-05a2-4d77-8091-d2fca3bbea1c' threw an exception - assuming image doesn't exist: IRS GenericException: IRSErrorException: VolumeDoesNotExist 2016-05-02 04:15:14,814 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.DoesImageExistVDSCommand] (ajp-/127.0.0.1:8702-1) [32f0b27c] FINISH, DoesImageExistVDSCommand, return: false, log id: 3366f39b 2016-05-02 04:15:14,814 WARN [org.ovirt.engine.core.bll.ImportVmFromConfigurationCommand] (ajp-/127.0.0.1:8702-1) [32f0b27c] CanDoAction of action 'ImportVmFromConfiguration' failed for user admin@internal. Reasons: VAR__ACTION__IMPORT,VAR__TYPE__VM,ACTION_TYPE_FAILED_VM_IMAGE_DOES_NOT_EXIST jsonrpc.Executor/2::DEBUG::2016-05-02 13:45:13,903::__init__::503::jsonrpc.JsonRpcServer::(_serveRequest) Calling 'Volume.getInfo' in bridge with {u'imageID': u'c52e4e02-dc6c-4a77-a184-9fcab88106c2', u'storagepoolID': u'46ac4975-a84e-4e76-8e73-7971d0dadf0b', u'volumeI D': u'6f4da17a-05a2-4d77-8091-d2fca3bbea1c', u'storagedomainID': u'5e1a37cf-933d-424c-8e3d-eb9e40b690a7'} jsonrpc.Executor/2::DEBUG::2016-05-02 13:45:13,910::fileVolume::535::Storage.Volume::(validateVolumePath) validate path for 6f4da17a-05a2-4d77-8091-d2fca3bbea1c jsonrpc.Executor/2::ERROR::2016-05-02 13:45:13,914::task::866::Storage.TaskManager.Task::(_setError) Task=`94dba16f-f7eb-439e-95e2-a04b34b92f84`::Unexpected error Traceback (most recent call last): File "/usr/share/vdsm/storage/task.py", line 873, in _run return fn(*args, **kargs) File "/usr/share/vdsm/logUtils.py", line 49, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/storage/hsm.py", line 3162, in getVolumeInfo volUUID=volUUID).getInfo() File "/usr/share/vdsm/storage/sd.py", line 457, in produceVolume volUUID) File "/usr/share/vdsm/storage/glusterVolume.py", line 16, in __init__ volUUID) File "/usr/share/vdsm/storage/fileVolume.py", line 58, in __init__ volume.Volume.__init__(self, repoPath, sdUUID, imgUUID, volUUID) File "/usr/share/vdsm/storage/volume.py", line 181, in __init__ self.validate() File "/usr/share/vdsm/storage/volume.py", line 194, in validate self.validateVolumePath() File "/usr/share/vdsm/storage/fileVolume.py", line 540, in validateVolumePath raise se.VolumeDoesNotExist(self.volUUID) VolumeDoesNotExist: Volume does not exist: (u'6f4da17a-05a2-4d77-8091-d2fca3bbea1c',) When I look at the tree output - there's no 6f4da17a-05a2-4d77-8091-d2fca3bbea1c file. ├── c52e4e02-dc6c-4a77-a184-9fcab88106c2 │ │ │ ├── 34e46104-8fad-4510-a5bf-0730b97a6659 │ │ │ ├── 34e46104-8fad-4510-a5bf-0730b97a6659.lease │ │ │ ├── 34e46104-8fad-4510-a5bf-0730b97a6659.meta │ │ │ ├── 766a15b9-57db-417d-bfa0-beadbbb84ad2 │ │ │ ├── 766a15b9-57db-417d-bfa0-beadbbb84ad2.lease │ │ │ ├── 766a15b9-57db-417d-bfa0-beadbbb84ad2.meta │ │ │ ├── 90f1e26a-00e9-4ea5-9e92-2e448b9b8bfa │ │ │ ├── 90f1e26a-00e9-4ea5-9e92-2e448b9b8bfa.lease │ │ │ └── 90f1e26a-00e9-4ea5-9e92-2e448b9b8bfa.meta

Regarding floating disks (without snapshots), you can register them through REST. If you are working on the master branch there should be a sub tab dedicated for those also. Regards, Maor On Tue, Apr 26, 2016 at 1:44 PM, Sahina Bose < <sabose(a)redhat.com&gt; sabose(a)redhat.com&gt; wrote: > Hi all, > > I have a gluster volume used as data storage domain which is replicated > to a slave gluster volume (say, slavevol) using gluster's geo-replication > feature. > > Now, in a new oVirt instance, I use the import storage domain to import > the slave gluster volume. The "VM Import" tab correctly lists the VMs that > were present in my original gluster volume. However the "Disks" tab is > empty. > > GET > https://new-ovitt/api/storagedomains/5e1a37cf-933d-424c-8e3d-eb9e40b690a7... > --> > <disks/> > > > In the code GetUnregisteredDiskQuery - if volumesList.size() != 1 - the > image is skipped with a comment that we can't deal with snapshots. > > How do I recover the disks/images in this case? > > > Further info: > > /rhev/data-center/mnt/glusterSD/10.70.40.112:_slavevol > ├── 5e1a37cf-933d-424c-8e3d-eb9e40b690a7 > │ ├── dom_md > │ │ ├── ids > │ │ ├── inbox > │ │ ├── leases > │ │ ├── metadata > │ │ └── outbox > │ ├── images > │ │ ├── 202efaa6-0d01-40f3-a541-10eee920d221 > │ │ │ ├── eb701046-6ee1-4c9d-b097-e51a8fd283e1 > │ │ │ ├── eb701046-6ee1-4c9d-b097-e51a8fd283e1.lease > │ │ │ └── eb701046-6ee1-4c9d-b097-e51a8fd283e1.meta > │ │ ├── c52e4e02-dc6c-4a77-a184-9fcab88106c2 > │ │ │ ├── 34e46104-8fad-4510-a5bf-0730b97a6659 > │ │ │ ├── 34e46104-8fad-4510-a5bf-0730b97a6659.lease > │ │ │ ├── 34e46104-8fad-4510-a5bf-0730b97a6659.meta > │ │ │ ├── 766a15b9-57db-417d-bfa0-beadbbb84ad2 > │ │ │ ├── 766a15b9-57db-417d-bfa0-beadbbb84ad2.lease > │ │ │ ├── 766a15b9-57db-417d-bfa0-beadbbb84ad2.meta > │ │ │ ├── 90f1e26a-00e9-4ea5-9e92-2e448b9b8bfa > │ │ │ ├── 90f1e26a-00e9-4ea5-9e92-2e448b9b8bfa.lease > │ │ │ └── 90f1e26a-00e9-4ea5-9e92-2e448b9b8bfa.meta > │ │ ├── c75de5b7-aa88-48d7-ba1b-067181eac6ae > │ │ │ ├── ff09e16a-e8a0-452b-b95c-e160e68d09a9 > │ │ │ ├── ff09e16a-e8a0-452b-b95c-e160e68d09a9.lease > │ │ │ └── ff09e16a-e8a0-452b-b95c-e160e68d09a9.meta > │ │ ├── efa94a0d-c08e-4ad9-983b-4d1d76bca865 > │ │ │ ├── 64e3913c-da91-447c-8b69-1cff1f34e4b7 > │ │ │ ├── 64e3913c-da91-447c-8b69-1cff1f34e4b7.lease > │ │ │ ├── 64e3913c-da91-447c-8b69-1cff1f34e4b7.meta > │ │ │ ├── 8174e8b4-3605-4db3-86a1-cb62c3a079f4 > │ │ │ ├── 8174e8b4-3605-4db3-86a1-cb62c3a079f4.lease > │ │ │ ├── 8174e8b4-3605-4db3-86a1-cb62c3a079f4.meta > │ │ │ ├── e79a8821-bb4a-436a-902d-3876f107dd99 > │ │ │ ├── e79a8821-bb4a-436a-902d-3876f107dd99.lease > │ │ │ └── e79a8821-bb4a-436a-902d-3876f107dd99.meta > │ │ └── f5eacc6e-4f16-4aa5-99ad-53ac1cda75b7 > │ │ ├── 476bbfe9-1805-4c43-bde6-e7de5f7bd75d > │ │ ├── 476bbfe9-1805-4c43-bde6-e7de5f7bd75d.lease > │ │ └── 476bbfe9-1805-4c43-bde6-e7de5f7bd75d.meta > │ └── master > │ ├── tasks > │ └── vms > └── __DIRECT_IO_TEST__ > > engine.log: > 2016-04-26 06:37:57,715 INFO > [org.ovirt.engine.core.vdsbroker.irsbroker.GetImageInfoVDSCommand] > (org.ovirt.thread.pool-6-thread-25) [5e6b7a53] FINISH, > GetImageInfoVDSCommand, return: org.ov > irt.engine.core.common.businessentities.storage.DiskImage@d4b3ac2f, log > id: 7b693bad > 2016-04-26 06:37:57,724 INFO > [org.ovirt.engine.core.vdsbroker.irsbroker.GetVolumesListVDSCommand] > (org.ovirt.thread.pool-6-thread-25) [5e6b7a53] START, > GetVolumesListVDSCommand( StoragePool > DomainAndGroupIdBaseVDSCommandParameters:{runAsync='true', > storagePoolId='ed338557-5995-4634-97e2-15454a9d8800', > ignoreFailoverLimit='false', > storageDomainId='5e1a37cf-933d-424c-8e3d-eb9e40b > 690a7', imageGroupId='c52e4e02-dc6c-4a77-a184-9fcab88106c2'}), log id: > 741b9214 > 2016-04-26 06:37:58,748 INFO > [org.ovirt.engine.core.vdsbroker.irsbroker.GetVolumesListVDSCommand] > (org.ovirt.thread.pool-6-thread-25) [5e6b7a53] FINISH, > GetVolumesListVDSCommand, return: [9 > 0f1e26a-00e9-4ea5-9e92-2e448b9b8bfa, > 766a15b9-57db-417d-bfa0-beadbbb84ad2, > 34e46104-8fad-4510-a5bf-0730b97a6659], log id: 741b9214 > > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users >