Hi Mike,
Mike Belopuhov wrote on Fri, Jul 21, 2017 at 03:14:08PM +0200:
> Together with Maxim Khitrov we have figured out what needs to
> be set for XenServer
If XenServer were free software, i would say that the OpenBSD
operating system should detect whether it is running under
XenServer and then do all this automatically, by default, but ...
> (that's a Citrix product based on Xen) to "recognize"
> the OpenBSD VM and let it do things like reboot and so on.
... that sounds like XenServer is a commercial product, so maybe
we don't want to bloat OpenBSD with specific code targeting it,
certainly not with large amounts of code. If it can automatically
be done in just a handful of lines of code, i don't feel strongly
either way, even if XenServer is commercial. I mean, other
virtual machine hosts are completely commercial in the first
place (unlike Xen) and we have large amounts of code in the kernel
specifically targeting them (unless i misunderstand).
> I'd like to get this documented in the xen(4) man page instead
> of referring users to mailing list archives.
Sure, if you decide to not do this automatically by default,
then documenting it in a manual page is a good idea, and xen(4)
seems like the logical place to me - FWTW, i know nothing about Xen,
pvbus(4), or hostctl(8).
> Index: xen.4
> ===================================================================
> RCS file: /home/cvs/src/share/man/man4/xen.4,v
> retrieving revision 1.1
> diff -u -p -r1.1 xen.4
> --- xen.4 9 Dec 2015 00:26:39 -0000 1.1
> +++ xen.4 21 Jul 2017 13:00:52 -0000
> @@ -28,6 +28,51 @@ driver performs HVM domU guest initializ
> virtual Xen interrupts, access to the XenStore configuration storage as
> well as a device probing facility for paravirtualized devices such as
> disk and network interfaces.
> +.Sh CAVEATS
I don't object to putting this into CAVEATS because XenServer does
seem to be going out of its way in order to set up plenty of traps
for the user. On the other hand, putting it at the end of DESCRIPTION
would seem even more logical to me, because it is just a description
of how to use XenServer. If DESCRIPTION seems too prominent to you
for a blurb about one specific commercial product, EXAMPLES would
also seem more logical to me than CAVEATS - anyway, your call.
If you decide to use CAVEATS, it has to go at the very end,
after AUTHORS. EXAMPLES would have to go between DESCRIPTION
and SEE ALSO.
> +When running under XenServer, it's useful to let it know that the guest
> +has finished initializing by setting a few XenStore properties with
> +.Xr hostctl 8
> +in the
> +.Pa /etc/rc.local
Make that line
.Xr rc.local 8
> +script.
> +.Bd -literal -offset indent
> +ostype=$(sysctl -n kern.ostype)
> +osrelease=$(sysctl -n kern.osrelease)
> +osbuild=$(sysctl -n kern.osversion)
> +osvermaj=${osrelease%\.*}
> +osvermin=${osrelease#*\.}
> +
> +# PV driver version
> +hostctl attr/PVAddons/MajorVersion $osvermaj
> +hostctl attr/PVAddons/MinorVersion $osvermin
> +hostctl attr/PVAddons/MicroVersion 0
> +hostctl attr/PVAddons/BuildVersion $osbuild
> +hostctl attr/PVAddons/Installed 1
> +
> +# OS version
> +hostctl data/os_name "$ostype $osrelease"
> +hostctl data/os_uname $osrelease
> +hostctl data/os_distro $ostype
> +
> +# Update XenStore
> +hostctl data/updated 1
> +.Ed
> +.Pp
> +Please note, that XenStore is capable of advertising a Hyper-V compatibility
No comma needed here.
> +layer called
> +.Dq Viridian
> +that may require an additional
> +.Xr pvbus 4
> +device node to be crated in
> +.Pa /dev
> +with
> +.Xr MAKEDEV 8
> +and all aforementioned invocations of
> +.Xr hostctl 8
> +to be amended with an
> +.Fl f Ar /dev/pvbus1
Make that line
.Fl f Pa /dev/pvbus1
> +command line option.
> +Viridian can also be disabled in the virtual machine configuration.
Maybe
Alternatively, Viridian can be disabled in the virtual machine
configuration.
because doing both ("also") does not seem to make much sense to me,
but of course i'm not sure.
Yours,
Ingo
