On Wed, Mar 4, 2020 at 6:13 PM Thorsten Glaser <t.gla...@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 _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/BDHVWXG4EZAFYLBPEZFUE5ZDYUHS5G3K/