Summarise what I discussed with Lars yesterday about this bug:
(1) If libguestfs hangs because of nested KVM, then it likely indicates your guest is going to hang too, so libguestfs is just being the canary in the mine here. However:
(2) Some users select libvirt_type=qemu to use software emulation when they know nested KVM is broken.
Libguestfs doesn't honor setting (2), but it certainly should, and it's easy to achieve that. After creating the handle but before calling g.launch(), you need to add the following bit of code:
if // some test here that libvirt_type=qemu:
try: g.set_backend_settings ("force_tcg")
except AttributeError:
# g.set_backend_settings method doesn't exist, ignore
pass
----
Note for RHOS: If you want g.set_backend_settings to be backported, you need to open a bug in https://bugzilla.redhat.com
Summarise what I discussed with Lars yesterday about this bug:
(1) If libguestfs hangs because of nested KVM, then it likely indicates your guest is going to hang too, so libguestfs is just being the canary in the mine here. However:
(2) Some users select libvirt_type=qemu to use software emulation when they know nested KVM is broken.
Libguestfs doesn't honor setting (2), but it certainly should, and it's easy to achieve that. After creating the handle but before calling g.launch(), you need to add the following bit of code:
if // some test here that libvirt_type=qemu:
g. set_backend_ settings ("force_tcg") settings method doesn't exist, ignore
try:
except AttributeError:
# g.set_backend_
pass
----
Note for RHOS: If you want g.set_backend_ settings to be backported, you need to open a bug in https:/ /bugzilla. redhat. com