#245 handle libvirt change to disallow shared disk access
Closed: Fixed 7 years ago Opened 7 years ago by tflink.

We've been seeing errors in dev for some time now and now the errors are starting to show up in stg. These errors are of the form:

Converting /var/lib/diskimages/PROCESSING-171219_0000-fedora-26-taskotron_cloud-x86_64.img to qcow2
Traceback (most recent call last):
  File "/var/lib/fedoraqa/base_images/process_for_taskotron.py", line 190, in <module>
    create_repofiles(image, filename)
  File "/var/lib/fedoraqa/base_images/process_for_taskotron.py", line 136, in create_repofiles
    gfs.launch()
  File "/usr/lib64/python2.7/site-packages/guestfs.py", line 5840, in launch
    r = libguestfsmod.launch(self._o)
RuntimeError: could not create appliance through libvirt.

Try running qemu directly without libvirt using this environment variable:
export LIBGUESTFS_BACKEND=direct

Original error from libvirt: unsupported configuration: shared access for disk 'sdb' requires use of supported storage format [code=67 int1=-1]

This seems to stem from a recent libvirt change which is a fix for this rhbz.

It seems to show up in 2 places:
1. testcloud at startup
2. when converting raw images from imagefactory into qcow2

Figure out how to mitigate the issues shown by the libvirt change.


setting LIBGUESTFS_BACKEND=direct when downloading images from imagefatory seems to work but I've only tried this once

downgrading libvirt also seems to work for imagefactory stuff. will try in dev

downgrading libvirt on qa11 in dev seems to have fixed the problem we were seeing. Now the question becomes how to fix the issue in a non-temporary mannor

after updating, the issue seems to have gone away on qa11. I suspect that it was the libguestfs update that landed in F27.

Either way, will keep an eye on this to see if it's really gone or not.

No problems since then, closing.

Metadata Update from @kparal:
- Issue close_status updated to: Fixed

7 years ago

Log in to comment on this ticket.

Metadata