Bug 865021 - vdsm: after move of disk with snapshot in preview cannot run the vm
vdsm: after move of disk with snapshot in preview cannot run the vm
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
x86_64 Linux
high Severity high
: ---
: 3.2.0
Assigned To: Federico Simoncelli
Dafna Ron
: ZStream
Depends On:
Blocks: 905499
  Show dependency treegraph
Reported: 2012-10-10 12:10 EDT by Dafna Ron
Modified: 2016-02-10 14:55 EST (History)
15 users (show)

See Also:
Fixed In Version: SF6
Doc Type: Release Note
Doc Text:
Previously, it was possible to move a virtual machine disk with a snapshot in preview mode, which caused a vdsm error, so the virtual machine could not run until the preview was reverted. An additional validation has been added to MoveDisksCommand to prevent such action.
Story Points: ---
Clone Of:
: 905499 (view as bug list)
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: Storage
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
logs (2.07 MB, application/x-gzip)
2012-10-10 12:10 EDT, Dafna Ron
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 11340 None None None Never

  None (edit)
Description Dafna Ron 2012-10-10 12:10:44 EDT
Created attachment 624986 [details]

Description of problem:

I moved a vm that had a snapshot in preview and after the move I got an error from vdsm:

Thread-7607::ERROR::2012-10-10 17:39:33,151::dispatcher::66::Storage.Dispatcher.Protect::(run) {'status': {'message': "Logical volume does not exist: ('dbed4cf3-a177-49a8-b41c-f12b85db4286/9e5c23c1-7d8f-4f30-904a-33b2824debf4',)", 'code
': 610}}
Thread-7607::DEBUG::2012-10-10 17:39:33,152::vm::589::vm.Vm::(_startUnderlyingVm) vmId=`95011428-d57a-49b1-b5cb-7d17d4d7737b`::_ongoingCreations released
Thread-7607::ERROR::2012-10-10 17:39:33,152::vm::613::vm.Vm::(_startUnderlyingVm) vmId=`95011428-d57a-49b1-b5cb-7d17d4d7737b`::The vm start process failed
Traceback (most recent call last):
  File "/usr/share/vdsm/vm.py", line 579, in _startUnderlyingVm
  File "/usr/share/vdsm/libvirtvm.py", line 1317, in _run
    devices = self.buildConfDevices()
  File "/usr/share/vdsm/vm.py", line 436, in buildConfDevices
  File "/usr/share/vdsm/vm.py", line 363, in _normalizeVdsmImg
    drv['truesize'] = res['truesize']
KeyError: 'truesize'
Thread-7607::DEBUG::2012-10-10 17:39:33,159::vm::929::vm.Vm::(setDownStatus) vmId=`95011428-d57a-49b1-b5cb-7d17d4d7737b`::Changed state to Down: 'truesize'

putting bug on medium since I was able to undo image and preview again and than run the vm. 

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. create a vm with snapshot
2. put snapshot in preview
3. move disk
4. run vm
Actual results:

vm fails to run with truesize error since it cannot find image

Expected results:

we should be able to run the vm

Additional info: logs
Comment 1 Federico Simoncelli 2013-01-22 07:14:06 EST
moveImage is not designed to move image trees. I've been able to reproduce the issue moving image d2d03a74-654e-4ceb-8043-40e6dc005bde (with a snapshot preview e70d48e9-cfeb-4da6-a9bc-512b9cc0bd53) from domain 02843c9b-acbd-4576-a4da-1461b90232be to domain ef67a16a-cb59-485f-a4c7-d27b006befe2.

# lvs -o name,vg_name,tags
  LV                                   VG                                   LV Tags
  61666f2b-abeb-4c79-8acd-6e065c07be3c 02843c9b-acbd-4576-a4da-1461b90232be PU_9d480ea8-77f6-4501-a2e2-0ecbaa0432f6,IU_d2d03a74-654e-4ceb-8043-40e6dc005bde,MD_5
  8de19a41-6fdb-4aae-8d78-c13a1333b47c 02843c9b-acbd-4576-a4da-1461b90232be MD_6,PU_61666f2b-abeb-4c79-8acd-6e065c07be3c,IU_d2d03a74-654e-4ceb-8043-40e6dc005bde
  9d480ea8-77f6-4501-a2e2-0ecbaa0432f6 02843c9b-acbd-4576-a4da-1461b90232be MD_4,PU_00000000-0000-0000-0000-000000000000,IU_d2d03a74-654e-4ceb-8043-40e6dc005bde
  e70d48e9-cfeb-4da6-a9bc-512b9cc0bd53 02843c9b-acbd-4576-a4da-1461b90232be MD_7,IU_d2d03a74-654e-4ceb-8043-40e6dc005bde,PU_9d480ea8-77f6-4501-a2e2-0ecbaa0432f6

As we can see, only the regular image (no preview) has been moved to a different domain:

# lvs -o name,vg_name,tags
  LV                                   VG                                   LV Tags
  61666f2b-abeb-4c79-8acd-6e065c07be3c ef67a16a-cb59-485f-a4c7-d27b006befe2 PU_9d480ea8-77f6-4501-a2e2-0ecbaa0432f6,IU_d2d03a74-654e-4ceb-8043-40e6dc005bde,MD_5
  8de19a41-6fdb-4aae-8d78-c13a1333b47c ef67a16a-cb59-485f-a4c7-d27b006befe2 MD_6,PU_61666f2b-abeb-4c79-8acd-6e065c07be3c,IU_d2d03a74-654e-4ceb-8043-40e6dc005bde
  9d480ea8-77f6-4501-a2e2-0ecbaa0432f6 ef67a16a-cb59-485f-a4c7-d27b006befe2 MD_4,PU_00000000-0000-0000-0000-000000000000,IU_d2d03a74-654e-4ceb-8043-40e6dc005bde

I can also see the log error reported in the description:

Thread-1596::ERROR::2013-01-22 06:04:52,801::vm::716::vm.Vm::(_startUnderlyingVm) vmId=`44deeef5-848f-47a2-ad08-b96ed9f39c1c`::The vm start process failed
Traceback (most recent call last):
  File "/usr/share/vdsm/vm.py", line 678, in _startUnderlyingVm
  File "/usr/share/vdsm/libvirtvm.py", line 1462, in _run
    devices = self.buildConfDevices()
  File "/usr/share/vdsm/vm.py", line 515, in buildConfDevices
  File "/usr/share/vdsm/vm.py", line 408, in _normalizeVdsmImg
    drv['truesize'] = res['truesize']
KeyError: 'truesize'

But the most interesting thing is the preceding error (the preview volume is missing):

Thread-1596::ERROR::2013-01-22 06:04:52,731::task::833::TaskManager.Task::(_setError) Task=`c1d97d0e-56cd-40db-8f9e-b169bed59af8`::Unexpected error
Traceback (most recent call last):
  File "/usr/share/vdsm/storage/task.py", line 840, in _run
    return fn(*args, **kargs)
  File "/usr/share/vdsm/logUtils.py", line 42, in wrapper
    res = f(*args, **kwargs)
  File "/usr/share/vdsm/storage/hsm.py", line 2879, in getVolumeSize
    volUUID, bs=1))
  File "/usr/share/vdsm/storage/volume.py", line 322, in getVSize
    return mysd.getVolumeClass().getVSize(mysd, imgUUID, volUUID, bs)
  File "/usr/share/vdsm/storage/blockVolume.py", line 106, in getVSize
    return int(int(lvm.getLV(sdobj.sdUUID, volUUID).size) / bs)
  File "/usr/share/vdsm/storage/lvm.py", line 845, in getLV
    raise se.LogicalVolumeDoesNotExistError("%s/%s" % (vgName, lvName))
LogicalVolumeDoesNotExistError: Logical volume does not exist: ('ef67a16a-cb59-485f-a4c7-d27b006befe2/e70d48e9-cfeb-4da6-a9bc-512b9cc0bd53',)

We can try to modify the moveImage verb to support image trees even though it's probably out of its scope (and it might break some assumptions).
Maybe the best fix at the moment is to prevent (in the engine) the move when a preview is in place.
Comment 2 Federico Simoncelli 2013-01-23 17:35:52 EST
Author: Federico Simoncelli <fsimonce@redhat.com>
Date:   Wed Jan 23 12:40:24 2013 -0500

    core: block MoveDisks on snapshot preview
    The moveImage command in VDSM (at the moment of this writing) cannot
    move disks of VMs that are in preview mode. An additional validation
    has been added to MoveDisksCommand to prevent such action for the time

Comment 11 Leonid Natapov 2013-02-13 07:00:30 EST
sf6. fixed. can not move disk in preview mode.Getting message: Cannot move Virtual Machine disk. VM is previewing a Snapshot.
Comment 14 Itamar Heim 2013-06-11 05:48:06 EDT
3.2 has been released
Comment 15 Itamar Heim 2013-06-11 05:48:09 EDT
3.2 has been released
Comment 16 Itamar Heim 2013-06-11 05:57:06 EDT
3.2 has been released

Note You need to log in before you can comment on or make changes to this bug.