[libvirt] RFC: remove qemu commandline parsing?

Cole Robinson crobinso at redhat.com
Mon Apr 8 22:16:03 UTC 2019


qemu/qemu_parse_command.c powers 'sudo virsh domxml-from-native
qemu-argv', parsing a qemu command line and attempting to turn it into
libvirt domain XML. Some history:

RFE: https://www.redhat.com/archives/libvir-list/2009-April/msg00266.html
Patches: https://www.redhat.com/archives/libvir-list/2009-May/msg00321.html
danpb blog post about related qemu-attach:
https://www.berrange.com/posts/2011/07/13/attaching-libvirt-to-an-externally-launched-kvm-instance/

At the time it was added, the parser was pretty comprehensive WRT to
what libvirt XML features were available at the time. However it's quite
hopelessly out of date these days and has been for a long time. As an
example, the only -device it knows to parse is virtio-balloon, and it
doesn't know anything about -netdev. So the parser can really only
handle typical old style qemu options.

AFAICT The original motivation for adding this and qemu-attach was
providing a more straightforward path for direct qemu users to switch to
libvirt. Googling does provide some cases of users successfully
converting very simple qemu invocations to libvirt XML. But at least
from my experience I don't think these features every really moved the
needle in this respect. If anything, it's been that managing qemu has
only grown more complex over time, which has made libvirt and tools that
use it all the more compelling over launching your own qemu command line
(for end users, think manually setting up usb2 with qemu directly).

But IMO all that is kind of beside the point. I don't think it's
debatable that the code is largely unused, and it hasn't seen many
material improvements in the last 5 years, with zero plans to improve it
on the horizon. It's 2000+ lines of text processing code living in every
libvirtd instance. Deleting it all and making the qemu_driver.c APIs
just return errors seems like an easy win considering we are trying to
make libvirtd more modular and have a smaller footprint to facilitate
usecases like kubevirt

Thoughts?

- Cole




More information about the libvir-list mailing list