Re: RFC: remove qemu commandline parsing?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Attachment: signature.asc
Description: PGP signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux