Re: [libvirt] RFC: remove qemu commandline parsing?
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-externa...
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.
It is tricky because the old style qemu options are things that libvirt
itself doesn't use, but are still mostly supported by QEMU and actually
quite common to use for humans launching QEMU.
IOW, a viable "attach" impl really has to support both old & new options
styles despite libvirt only generating new styles. We've meanwhile been
deleting support for stuff related to old style args, so even if we can
parse old style args we will probably break. There's really no way to
support old style args for parsing, if we don't also support generating
them ourselves.
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).
This was introduced about the same time as CLI arg passthrough, and I
think most people who were launching QEMU externally who wanted to
use libvirt ended up using the CLI arg passthrough feature, thus
reducing the need to attach to running QEMU.
The interesting thing is that with my proposal for libvirt-shim we
will actually end up supporting a "qemu attach" concept for real,
but in a rather different way. We'd still be using libvirt generatd
CLI args and so wouldn't be reverse engineering the args. We'd
just be passing in XML that already represents the thing we';d be
attaching to.
Anyway, i think we can reasonably stub out the API to just raise an
error at this point.
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
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|