[ovirt-users]Re: qcow on LVM‽ Why‽
On Wed, Mar 4, 2020 at 6:13 PM Thorsten Glaser <t.glaser(a)tarent.de> wrote:
...
I was shrinking a hard disc: first the filesystems inside the VM,
then the partitions inside the VM, then the LV
This is the point where you probably corrupted your image.
oVirt does not support shrinking existing disks. If you want to do this
you must know what you are doing.
… then I wanted to
convert the LV to a compressed qcow2 file for transport, and it
told me that the source is corrupted. Huh?
You corrupted it by shrinking the LV without checking the end of the image.
Next time try:
$ qemu-img check /dev/vg/lv
...
Image end offset: 123456789
You must not shrink the LV less than Image end offset.
I had already wondered why I was unable to inspect the LV on the
host the usual way (kpartx -v -a /dev/VG/LV after finding out,
with “virsh --readonly -c qemu:///system domblklist VM_NAME”,
which LV is the right one).
Turns out that ovirt stores qcow on LVs instead of raw images ☹
I think this this is documented. Did you read storage admin guide before
playing with the underlying logical volumes?
Well, vgcfgrestore to my rescue:
- vgcfgrestore -l VG_NAME
- vgcfgrestore -f /etc/… VG_NAME
This may be too late if another disk is using segments you removed from the
original lv, but seems that you were lucky this time.
The image was still marked as corrupted, but exported fine. I
could not write it back to the LV as preallocated,
You cannot change image format for existing disk. But you can delete
the VM disk,
upload the modified disk (e.g. via the UI or SDK) and attach the disk to the VM.
Or you can create a new empty preallocated disk, copy the image
directly to the disk
using qemu-img, and then attach the disk to the VM.
which seems
to be what ovirt does, because qemu-img doesn’t wish to do that
when the target is a special device (not a regular file). Meh.
qemu-img convert works with block devices. You can enable DEBUG log
level in vdsm to check how vdsm run qemu-img.
Does ovirt handle raw images on LV, and if so, how can we enable
this for new VMs? If not, whyever the hell not? And whose “great”
idea was this anyway?
oVirt supports raw format of course, and this is the default format
for disks on iSCSI/FC
storage domain.
You probably chose "thin" when you created the disk. This means qcow2 format.
Nir