Re: Experiences with 7.0-CURRENT and vmware.

On Thu, May 10, 2007 at 01:28:16PM +0100, Robert Watson wrote:
> 
> On Thu, 10 May 2007, Darren Reed wrote:
> 
> >I'm using FreeBSD 7.0-CURRENT under vmware and there are a few issues.

Redirecting to current_at_...

> >First, time. hint.hw.acpi.disabled="1" This appears to make _no_ 
> >difference to time keeping on FreeBSD 7 and nor does it seem to have any 
> >impact on ACPI being loaded.  Do I need to recompile a new kernel without 
> >it or is there a new way to disable ACPI?
> 
> Have you tried hint.acpi.0.disabled=1 instead?  This is what appears in 
> acpi(4), and is what is used in various existing boot loader bits when I 
> grep around.

In another reply it was "hint.apic.0.disabled=1".
My current loader.conf:

vm.kmem_size=536870912
vm.kmem_size_max=536870912
unset acpi_load
hint.acpi.0.disabled=1
hint.apci.0.disabled=1
hint.acpi.0.disabled="1"
hint.apci.0.disabled="1"
vfs.zfs.arc_max=402653184

Booting with this gives me:
 kernel: Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000

and ACPI enabled.

> >I should add that FreeBSD 6, with the same setting, is no better and that 
> >I need to run ntpdate every 5-10 minutes via crontab in order to keep good 
> >time (timekeeping is *really* bad.)  In one instance, i was watching 
> >"zpool iostat 1" and it appeared like the rows were muching up at a rate 
> >of 2 a second for a minute or so. How do I disable TSC timekeeping?  
> >(NetBSD has this disabled by default in their kernels.)  Or is there 
> >somethign else I must do?
> 
> kern.timecounter.hardware: ACPI-fast
> kern.timecounter.choice: TSC(800) ACPI-fast(1000) i8254(0) dummy(-1000000)
> 
> I believe you can simply set kern.timecounter.hardware=APCI-fast and it 
> will do what you expect.  An interesting question is why it selects what is 
> arguably the wrong one; a post to current_at_ might help resolve that.

Hmm.

# sysctl kern.timecounter.hardware="ACPI-fast"
kern.timecounter.hardware: ACPI-safe
sysctl: kern.timecounter.hardware: Invalid argument

Or is this a loader.conf setting?

> >Second, networking. Prior to FreeBSD-7, the driver to use inside vmware 
> >workstation was lnc.  It has worked and contiues to work great.  No 
> >problemo. FreeBSD-7 uses the "em" driver.  To put it simply, it sucks in 
> >comparison.  When things really get bad I start seeing "em0: watchdog 
> >timeout" messages on the console.  I looked and I don't see a lnc driver 
> >anywhere.  Is there another alternative (le?) driver that I can use in 
> >place of em, if so, how?
> 
> Has VMware changed what network hardware they emulate, and/or does VMware 
> offer options about what virtual hardware to expose?

I don't believe so.  It still probes as pcn under NetBSD.

> The if_em driver is 
> for Intel ethernet cards; historically VMware has exposed a Lance ethernet 
> device supported by the lnc(4) device driver; now that driver has indeed 
> been replaced with le(4).

Right.  I believe it still is lance, but somehow em is showing up.

> But if if_em is probing, it suggests a VMware 
> change rather than a FreeBSD change, which you may be able to revert by 
> telling it to expose a Lance-style device as opposed to an Intel device.

There's no way to choose the type of card vmware emulates.
 
> Generally speaking, this would be a discouraged configuration, but you will 
> probably need to frob two settings: first, PermitEmptyPasswords in 
> sshd_config, and second, force non-PAM validation by setting UsePAM to 
> false. Instead of doing this, I would advise instead setting up an SSH key 
> for the account, and not set a passphrase on the SSH key.  This doesn't 
> require any changing of the global sshd configuration and should offer most 
> of the same benefits.

btw, there are instances where you can be promopted 6 times for a
password when logging in with ssh, 3 times with "Password:" prompt
and another three with "root_at_hostname's password:" promopt.

Darren