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
