Bug 1654763

Thanks for the report. This VM was booting correctly in the past, I take it?
Please provide the VM XML: sudo virsh dumpxml $vmname

(In reply to Cole Robinson from comment #1)
> Thanks for the report. This VM was booting correctly in the past, I take it?

Right, it worked with Fedora 28. After upgrade to Fedora 29 this VM shows above error, other VMs are still working fine.

> Please provide the VM XML: sudo virsh dumpxml $vmname

Attaching

Created attachment 1513616 [details]
VM xml dump

Not sure if it may be useful but the qcow file is seen like:

$ sudo file host.qcow2 
host.qcow2: QEMU QCOW2 Image (v3), has backing file (path /home/sbonazzo/NotBackedUp/VMs/), 64424509440 bytes

while other qcow images in same directory are different:
$ sudo file centos7.0.qcow2
centos7.0.qcow2: QEMU QCOW2 Image (v3), 21474836480 bytes

No idea what caused the difference, I don't remember having done something special on this VM.

Is that definitely the offending VM? The libvirt error doesn't match the guest config, though maybe that's the root issue.
Does 'sudo virsh start $vmname' fail similarly?

I'm guessing you are using the virt-preview repo since you have libvirt 4.9.0 on F29, while the stable version there is 4.7.0. virt-preview has libvirt 4.10.0 now, does that fix anything after install + libvirtd restart?

(In reply to Cole Robinson from comment #5)
> Is that definitely the offending VM?

Yes

> The libvirt error doesn't match the
> guest config, though maybe that's the root issue.
> Does 'sudo virsh start $vmname' fail similarly?

Yes:
sudo virsh start host.home
error: Failed to start domain host.home
error: unsupported configuration: storage type 'dir' requires use of storage format 'fat'


> I'm guessing you are using the virt-preview repo since you have libvirt
> 4.9.0 on F29, while the stable version there is 4.7.0. virt-preview has
> libvirt 4.10.0 now, does that fix anything after install + libvirtd restart?

I'm using virt preview. Upraded to libvirt 4.10.0-2.fc29.x86_64, qemu 3.1.0-1.fc29.x86_64
Rebooted and tested again, still failing with same messages.

Hmm now that I look at your qcow2 output, the backing file of your disk image seems to be a directory: /home/sbonazzo/NotBackedUp/VMs/

I don't think that's ever been a valid config and maybe libvirt just started explicitly erroring over it. Maybe check /var/log/libvirt/qemu/host_home.log and see if previous qemu was throwing errors, maybe it warned about it silently.

I think you can correct this issue by doing:

  qemu-img rebase -b "" $IMAGENAME

Which basically says: rebase and remove the backing file from $IMAGENAME. Create a back up first!

(In reply to Cole Robinson from comment #8)
> Hmm now that I look at your qcow2 output, the backing file of your disk
> image seems to be a directory: /home/sbonazzo/NotBackedUp/VMs/
> 
> I don't think that's ever been a valid config and maybe libvirt just started
> explicitly erroring over it. Maybe check /var/log/libvirt/qemu/host_home.log
> and see if previous qemu was throwing errors, maybe it warned about it
> silently.

No warning or errors about this in /var/log/libvirt/qemu/host_home.log*.
Looks like issue has been ignored silently.

> 
> I think you can correct this issue by doing:
> 
>   qemu-img rebase -b "" $IMAGENAME
> 
> Which basically says: rebase and remove the backing file from $IMAGENAME.
> Create a back up first!

# qemu-img rebase -b "" host.qcow2 
qemu-img: Could not open 'host.qcow2': Could not open backing file: A regular file was expected by the 'file' driver, but something else was given

(In reply to Sandro Bonazzola from comment #9)
> 
> # qemu-img rebase -b "" host.qcow2 
> qemu-img: Could not open 'host.qcow2': Could not open backing file: A
> regular file was expected by the 'file' driver, but something else was given

Okay seems like qemu-img is choking on the directory as well... not really sure how that image got into this state or ever worked correctly. Maybe try qemu-img convert? Or turn /home/sbonazzo/NotBackedUp/VMs into a regular file and then try the rebase command. Not really sure what to do here or if any of them will corrupt the image...

(In reply to Cole Robinson from comment #10)
> (In reply to Sandro Bonazzola from comment #9)
> > 
> > # qemu-img rebase -b "" host.qcow2 
> > qemu-img: Could not open 'host.qcow2': Could not open backing file: A
> > regular file was expected by the 'file' driver, but something else was given
> 
> Okay seems like qemu-img is choking on the directory as well... not really
> sure how that image got into this state or ever worked correctly. Maybe try
> qemu-img convert? Or turn /home/sbonazzo/NotBackedUp/VMs into a regular file
> and then try the rebase command. Not really sure what to do here or if any
> of them will corrupt the image...

The content of the VM is not really relevant to me, I can just destroy the image and re-create.
I reported the bug because I guess it may happen elsewhere with more relevant content within the image.
Tried what you suggested:
- qemu-img convert fails as well on the 'file' driver.
- changing the path to a regular file ended up with: qemu-img rebase -b "" host.qcow2 
qemu-img: Could not open 'host.qcow2': Could not open backing file: Could not open '/home/sbonazzo/NotBackedUp/VMs/': Not a directory

Looks like you can use the -u option to rebase to fix this, I just tested.
Also 'qemu-img create' will let you point to a busted backing file path, it warns about it and says it will be disallowed in future versions but I guess we aren't there yet.

Either way it seems like qemu is moving in the direction of trying to clean up this situation, hopefully future versions prevent using incorrect backing images

Confirming that: qemu-img rebase -u -b "" host.qcow2
solved the issue for my system.

Thanks for this tip - I have started seeing this in newly created VMs with virt-manager in Fedora 31.  Would love to see a feature request for button/option to resolve this put in virt-manager.