We are trying a Fedora 24, because the qemu-img from git require a differnt version of glibc 2.12 and gthread 2.0 from that running on the hosts. In the while we fixed the problem in another way: 1) we dumped (with dd) all the snapshots and the base on files 2) then checked where the backing file becomes too long (in our case in the 2nd snapshot) with qemu-img info --backing chain <dumped snapshot filename> 3) we fixed the backing file with hexedit on that file only (be sure to correct too the lenght of the backing file read qcow2 format) 4) we checked others snapshots starting from 3rd and all were OK 5) we converted all in a qcow2 and in a raw image with qemu-img convert <latest snapshot filename> -O qcow2 <output filename in qcow2> qemu-img convert <latest snapshot filename> -O raw <output filename in raw> 6) we mounted with guestfish the qcow2 image and checked all was correct and it was 7) we did the same steps (from 1 to 6) for all the disks (base + snapshots) in the VM 8) we create a new VM in ovirt with the same structure of the old one (RAM, disks, disks size, network) 9) we started the new VM with a livecd and then dumped back (using the raw files) all the disks fixed using dd with netcat 10) we stopped and started again the new VM and all was working like we left the last working time I know our solution was longer and harder, but in this way if something was wrong we had destroyed a copy of the original datas and we had no success to compile the qemu-img from git on our hosts 4.0.4 for glibc and gthread version. Anyway we will have to check all the VMs (about 200) for snapshots and backing file too long but then we would like to fix the problem directly on the LVs snapshot (our method would require i suppose 2-3 months of work), so we need a working qemu-img patched. I will let you know if fedora 24 still give problems about the compiler and gthread version. I opened another case in the mailing list, because from when we upgraded to 4.0.4 each VM that we shutdown, never starts again with the following error "Unable to get size for domain ..." Do you think it can be related at the backing file problem ? For now thanks to all Claudio On 19/10/16 16:55, Adam Litke wrote:
On 19/10/16 14:43 +0200, Claudio Soprano wrote:
Hi Adam, we tried your solution.
This is our situation with the current VM that has 2 disks
base -> snap1 -> snap2 -> snap3 -> snap4 -> snap5 -> .. -> snap15 for each disk
We tried to do
qemu-img rebase -u -b base snap1
results OK
qemu-img rebase -u -b snap1 snap2
results:
qemu-img: Could not open 'snap2': Backing file name too long
our qemu version is
qemu-img version 2.3.0 (qemu-kvm-ev-2.3.0-31.el7.16.1), Copyright (c) 2004-2008 Fabrice Bellard
How do you think can we resolve ?
I talked with the qemu developers about this issue and the best way to fix this is by using a patched version of qemu-img that ignores invalid backing_file values when doing an unsafe rebase. Here is what you will need to do to fix your images.
1. Save the attached patch 2. Grab a copy of the latest qemu.git 3. Apply the patch to the source 4. Install qemu build dependencies 5. Build qemu 6. Run the built version of qemu-img when fixing your chain as I suggested above:
./qemu-img rebase -u -b snap1 snap2
The patch disables other qemu-img functionality since you should not be using this for anything but the rebase part. After the rebase you can use the system qemu-img binary to check the image. Please try this on one VM disk and make sure everything is okay.
-- / | / _____/ / | / _____/ | / / / | / / / / | / / / | / / / | / ___/ _____/ / / | / ___/ / | / / / | / / / / | / / / | / ______/ _/ __/ _/ _/ _/ __/ _/ _/ __/ Claudio Soprano phone: (+39)-06-9403.2349/2355 Computing Service fax: (+39)-06-9403.2649 LNF-INFN e-mail: Claudio.Soprano@lnf.infn.it Via Enrico Fermi, 40 www: http://www.lnf.infn.it/ I-00044 Frascati, Italy