[ovirt-users] critical production issue for a vm

[Nathanaël Blanchet]

Many thanks to Nicolas who saved my life!

When the export of disks (base + snapshot) has finished, I managed to 
boot up the vm into libvirt/kvm with the top disk snapshot as the main disk.
Then, I believed reimporting the vm was the last thing to do, but 
integrated virt-v2v doesn't support importing vm with external 
snapshots, so when the importing process has finished, I couldn't boot 
up the vm.
I had to merge the snapshots with qemu tools:

qemu-img rebase-b  base.raw snap2.qcow2
qemu-img commit snap2.qcow2

And then, attaching the base image of each disk to the libvirt vm before 
reimporting it chosing "preallocated" for raw disks.

This is a manual method, but it was first necessary to find the disk id 
into lvm thanks to ovirt-shell: list disks --query "name=hortensia*" 
--show-all.

When finding the volume group id corresponding to the vm, I had to 
activate all the logical volume with lvchange -ay /dev/... and then 
finding qcow2 information with qemu-img info --backing-chain

*In this specific desastry, is there something to do with ovirt itself 
instead of exporting/reimporting, knowing that vm disks on the lun are 
intact, while the main reason is that the reference to some disks are 
broken into database?*


Le 06/12/2017 à 11:30, Nicolas Ecarnot a écrit :
> Le 06/12/2017 à 11:21, Nathanaël Blanchet a écrit :
>> Hi all,
>>
>> I'm about to lose one very important vm. I shut down this vm for 
>> maintenance and then I moved the four disks to a new created lun. 
>> This vm has 2 snapshots.
>>
>> After successful move, the vm refuses to start with this message:
>>
>> Bad volume specification {u'index': 0, u'domainID': 
>> u'961ea94a-aced-4dd0-a9f0-266ce1810177', 'reqsize': '0', u'format': 
>> u'cow', u'bootOrder': u'1', u'discard': False, u'volumeID': 
>> u'a0b6d5cb-db1e-4c25-aaaf-1bbee142c60b', 'apparentsize': 
>> '2147483648', u'imageID': u'4a95614e-bf1d-407c-aa72-2df414abcb7a', 
>> u'specParams': {}, u'readonly': u'false', u'iface': u'virtio', 
>> u'optional': u'false', u'deviceId': 
>> u'4a95614e-bf1d-407c-aa72-2df414abcb7a', 'truesize': '2147483648', 
>> u'poolID': u'48ca3019-9dbf-4ef3-98e9-08105d396350', u'device': 
>> u'disk', u'shared': u'false', u'propagateErrors': u'off', u'type': 
>> u'disk'}.
>>
>> I tried to merge the snaphots, export , clone from snapshot, copy 
>> disks, or deactivate disks and every action fails when it is about disk.
>>
>> I began to dd lv group to get a new vm intended to a standalone 
>> libvirt/kvm, the vm quite boots up but it is an outdated version 
>> before the first snapshot. There is a lot of disks when doing a "lvs 
>> | grep 961ea94a" supposed to be disks snapshots. Which of them must I 
>> choose to get the last vm before shutting down? I'm not used to deal 
>> snapshot with virsh/libvirt, so some help will be much appreciated.
>>
>> Is there some unknown command to recover this vm into ovirt?
>>
>> Thank you in advance.
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>
> Beside specific oVirt answers, did you try to get informations about 
> the snapshot tree with qemu-img info --backing-chain on the adequate 
> /dev/... logical volume?
> As you know how to dd from LVs, you could extract every needed 
> snapshots files and rebuild your VM outside of oVirt.
> Then take time to re-import it later and safely.
>

-- 
Nathanaël Blanchet

Supervision réseau
Pôle Infrastrutures Informatiques
227 avenue Professeur-Jean-Louis-Viala
34193 MONTPELLIER CEDEX 5 	
Tél. 33 (0)4 67 54 84 55
Fax  33 (0)4 67 54 84 14
blanchet at abes.fr

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20171207/8f432ca1/attachment.html>