virt-install: changing default --os-variant behavior

[Peter Crowther]

On Tue, 22 Sep 2020 at 16:48, Cole Robinson <crobinso at redhat.com> wrote:

> On 9/20/20 4:46 PM, Peter Crowther wrote:
> > On Sun, 20 Sep 2020 at 21:10, Cole Robinson <crobinso at redhat.com
> > <mailto:crobinso at redhat.com>> wrote:
> > [...]
> >
> >     2) Default to --os-variant detect=on,name=<virtio-something>. 'give
> me
> >     virtio' is representative of what most virt-install users want. But
> this
> >     adds some new corner cases, ex if anyone is using virt-install with
> >     windows up until now they could get away without specifying a
> >     --os-variant and things would generally work, but now if we default
> to
> >     virtio windows out of the box is not going to install. I kinda doubt
> >     many people are using virt-install with windows though.
> >
> >
> > As feedback, this is the single largest use case in the main
> > virtualisation cluster I manage.  CentOS hosts, 90% Windows 7(!) and 8.1
> > guests.  We have our virt-install scripted to add a floppy drive with
> > autoinstall file, virtio drivers, and a few other bits and pieces like a
> > minimal puppet client install (surprisingly non-trivial in Windows 7
> > gold), so we could live with such a change; but please don't assume that
> > if the hosts are Linux then the guests are also likely to be Linux.
> >
>
> But presumably you are already specifying an --os-variant though? In
> which case you would be fine even if the default changes.
>

Yes, we are.

On the principle of least surprise, I would suggest "Option 3" of your two
suggestions: virt-install warns but succeeds for such an install.  I don't
think it's unreasonable to default to slower emulated hardware rather than
virtio as long as the user gets a reasonably helpful notice that
virt-install doesn't know what else to do so has gone for a slow fail-safe.

Cheers,

- Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/virt-tools-list/attachments/20200922/182c50ac/attachment.htm>