9:59 p.m.
Recently I got a disk snapshot marked as illegal in an VM due to a failed live merge
I fixed the snapshot manually with qemu-img rebase, now qemu-img check shows everything
OK
I also set the imagestatus to OK in the engine database, as shown below
engine=# select
image_guid,parentid,imagestatus,vm_snapshot_id,volume_type,volume_format,active from
images where image_group_id='c35ccdc5-a256-4460-8dd2-9e639b8430e9';
image_guid | parentid | imagestatus
| vm_snapshot_id | volume_type
| volume_format | active
--------------------------------------+--------------------------------------+-------------+--------------------------------------+-------------
+---------------+--------
07729f62-2cd2-45d0-993a-ec8d7fbb6ee0 | 00000000-0000-0000-0000-000000000000 | 1
| 7ae58a5b-eacf-4f6b-a06f-bda1d85170b5 | 1
| 5 | f
ee733323-308a-40c8-95d4-b33ca6307362 | 07729f62-2cd2-45d0-993a-ec8d7fbb6ee0 | 1
| 2ae07078-cc48-4e20-a249-52d3f44082b4 | 2
| 4 | t
But when I try to boot the VM it still fails with this error in the SPM
Thread-292345::ERROR::2017-07-06
14:20:33,155::task::866::Storage.TaskManager.Task::(_setError)
Task=`2d262a05-5a03-4ff9-8347-eaa22b6e143c`::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 3227, in prepareImage
raise se.prepareIllegalVolumeError(volUUID)
prepareIllegalVolumeError: Cannot prepare illegal volume:
('ee733323-308a-40c8-95d4-b33ca6307362',)
Thread-292345::DEBUG::2017-07-06 14:20:33,156::task::885::Storage.TaskManager.Task::(_run)
Task=`2d262a05-5a03-4ff9-8347-eaa22b6e143c`::Task._run:
2d262a05-5a03-4ff9-8347-eaa22b6e143c (u'146dca57-05fd-4b3f-af8d-b253a7ca6f6e',
u'00000001-0001-0001-0001-00000000014d',
u'c35ccdc5-a256-4460-8dd2-9e639b8430e9',
u'ee733323-308a-40c8-95d4-b33ca6307362') {} failed - stopping task
Just before that error I see this operation in the log:
/usr/bin/taskset --cpu-list 0-23 /usr/bin/dd iflag=direct skip=11 bs=512
if=/dev/146dca57-05fd-4b3f-af8d-b253a7ca6f6e/metadata count=1
If I run it manually I get this:
[root@blade6 ~]# /usr/bin/taskset --cpu-list 0-23 /usr/bin/dd iflag=direct skip=11 bs=512
if=/dev/146dca57-05fd-4b3f-af8d-b253a7ca6f6e/metadata count=1
DOMAIN=146dca57-05fd-4b3f-af8d-b253a7ca6f6e
VOLTYPE=LEAF
CTIME=1497399380
FORMAT=COW
IMAGE=c35ccdc5-a256-4460-8dd2-9e639b8430e9
DISKTYPE=2
PUUID=07729f62-2cd2-45d0-993a-ec8d7fbb6ee0
LEGALITY=ILLEGAL
MTIME=0
POOL_UUID=
SIZE=209715200
TYPE=SPARSE
DESCRIPTION=
EOF
So I guess the volume info is cached in the storage domain's metadata LV, and it's
still in ILLEGAL status there
Is there a way to force ovirt to update the information in the metadata LV?
Of course I've thought of updating manually with dd, with it seems too risky (and
scary) to do it in production
Salu2!
--
Miguel Armas
CanaryTek Consultoria y Sistemas SL
http://www.canarytek.com/