On 05/02/2016 03:15 PM, Maor Lipchuk wrote:


On Mon, May 2, 2016 at 12:29 PM, Sahina Bose <sab...@redhat.com <mailto:sab...@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 <sab...@redhat.com
    <mailto:sab...@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@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@ovirt.org <mailto:Users@ovirt.org>
        http://lists.ovirt.org/mailman/listinfo/users





_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Reply via email to