6:08 a.m.
This is a multi-part message in MIME format.
--------------080207070706080506070807
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
On 05/02/2016 03:15 PM, Maor Lipchuk wrote:
On Mon, May 2, 2016 at 12:29 PM, Sahina Bose <sabose(a)redhat.com
<mailto:sabose@redhat.com>> wrote:
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
Usually the "image does not exists" message is prompted once the VM's
disk is managed in a different storage domain which were not imported yet.
Few questions:
1. Were there any other Storage Domain which are not present in the setup?
In the original RHEV instance - there were 3 storage domain
i) Hosted engine storage domain: engine
ii) Master data domain: vmstore
iii) An export domain: expVol (no data here)
To my backup RHEV server, I only imported vmstore.
2. Can you look for the image id 6f4da17a-05a2-4d77-8091-d2fca3bbea1c
in your storage server (Search on all the rest of the storage domains)?
No - there was no file with this id (checked both in the original RHEV
instance)
[root@dhcp42-105 mnt]# pwd
/rhev/data-center/mnt
[root@dhcp42-105 mnt]# find . -name 6f4da17a-05a2-4d77-8091-d2fca3bbea1c
[root@dhcp42-105 mnt]#
Were there any operations being done on the VM before the recovery
such as remove disk, move disk, or a new creation of a disk?
No. The only operation done was creation of a snapshot - and it
completed before the recovery was attempted.
Regards,
Maor
>
> 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
> <mailto:sabose@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/>
>
>
> 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 <mailto:Users@ovirt.org>
> http://lists.ovirt.org/mailman/listinfo/users
>
>
--------------080207070706080506070807
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=utf-8"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">On 05/02/2016 03:15 PM, Maor Lipchuk
wrote:<br>
</div>
<blockquote
cite="mid:CAJ1JNOe51AgPnb-kaMLvzu=Kuchi1kU-SnsaXzW5m+mAUtsVGA@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, May 2, 2016 at 12:29 PM,
Sahina Bose <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:sabose@redhat.com"
target="_blank">sabose(a)redhat.com</a>&gt;</span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span
class=""> <br>
<br>
<div>On 05/01/2016 05:33 AM, Maor Lipchuk wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi Sahina,
<div><br>
</div>
<div>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.<br>
</div>
</div>
</blockquote>
<br>
</span> Maor,<br>
<br>
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.<br>
It fails with an error "Image does not exist". Where
does it look for volume IDs to pass to
GetImageInfoVDSCommand - the OVF disk?<br>
</div>
</blockquote>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><br>
In engine.log<br>
<br>
2016-05-02 04:15:14,812 ERROR
[org.ovirt.engine.core.vdsbroker.irsbroker.GetImageInfoVDSCommand]
(ajp-/127.0.0.1:8702-1) [32f0b27c] Ir<br>
sBroker::getImageInfo::Failed getting image info
imageId='6f4da17a-05a2-4d77-8091-d2fca3bbea1c' does not
exist on domainName='sahinasl<br>
ave', domainId='5e1a37cf-933d-424c-8e3d-eb9e40b690a7',
error code: 'VolumeDoesNotExist', message: Volume does
not exist: (u'6f4da17a-0<br>
5a2-4d77-8091-d2fca3bbea1c',)<br>
2016-05-02 04:15:14,814 WARN
[org.ovirt.engine.core.vdsbroker.irsbroker.DoesImageExistVDSCommand]
(ajp-/127.0.0.1:8702-1) [32f0b27c] <br>
executeIrsBrokerCommand: getImageInfo on
'6f4da17a-05a2-4d77-8091-d2fca3bbea1c' threw an
exception - assuming image doesn't exist: IRS<br>
GenericException: IRSErrorException: VolumeDoesNotExist<br>
2016-05-02 04:15:14,814 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.DoesImageExistVDSCommand]
(ajp-/127.0.0.1:8702-1) [32f0b27c] <br>
FINISH, DoesImageExistVDSCommand, return: false, log id:
3366f39b<br>
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<br>
<br>
<br>
<br>
jsonrpc.Executor/2::DEBUG::2016-05-02
13:45:13,903::__init__::503::jsonrpc.JsonRpcServer::(_serveRequest)
Calling 'Volume.getInfo' in <br>
bridge with {u'imageID':
u'c52e4e02-dc6c-4a77-a184-9fcab88106c2',
u'storagepoolID':
u'46ac4975-a84e-4e76-8e73-7971d0dadf0b', u'volumeI<br>
D': u'6f4da17a-05a2-4d77-8091-d2fca3bbea1c',
u'storagedomainID':
u'5e1a37cf-933d-424c-8e3d-eb9e40b690a7'}<br>
<br>
jsonrpc.Executor/2::DEBUG::2016-05-02
13:45:13,910::fileVolume::535::Storage.Volume::(validateVolumePath)
validate path for 6f4da17a-05a2-4d77-8091-d2fca3bbea1c<br>
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<br>
Traceback (most recent call last):<br>
File "/usr/share/vdsm/storage/task.py", line 873, in
_run<br>
return fn(*args, **kargs)<br>
File "/usr/share/vdsm/logUtils.py", line 49, in
wrapper<br>
res = f(*args, **kwargs)<br>
File "/usr/share/vdsm/storage/hsm.py", line 3162, in
getVolumeInfo<br>
volUUID=volUUID).getInfo()<br>
File "/usr/share/vdsm/storage/sd.py", line 457, in
produceVolume<br>
volUUID)<br>
File "/usr/share/vdsm/storage/glusterVolume.py", line
16, in __init__<br>
volUUID)<br>
File "/usr/share/vdsm/storage/fileVolume.py", line 58,
in __init__<br>
volume.Volume.__init__(self, repoPath, sdUUID,
imgUUID, volUUID)<br>
File "/usr/share/vdsm/storage/volume.py", line 181, in
__init__<br>
self.validate()<br>
File "/usr/share/vdsm/storage/volume.py", line 194, in
validate<br>
self.validateVolumePath()<br>
File "/usr/share/vdsm/storage/fileVolume.py", line
540, in validateVolumePath<br>
raise se.VolumeDoesNotExist(self.volUUID)<br>
VolumeDoesNotExist: Volume does not exist:
(u'6f4da17a-05a2-4d77-8091-d2fca3bbea1c',)<br>
<br>
When I look at the tree output - there's no
6f4da17a-05a2-4d77-8091-d2fca3bbea1c file.
<div>
<div class="h5"><br>
<br>
├── c52e4e02-dc6c-4a77-a184-9fcab88106c2<br>
│ │ │ ├── 34e46104-8fad-4510-a5bf-0730b97a6659<br>
│ │ │ ├──
34e46104-8fad-4510-a5bf-0730b97a6659.lease<br>
│ │ │ ├──
34e46104-8fad-4510-a5bf-0730b97a6659.meta<br>
│ │ │ ├── 766a15b9-57db-417d-bfa0-beadbbb84ad2<br>
│ │ │ ├──
766a15b9-57db-417d-bfa0-beadbbb84ad2.lease<br>
│ │ │ ├──
766a15b9-57db-417d-bfa0-beadbbb84ad2.meta<br>
│ │ │ ├── 90f1e26a-00e9-4ea5-9e92-2e448b9b8bfa<br>
│ │ │ ├──
90f1e26a-00e9-4ea5-9e92-2e448b9b8bfa.lease<br>
│ │ │ └──
90f1e26a-00e9-4ea5-9e92-2e448b9b8bfa.meta<br>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div>Usually the "image does not exists" message is prompted
once the VM's disk is managed in a different storage
domain which were not imported yet.</div>
<div><br>
</div>
<div>Few questions:</div>
<div>1. Were there any other Storage Domain which are not
present in the setup?</div>
</div>
</div>
</div>
</blockquote>
<br>
In the original RHEV instance - there were 3 storage domain<br>
i) Hosted engine storage domain: engine<br>
ii) Master data domain: vmstore<br>
iii) An export domain: expVol (no data here)<br>
<br>
To my backup RHEV server, I only imported vmstore.<br>
<br>
<blockquote
cite="mid:CAJ1JNOe51AgPnb-kaMLvzu=Kuchi1kU-SnsaXzW5m+mAUtsVGA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>2. Can you look for the image id
6f4da17a-05a2-4d77-8091-d2fca3bbea1c in your storage
server (Search on all the rest of the storage domains)?</div>
</div>
</div>
</div>
</blockquote>
<br>
No - there was no file with this id (checked both in the original
RHEV instance)<br>
[root@dhcp42-105 mnt]# pwd<br>
/rhev/data-center/mnt<br>
[root@dhcp42-105 mnt]# find . -name
6f4da17a-05a2-4d77-8091-d2fca3bbea1c<br>
[root@dhcp42-105 mnt]# <br>
<br>
<br>
<blockquote
cite="mid:CAJ1JNOe51AgPnb-kaMLvzu=Kuchi1kU-SnsaXzW5m+mAUtsVGA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>Were there any operations being done on the VM before
the recovery such as remove disk, move disk, or a new
creation of a disk?<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
No. The only operation done was creation of a snapshot - and it
completed before the recovery was attempted.<br>
<br>
<blockquote
cite="mid:CAJ1JNOe51AgPnb-kaMLvzu=Kuchi1kU-SnsaXzW5m+mAUtsVGA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Regards,</div>
<div>Maor</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>
<div class="h5">
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Regarding floating disks (without
snapshots), you can register them through
REST.</div>
<div>If you are working on the master branch
there should be a sub tab dedicated for those
also.</div>
<div><br>
</div>
<div>Regards,</div>
<div>Maor</div>
<div>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Apr 26,
2016 at 1:44 PM, Sahina Bose <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:sabose@redhat.com"
target="_blank"><a
class="moz-txt-link-abbreviated"
href="mailto:sabose@redhat.com">sabose@redhat.com</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi
all,<br>
<br>
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.<br>
<br>
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.<br>
<br>
GET <a moz-do-not-send="true"
href="https://new-ovitt/api/storagedomains/5e1a37cf-933d-424c-8e3d-eb9e40b690a7/disks;unregistered"
rel="noreferrer"
target="_blank">https://new-ovitt/api/storagedomains/5e1a37cf-933d-424c-8e3d-eb9e40b690a7/disks;unregistered</a>
--><br>
<disks/><br>
<br>
<br>
In the code GetUnregisteredDiskQuery -
if volumesList.size() != 1 - the image
is skipped with a comment that we
can't deal with snapshots.<br>
<br>
How do I recover the disks/images in
this case?<br>
<br>
<br>
Further info:<br>
<br>
/rhev/data-center/mnt/glusterSD/10.70.40.112:_slavevol<br>
├──
5e1a37cf-933d-424c-8e3d-eb9e40b690a7<br>
│ ├── dom_md<br>
│ │ ├── ids<br>
│ │ ├── inbox<br>
│ │ ├── leases<br>
│ │ ├── metadata<br>
│ │ └── outbox<br>
│ ├── images<br>
│ │ ├──
202efaa6-0d01-40f3-a541-10eee920d221<br>
│ │ │ ├──
eb701046-6ee1-4c9d-b097-e51a8fd283e1<br>
│ │ │ ├──
eb701046-6ee1-4c9d-b097-e51a8fd283e1.lease<br>
│ │ │ └──
eb701046-6ee1-4c9d-b097-e51a8fd283e1.meta<br>
│ │ ├──
c52e4e02-dc6c-4a77-a184-9fcab88106c2<br>
│ │ │ ├──
34e46104-8fad-4510-a5bf-0730b97a6659<br>
│ │ │ ├──
34e46104-8fad-4510-a5bf-0730b97a6659.lease<br>
│ │ │ ├──
34e46104-8fad-4510-a5bf-0730b97a6659.meta<br>
│ │ │ ├──
766a15b9-57db-417d-bfa0-beadbbb84ad2<br>
│ │ │ ├──
766a15b9-57db-417d-bfa0-beadbbb84ad2.lease<br>
│ │ │ ├──
766a15b9-57db-417d-bfa0-beadbbb84ad2.meta<br>
│ │ │ ├──
90f1e26a-00e9-4ea5-9e92-2e448b9b8bfa<br>
│ │ │ ├──
90f1e26a-00e9-4ea5-9e92-2e448b9b8bfa.lease<br>
│ │ │ └──
90f1e26a-00e9-4ea5-9e92-2e448b9b8bfa.meta<br>
│ │ ├──
c75de5b7-aa88-48d7-ba1b-067181eac6ae<br>
│ │ │ ├──
ff09e16a-e8a0-452b-b95c-e160e68d09a9<br>
│ │ │ ├──
ff09e16a-e8a0-452b-b95c-e160e68d09a9.lease<br>
│ │ │ └──
ff09e16a-e8a0-452b-b95c-e160e68d09a9.meta<br>
│ │ ├──
efa94a0d-c08e-4ad9-983b-4d1d76bca865<br>
│ │ │ ├──
64e3913c-da91-447c-8b69-1cff1f34e4b7<br>
│ │ │ ├──
64e3913c-da91-447c-8b69-1cff1f34e4b7.lease<br>
│ │ │ ├──
64e3913c-da91-447c-8b69-1cff1f34e4b7.meta<br>
│ │ │ ├──
8174e8b4-3605-4db3-86a1-cb62c3a079f4<br>
│ │ │ ├──
8174e8b4-3605-4db3-86a1-cb62c3a079f4.lease<br>
│ │ │ ├──
8174e8b4-3605-4db3-86a1-cb62c3a079f4.meta<br>
│ │ │ ├──
e79a8821-bb4a-436a-902d-3876f107dd99<br>
│ │ │ ├──
e79a8821-bb4a-436a-902d-3876f107dd99.lease<br>
│ │ │ └──
e79a8821-bb4a-436a-902d-3876f107dd99.meta<br>
│ │ └──
f5eacc6e-4f16-4aa5-99ad-53ac1cda75b7<br>
│ │ ├──
476bbfe9-1805-4c43-bde6-e7de5f7bd75d<br>
│ │ ├──
476bbfe9-1805-4c43-bde6-e7de5f7bd75d.lease<br>
│ │ └──
476bbfe9-1805-4c43-bde6-e7de5f7bd75d.meta<br>
│ └── master<br>
│ ├── tasks<br>
│ └── vms<br>
└── __DIRECT_IO_TEST__<br>
<br>
engine.log:<br>
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<br>
irt.engine.core.common.businessentities.storage.DiskImage@d4b3ac2f,
log id: 7b693bad<br>
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<br>
DomainAndGroupIdBaseVDSCommandParameters:{runAsync='true',
storagePoolId='ed338557-5995-4634-97e2-15454a9d8800',
ignoreFailoverLimit='false',
storageDomainId='5e1a37cf-933d-424c-8e3d-eb9e40b<br>
690a7',
imageGroupId='c52e4e02-dc6c-4a77-a184-9fcab88106c2'}),
log id: 741b9214<br>
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<br>
0f1e26a-00e9-4ea5-9e92-2e448b9b8bfa,
766a15b9-57db-417d-bfa0-beadbbb84ad2,
34e46104-8fad-4510-a5bf-0730b97a6659],
log id: 741b9214<br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a moz-do-not-send="true"
href="mailto:Users@ovirt.org"
target="_blank">Users(a)ovirt.org</a><br>
<a moz-do-not-send="true"
href="http://lists.ovirt.org/mailman/listinfo/users"
rel="noreferrer"
target="_blank">http://lists.ovirt.org/mailman/listinfo/user...
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>
--------------080207070706080506070807--