On Fri, May 6, 2016 at 3:08 PM, Sahina Bose wrote:
> Hi,
>
> Back to Import Storage domain questions -
>
> To ensure consistency, we snapshot the running VMs prior to replicating
> the gluster volume to a central site. The VMs have been setup such that OS
> disks are on a gluster volume called "vmstore" and non-OS disks are on a
> gluster volume called "data"
> For back up , we are only interested in "data" - so only this storage
> domain is imported at backup recovery site.
>
> Since the "data" storage domain does not contain all disks - VMs cannot be
> imported - that's expected.
>
> To retrieve the backed up disks - since the disk has snapshot - this does
> not seem possible either. How do we work around this?
>
Since the engine can't support floating disks with snapshot you can try to
merge those snapshots (by using qemu-img merge and qemu-img rebase.) until
there will be only one volume left.
Once there will be only one volume oVirt can import the disk.
Another workaround might be that if you still have the setup which could
not import the VM because of missing volume, then, you can try manipulate
the OVF in the Data Base.
The VMs' and Template's XML representation are contained in the
"unregistered_ovf_of_entities" table.
You can fetch the VM's OVF from that table:
SELECT ovf_data FROM unregistered_ovf_of_entities where entity_name ilike
'%(the VM name (You can also fetch by id with entity_id))%';
Update the OVF with the correlated volume ids in the storage server. After
updating this, the import of the VM should work
>
> thanks!
>
>
>
> On 05/03/2016 03:21 PM, Maor Lipchuk wrote:
>
>> There is this bug https://bugzilla.redhat.com/1270562 which forces
>> OVF_STORE update but it is not yet implemented.
>>
>> On Tue, May 3, 2016 at 8:52 AM, Sahina Bose wrote:
>>
>>>
>>> On 05/02/2016 09:36 PM, Maor Lipchuk wrote:
>>>
On Mon, May 2, 2016 at 5:45 PM, Sahina Bose wrote:
>
>
> On 05/02/2016 05:57 PM, Maor Lipchuk wrote:
>
>
>
> On Mon, May 2, 2016 at 1:08 PM, Sahina Bose wrote:
>
>>
>>
>> On 05/02/2016 03:15 PM, Maor Lipchuk wrote:
>>
>>
>>
>> On Mon, May 2, 2016 at 12:29 PM, Sahina Bose
>> 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)
>>> v
