[ovirt-users]Re: qcow on LVM‽ Why‽

Hi all, calmer now, sorry for the initial mail, but I was under some pressure. Strahil Nikolov dixit: No, not at all. The thing I really needed to do is to prepare a VM on an oVirt system then export it as qcow2 file for uploading to a “cloud” hoster. We originally created the hard disc larger than it turned out was permitted by the cloud hoster so I had to shrink it. I’m very experienced with emulation and virtualisation, and for regular management, this approach is correct; I have done so with no problems for years, on a libvirt/virt-manager environment, with various storages. Gianluca Cecchi dixit: But when I have LVM, I reserve an LV with enough space for the virtual HDD, and that will reserve the space entirely ahead of use. Thin provisioning makes zero sense on LVM, and “raw” is massively faster and less overhead, so it is the natural format to use with LVs as backing store. Huh? No. The setup is pretty standard: - hardware server with several physical HDDs - then either * RAID over those HDDs, and the RAID device is the (only) PV * one partition on each of these HDDs is a PV - one volume group - in which one LV per virtual HDD (that is, one or more per VM) Everything else happens inside the VM. A standard VM would get one LV assigned as its only virtual HDD (IDE, SCSI or VirtIO) and then have a partition table on that and guest partitions inside, such as /boot, / and swap on Linux or boot and C: on Windows. Trivial if the LV uses the raw format for the guest HDD. (OK, trivial for me, who has been known to use a hex editor to partition a HDD when no fdisk is near, and who has written his own boot managers.) Yes, but this didn’t happen here (guest was Windows anyway), and you can do that as long as the VG names differ. (You’ll want to NOT have os-prober installed on the host, though.) No LVM was used in the guest. Interesting, because that doesn’t appear what has happened here. I did not initially create the VM, so I cannot know 100%, but the size of the LV was precisely a little more than the size of the guest HDD, and qemu-img info reports that the LV contains a qcow2 in “preallocated” mode. (Incidentally, I was unable to replicate that: when using qemu-img to convert *to* qcow2 and telling it to use an LV as destination, it refuses to preallocate because it’s a special device, not a regular file, hence my surprise at how oVirt even did it.) Nir Soffer dixit: Yes, I know — but only because I was expecting the LV to contain the guest HDD in “raw” format, because that’s literally the only thing that makes sense for LVs. As I said above, I know what I’m doing and have done this in various environments over the years without any problems, it’s that oVirt did not meet common industry expectations which caused this. No, I would not have needed to shrink the LV at all in the first place, I would have needed to use qemu-img resize --shrink. Because my next step was qemu-img convert -p -c /dev/… foo.qcow, the size of the LV did not matter, only the size of the guest image; for “raw” format that *is* the size of the LV (or file, if one does that), for qcow2 it isn’t. There’s qemu-nbd which can “mount” a qcow image, by the way, is something I found out later, mentioning here in case someone else needs it and for the list archives. Incidentally I haven’t, because I was “thrown” onto oVirt, and I was extrapolating from preexisting libvirt knowledge and industry standards. I haven’t had enough time to get to know oVirt enough (and must confess I like it bad enough to not do that if I have the choice, it’s very over-complicated, graphical, slow and complex). That cannot happen because for that someone would have needed to create a new or resize an LV on that VG in the meantime, which, thankfully, nobody could have done… because I was the only one working on that system at that time. On a more busy system, yes, that would’ve been a problem (and have cost tons more time to fix up, which, perhaps, explains my unhappiness). That wasn’t what I tried… only to make the disc “not corrupted”, and “qemu-img check” ran into errors, so I’ve copied back the conversion target. Does that mean oVirt _can_ handle raw guest discs? Ah okay. Will do if/when I’m curious enough, thanks. But not on LVM? Whyever? As I said, I didn’t initially create it, but the LV was certainly created in guest size plus qcow2 overhead, and the qcow2 itself had the “preallocated” attribute. Looking at the lvcreate manpage thin LVs exist, but they need a thin pool and while “lvs” says there exist thin volumes on this host… LV VG Attr LSize Pool Origin pool00 onn twi-aotz-- 3.53t root onn Vri---tz-k <3.51t pool00 […] … the VMs are not on it, and not thin: […] 26e50a25-a91b-498b-9d1b-52552e03c935 8e3e2c99-b806-452c-bfb7-1542ebabade4 -wi-ao---- 500.00g 5e3d9fca-02ac-4d69-9f1b-dde499097e40 8e3e2c99-b806-452c-bfb7-1542ebabade4 -wi------- 160.00g […] bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ********** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **********