[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