Re: VMware Tools driver to advertise OS as 'FreeBSD 64-bit' OS, not 32-bit version
On Fri, Oct 28, 2022 at 12:26:07PM -0700, Mike Larkin wrote: > On Fri, Oct 28, 2022 at 12:30:11PM -0600, Theo de Raadt wrote: > > Kalabic S, wrote: > > > > > To be more precise, I wanted to say sticking with FreeBSD means > > > sticking with whatever behavior VMware will keep consistent and > > > support in the future. For "Others" option I don't think they care and > > > is more probable to vary. > > > > I cannot tell the difference. I think you are completely unqualified > > to know what "they will not change" fakery vmware is doing with the MSR's > > and clock related registers... it is actually possible that when they > > *know* it is one particular operating system they do something sophisticated > > to fool that one specific operating system, whereas when they don't know > > what the operating system is, they reduce the amount of trickery. > > > > You don't know. I don't know. None of us know. > > > > But can you please stop making claims you can't back. > > > > I think it's reasonable to try and claim that whatever we are, we are the > closest to "that thing". Meaning, the OP said we should claim we are FreeBSD > 64 bit or 32 bit or whatever. Fine, but let's spend some time to actually > figure out *what* we should say we are before we just pick something randomly > because "it fixed my machine". Maybe we should say we're Windows? Maybe we > should say we're Linux? My point, and I think Theo's as well, is we don't > know and just randomly taking a diff because it fixes one scenario on one > version of ESXi is shortsighted. > > So I would ask the OP to: > > - try different OS choices > - on different versions of ESX > - on different versions of VMware fusion > - on different versions of VMware workstation > - on different versions of OpenBSD VMs > - on different archs (i386/amd64) of OpenBSD VMs > > ... and then report back what the findings are. > > -ml Hi, >From what I've been told from someone in the know: * What we report in vmt(4) doesn't influence what machine is modeled, that's just for what's shown in vCenter. We should probably show something useful. I kinda liked that OpenBSD 7.2 GENEIRC.MP#31 string that jmatthew@ showed, but that's another discussion. * The guest type configured in the .vmx influences the VM model. Just assume the ESXi version has a workaround for FreeBSD to run fine on that ESXi, it could be possible that it actually degrades OpenBSD performance/stability. In general it makes more sense to opt for the Other 64-Bit guest type (for amd64). I personally sometimes use Windows 11 guest types on things like VMware Fusion or Parallels, but that's mostly because they sometimes have some funky devices and I'm doing that for testing w/ graphics. For ESXi I'd opt for Other 64-Bit. Cheers, Patrick
Re: VMware Tools driver to advertise OS as 'FreeBSD 64-bit' OS, not 32-bit version
On Fri, Oct 28, 2022 at 12:30:11PM -0600, Theo de Raadt wrote: > Kalabic S, wrote: > > > To be more precise, I wanted to say sticking with FreeBSD means > > sticking with whatever behavior VMware will keep consistent and > > support in the future. For "Others" option I don't think they care and > > is more probable to vary. > > I cannot tell the difference. I think you are completely unqualified > to know what "they will not change" fakery vmware is doing with the MSR's > and clock related registers... it is actually possible that when they > *know* it is one particular operating system they do something sophisticated > to fool that one specific operating system, whereas when they don't know > what the operating system is, they reduce the amount of trickery. > > You don't know. I don't know. None of us know. > > But can you please stop making claims you can't back. > I think it's reasonable to try and claim that whatever we are, we are the closest to "that thing". Meaning, the OP said we should claim we are FreeBSD 64 bit or 32 bit or whatever. Fine, but let's spend some time to actually figure out *what* we should say we are before we just pick something randomly because "it fixed my machine". Maybe we should say we're Windows? Maybe we should say we're Linux? My point, and I think Theo's as well, is we don't know and just randomly taking a diff because it fixes one scenario on one version of ESXi is shortsighted. So I would ask the OP to: - try different OS choices - on different versions of ESX - on different versions of VMware fusion - on different versions of VMware workstation - on different versions of OpenBSD VMs - on different archs (i386/amd64) of OpenBSD VMs ... and then report back what the findings are. -ml
Re: VMware Tools driver to advertise OS as 'FreeBSD 64-bit' OS, not 32-bit version
Kalabic S, wrote: > To be more precise, I wanted to say sticking with FreeBSD means > sticking with whatever behavior VMware will keep consistent and > support in the future. For "Others" option I don't think they care and > is more probable to vary. I cannot tell the difference. I think you are completely unqualified to know what "they will not change" fakery vmware is doing with the MSR's and clock related registers... it is actually possible that when they *know* it is one particular operating system they do something sophisticated to fool that one specific operating system, whereas when they don't know what the operating system is, they reduce the amount of trickery. You don't know. I don't know. None of us know. But can you please stop making claims you can't back.
Re: VMware Tools driver to advertise OS as 'FreeBSD 64-bit' OS, not 32-bit version
On 10/28/22 18:29, Theo de Raadt wrote: Kalabic S. wrote: Also, OpenBSD really is part of BSD family. That is such a load of crap. You have absolutely no idea what vmware is doing behind the scenes based upon that string. Obviously, it is doing stuff. But you want to say "oh family". Stop it. Yeah, me using "family" was a brain fart, no idea what is ESXi doing behind the scenes. To be more precise, I wanted to say sticking with FreeBSD means sticking with whatever behavior VMware will keep consistent and support in the future. For "Others" option I don't think they care and is more probable to vary.
Re: VMware Tools driver to advertise OS as 'FreeBSD 64-bit' OS, not 32-bit version
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.
Re: VMware Tools driver to advertise OS as 'FreeBSD 64-bit' OS, not 32-bit version
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 > > Also, OpenBSD really is part of BSD family. > > I have an OpenBSD VM running without issues as a guest with 'FreeBSD' option > for years and serving as an Internet router for home network. IMO, it's > pretty good chice. > > Only thing I would update is to make it exactly specify to hypervisor is it > 32 or 64 bit OS. So 'FreeBSD-64' for amd64 and 'FreeBSD' for i386. >
Re: VMware Tools driver to advertise OS as 'FreeBSD 64-bit' OS, not 32-bit version
Kalabic S. wrote: > I have an OpenBSD VM running without issues as a guest with 'FreeBSD' > option for years and serving as an Internet router for home > network. IMO, it's pretty good chice. I want to say more. You really have no idea what you are talking about. The difference between 7.1 and 7.2 and future, is that all the clock hardware and a pile of MSRs are being inspected completely differently. But half of those are emulated by the VMs. The way this works is that the VM's have always emulated a pile of this stuff based upon "we know what guest is running". So you are welcome to keep running old OpenBSD on your VMs without making any changes. But that does not let you participate in the conversation about the new code.
Re: VMware Tools driver to advertise OS as 'FreeBSD 64-bit' OS, not 32-bit version
Kalabic S. wrote: > Also, OpenBSD really is part of BSD family. That is such a load of crap. You have absolutely no idea what vmware is doing behind the scenes based upon that string. Obviously, it is doing stuff. But you want to say "oh family". Stop it.
Re: VMware Tools driver to advertise OS as 'FreeBSD 64-bit' OS, not 32-bit version
> 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. Also, OpenBSD really is part of BSD family. I have an OpenBSD VM running without issues as a guest with 'FreeBSD' option for years and serving as an Internet router for home network. IMO, it's pretty good chice. Only thing I would update is to make it exactly specify to hypervisor is it 32 or 64 bit OS. So 'FreeBSD-64' for amd64 and 'FreeBSD' for i386.
Re: VMware Tools driver to advertise OS as 'FreeBSD 64-bit' OS, not 32-bit version
On Thu, Oct 27, 2022 at 11:02:06AM -0700, Mike Larkin wrote:
> On Wed, Oct 26, 2022 at 07:39:03PM +0200, Kalabic S. wrote:
> > Hello @misc,
> >
> > I do not see a reason not to update OS version that vmt (kernel level
> > implementation of VMware Tools) is advertising to VMware hypervisor from 32
> > bit FreeBSD to 64 bit version.
> >
> > If for nothing else, there's clock running forward issue that appeared in
> > 7.2 release and that is solved simply by manually specifying "FreeBSD
> > 64-bit" instead of "FreeBSD 32-bit" for "Guest OS Version".
> > - https://marc.info/?t=16667408377=1=2
> > - https://marc.info/?t=16663046932=1=2
> >
> > Attached is a simple patch that I tested and that changes string "FreeBSD"
> > to "FreeBSD-64" in a call to "SetGuestInfo" function on hypervisor and that
> > accomplishes the task.
> >
> > What could be a drawback? Is author David Gwynne still active and can he
> > give some feedback?
>
> What versions of ESXi did you test this with?
>
> Did you test both i386 OpenBSD VMs and amd64 ones on each version?
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.
Index: vmt.c
===
RCS file: /cvs/src/sys/dev/pv/vmt.c,v
retrieving revision 1.26
diff -u -p -r1.26 vmt.c
--- vmt.c 8 Sep 2022 10:22:06 - 1.26
+++ vmt.c 28 Oct 2022 03:50:29 -
@@ -626,14 +626,8 @@ vmt_update_guest_info(struct vmt_softc *
sc->sc_rpc_error = 1;
}
- /*
-* Host doesn't like it if we send an OS name it doesn't
-* recognise, so use the closest match, which happens
-* to be FreeBSD.
-*/
-
if (vm_rpc_send_rpci_tx(sc, "SetGuestInfo %d %s",
- VM_GUEST_INFO_OS_NAME, "FreeBSD") != 0) {
+ VM_GUEST_INFO_OS_NAME, "OpenBSD") != 0) {
DPRINTF("%s: unable to set guest OS", DEVNAME(sc));
sc->sc_rpc_error = 1;
}
Re: VMware Tools driver to advertise OS as 'FreeBSD 64-bit' OS, not 32-bit version
On 10/27/22 20:02, Mike Larkin wrote:
On Wed, Oct 26, 2022 at 07:39:03PM +0200, Kalabic S. wrote:
Hello @misc,
I do not see a reason not to update OS version that vmt (kernel level
implementation of VMware Tools) is advertising to VMware hypervisor from 32
bit FreeBSD to 64 bit version.
If for nothing else, there's clock running forward issue that appeared in
7.2 release and that is solved simply by manually specifying "FreeBSD
64-bit" instead of "FreeBSD 32-bit" for "Guest OS Version".
- https://marc.info/?t=16667408377=1=2
- https://marc.info/?t=16663046932=1=2
Attached is a simple patch that I tested and that changes string "FreeBSD"
to "FreeBSD-64" in a call to "SetGuestInfo" function on hypervisor and that
accomplishes the task.
What could be a drawback? Is author David Gwynne still active and can he
give some feedback?
What versions of ESXi did you test this with?
Did you test both i386 OpenBSD VMs and amd64 ones on each version?
-ml
Mike, good point, I forgot about i386 and so I actually did install a
new OpenBSD i386 Guest on ESXi 6.5.
Also have adjusted a patch for vmt to send 32-bit OS identifier for i386
and 64-bit identifier for amd64, it is attached here.
Tested on both guest on same hypervisor, ESXi 6.5.Index: sys/dev/pv/vmt.c
===
RCS file: /cvs/src/sys/dev/pv/vmt.c,v
retrieving revision 1.26
diff -u -p -p -r1.26 vmt.c
--- sys/dev/pv/vmt.c 8 Sep 2022 10:22:06 - 1.26
+++ sys/dev/pv/vmt.c 27 Oct 2022 21:55:40 -
@@ -633,7 +633,11 @@ vmt_update_guest_info(struct vmt_softc *
*/
if (vm_rpc_send_rpci_tx(sc, "SetGuestInfo %d %s",
+#ifdef __amd64__
+ VM_GUEST_INFO_OS_NAME, "FreeBSD-64") != 0) {
+#else
VM_GUEST_INFO_OS_NAME, "FreeBSD") != 0) {
+#endif
DPRINTF("%s: unable to set guest OS", DEVNAME(sc));
sc->sc_rpc_error = 1;
}
Re: VMware Tools driver to advertise OS as 'FreeBSD 64-bit' OS, not 32-bit version
On Wed, Oct 26, 2022 at 07:39:03PM +0200, Kalabic S. wrote:
> Hello @misc,
>
> I do not see a reason not to update OS version that vmt (kernel level
> implementation of VMware Tools) is advertising to VMware hypervisor from 32
> bit FreeBSD to 64 bit version.
>
> If for nothing else, there's clock running forward issue that appeared in
> 7.2 release and that is solved simply by manually specifying "FreeBSD
> 64-bit" instead of "FreeBSD 32-bit" for "Guest OS Version".
> - https://marc.info/?t=16667408377=1=2
> - https://marc.info/?t=16663046932=1=2
>
> Attached is a simple patch that I tested and that changes string "FreeBSD"
> to "FreeBSD-64" in a call to "SetGuestInfo" function on hypervisor and that
> accomplishes the task.
>
> What could be a drawback? Is author David Gwynne still active and can he
> give some feedback?
What versions of ESXi did you test this with?
Did you test both i386 OpenBSD VMs and amd64 ones on each version?
-ml
> Index: dev/pv/vmt.c
> ===
> RCS file: /cvs/src/sys/dev/pv/vmt.c,v
> retrieving revision 1.26
> diff -u -p -u -r1.26 vmt.c
> --- dev/pv/vmt.c 8 Sep 2022 10:22:06 - 1.26
> +++ dev/pv/vmt.c 26 Oct 2022 17:01:39 -
> @@ -633,7 +633,7 @@ vmt_update_guest_info(struct vmt_softc *
>*/
>
> if (vm_rpc_send_rpci_tx(sc, "SetGuestInfo %d %s",
> - VM_GUEST_INFO_OS_NAME, "FreeBSD") != 0) {
> + VM_GUEST_INFO_OS_NAME, "FreeBSD-64") != 0) {
> DPRINTF("%s: unable to set guest OS", DEVNAME(sc));
> sc->sc_rpc_error = 1;
> }
VMware Tools driver to advertise OS as 'FreeBSD 64-bit' OS, not 32-bit version
Hello @misc,
I do not see a reason not to update OS version that vmt (kernel level
implementation of VMware Tools) is advertising to VMware hypervisor from
32 bit FreeBSD to 64 bit version.
If for nothing else, there's clock running forward issue that appeared
in 7.2 release and that is solved simply by manually specifying "FreeBSD
64-bit" instead of "FreeBSD 32-bit" for "Guest OS Version".
- https://marc.info/?t=16667408377=1=2
- https://marc.info/?t=16663046932=1=2
Attached is a simple patch that I tested and that changes string
"FreeBSD" to "FreeBSD-64" in a call to "SetGuestInfo" function on
hypervisor and that accomplishes the task.
What could be a drawback? Is author David Gwynne still active and can he
give some feedback?
Index: dev/pv/vmt.c
===
RCS file: /cvs/src/sys/dev/pv/vmt.c,v
retrieving revision 1.26
diff -u -p -u -r1.26 vmt.c
--- dev/pv/vmt.c8 Sep 2022 10:22:06 - 1.26
+++ dev/pv/vmt.c26 Oct 2022 17:01:39 -
@@ -633,7 +633,7 @@ vmt_update_guest_info(struct vmt_softc *
*/
if (vm_rpc_send_rpci_tx(sc, "SetGuestInfo %d %s",
- VM_GUEST_INFO_OS_NAME, "FreeBSD") != 0) {
+ VM_GUEST_INFO_OS_NAME, "FreeBSD-64") != 0) {
DPRINTF("%s: unable to set guest OS", DEVNAME(sc));
sc->sc_rpc_error = 1;
}
