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

Sahina Bose sabose at redhat.com
Mon May 2 09:29:46 UTC 2016



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 at 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 at redhat.com 
> <mailto:sabose at redhat.com>> 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;unregistered
>     -->
>     <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 at 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 at ovirt.org <mailto:Users at ovirt.org>
>     http://lists.ovirt.org/mailman/listinfo/users
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20160502/41c41c82/attachment-0001.html>


More information about the Users mailing list