[libvirt] [RFC 0/7] Warn at runtime when deprecated features are used
Daniel P. Berrangé
berrange at redhat.com
Fri Oct 12 15:21:19 UTC 2018
On Wed, Oct 10, 2018 at 01:09:50PM +0200, Andrea Bolognani wrote:
> Pavel helpfully pointed out that such a client already exists:
> it's called virt-xml and it's part of virt-manager.
>
> It needs a few tweaks before it can really fit the bill, but once
> that's been taken care of you should be able to use something like
>
> $ virt-xml \
> myguest \
> --os-variant fedora28 \
> --add-device \
> --network network=default
>
> and get a virtio-net device, as you should, instead of rtl8139.
>
> Actually accepting --os-variant is the missing bit, but it should
> be fairly easy to do; not only that, but the existing proposal to
> store libosinfo metadata in the guest XML during installation has
> the potential to make even that entirely unnecessary!
>
> For installation you'll obviously want to use virt-install, but
> that's the case already since actually installing a guest from
> scratch using 'virsh define' is just madness :) IIUC the use case
> of importing an existing guest image without booting the guest at
> the same time is not covered, but once again that's only a bugfix
> away.
>
> So once we have these changes in place, command line users can be
> pretty much completely isolated from libvirt defaults, just like
> virt-manager and oVirt and Nova users. Then it will be up to us
> to actually advertise these alternatives and push users away from
> virsh[1] and towards them.
>
> I wonder if showing a message suggesting to use virt-xml instead
> when 'virsh edit' or 'virsh attach-device' are called would be
> considered acceptable at that point?
Depends what you mean by showing a message ? I'd be fine with the
virsh man page referring people to virt-xml as a companion tool.
I would certainly not expect invokation of 'virsh edit' to print
any text on the console, as it will always be valid to want to
use "virsh edit", "virsh atach-device" or any other command
precisely because they are an almost direct passthrough to the
libvirt API without trying to inject clever logic of their own.
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 :|
More information about the libvir-list
mailing list