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. 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
