On 10/28/22 19:06, Mike Larkin wrote:
On Fri, Oct 28, 2022 at 06:25:11PM +0200, Kalabic S. wrote:
In my testing, this has no effect on the operation of the clock. Only
the guest OS selected in the VM configuration does have an effect.
We should remove any suggestion that 32bit FreeBSD is the right thing
to select though, so changing the guest OS we report is still a good
idea.
Interestingly, it looks like if the guest OS is set to 'Other
(64-bit)', and vmt reports an unrecognised short guest OS name (such
as 'OpenBSD'), vcenter will display the full guest OS name, so you get >
something like 'OpenBSD 7.2 GENERIC.MP#31'.
I'm pretty sure this caused problems in the distant past, but it seems
fine now with esxi 6.7+, so I think we should change to saying we're
OpenBSD instead.
Replacing 'FreeBSD' with something ESXi doesn't support will almost
certainly have drawbacks. We can already see different 'Guest OS' options
have different effects on guest VMs.
What drawbacks? Does jmatthew@'s diff to change the name to OpenBSD fix the
problem or not? If it does, that's a more factually accurate diff. We are
not "FreeBSD 32 bit" or "FreeBSD 64 bit" and it seems that calling ourselves
"OpenBSD" doesn't cause problems anymore. So I'd like to know what "certainly
have drawbacks" means. Can you shed some light on that please?
-ml
jmatthew@'s diff to change the name to OpenBSD does not fix the problem.
Only the "Guest OS" set to "FreeBSD (64-bit)" or "Other (32-bit)" or
"Other (64-bit)" in the VM configuration does fix the clock problem.
I said it will "certainly have drawbacks" first because just changing to
64-bit FreeBSD from 32-bit fixes the clock issue. So, being ignorant and
not informed about technical details happening on ESXi I see it as even
bigger change (risk) switching to "Others" option. Only guessing here
and giving my opinion, not trying to teach people with knowledge of the
issue.
