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/