[libvirt] RFC: remove qemu commandline parsing?

Ján Tomko jtomko at redhat.com
Tue Apr 9 07:58:59 UTC 2019


On Mon, Apr 08, 2019 at 06:16:03PM -0400, Cole Robinson wrote:
>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.
>

ACK to deleting useless code. Proposing deleting this was on my TODO
list, but first I wanted to try just how useless the parser is - IIRC
it cannot even parse a QMP monitor connection, so the only reasonable
working operations might be dumpxml and destroy.

>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

Agreed, regardless of the buzzwords hereafter

>considering we are trying to
>make libvirtd more modular and have a smaller footprint to facilitate
>usecases like kubevirt
>
>Thoughts?
>

Jano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20190409/5968596a/attachment-0001.sig>


More information about the libvir-list mailing list