Re: [Qemu-devel] [PATCH v6 2/2] mach-virt: Provide sample configuration files

[Andrea Bolognani <abologna@redhat.com>]

On Fri, 2017-02-10 at 12:43 +0100, Laszlo Ersek wrote:
> So, what speaks against adding "-serial mon:stdio" here too? Even with a
> graphical guest, the monitor is useful. And, if you care about firmware
> logs (who doesn't? ;)), seeing serial output is good. (Same applies to
> the guest kernel -- sooner or later everyone enables serial output for
> grub2 and kernel, for reporting bugs.)
> 
> Just my two cents, you're welcome to disagree.

The sample configurations are opinionated, that's why there
are both a graphical and a serial variant and not a single
configuration with everything but the kitchen sink. Users
are of course more than welcome to mix and match :)

> > +# We create eight PCI Express Root Ports, and we plug them
> > +# all into separate functions of the same slot. Some of
> > +# them will be used by devices, the rest will remain
> > +# available for hotplug.
> > +
> > +[device "pci.1"]
> 
> I suggest to call these devices "pcie.x" (and update the references).

Makes sense. I followed libvirt's naming here, but there
is no reason not to highlight the fact that these
controllers are, indeed, PCI Express rather than legacy
PCI.

[...]
> A number of suggestions. If you think they are beyond the scope of these
> examples, or plain disagree, that's fine. :)
> 
> * please add a CD-ROM too (scsi-cd), and point its drive to some
> installer ISO. (remember # CHANGE ME for the pathname)
> 
> * please spell out the "bootindex" property for both the disk and the
> CD-ROM device. If you set booindex=1 for the disk and bootindex=2 for
> the CD-ROM, then that configuration is permanently suitable for first
> installing the guest from the ISO, then booting it all subsequent times
> from the disk. ArmVirtQemu is king like that! ;)

So it does! And the same trick works for SeaBIOS as well,
I just tested with the q35 sample configurations :)

I'll include this.

> * I'm a *huge* fan of saving disk space on the host. So, thin
> provisioning FTW! Virtio-scsi is definitely a step in the right
> direction, but for the disk drive, please add these wo properties:
> 
>   discard = "unmap"
>   werror = "enospc"
> 
> The first property will release host filesystem blocks when the guest
> runs "fstrim". The second option lets you over-provision the host
> filesystem, and if a guest runs out of room mid-flight, it will be
> paused. You can free up more disk space and unpause the guest then.
> 
> (There's also "detect-zeroes", but I've never tried that. I very vaguely
> recall reading bad things about its CPU demand. I could be wrong, but I
> certainly don't feel comfortable enough to actively recommend it.)

I think such tweaks, while definitely useful, fall beyond
the scope of these sample configuration files.

[...]
> > +# If you're running the guest on a remote, potentially
> > +# headless host, you will probably want to append something
> > +# like
> > +#
> > +#   -display vnc=127.0.0.1:0
> > +#
> > +# to the command line in order to prevent QEMU from trying
> > +# to display a GTK+ window on the host and enable remote
> > +# access instead.
> 
> Haha, someone prefers GTK+ to SDL? :) Last time I checked the GTK+
> window, it was painful. (It was a very long time ago.)
> 
> Maybe that's to blame on GTK+ *in RHEL-7* specifically, I'm uncertain.
> But, I digress; no need to do anything about this.

GTK+ just seems to be the default display mode, so no
preference of my own really - although I have no problem
admitting that I'm a massive GNOME fan ;)

Calling out GTK+ explicitly here does not serve any purpose,
though, so I'll change it to a more neutral wording.

-- 
Andrea Bolognani / Red Hat / Virtualization