10.0 interaction with vmware

[dylan at techtangents.com]

Hi Paul,

 > We don't install open-vm-tools at the moment, therefore we have a 
known amount of memory to work with...
That's not correct. I'd suggest reading up on vsphere's memory management.

This article goes into it in depth, there's others around.
http://www.vmware.com/files/pdf/mem_mgmt_perf_vsphere5.pdf

I think you want to set a memory "reservation" for this vm in vmware.
"Reservation is a guaranteed lower bound on the amount of host physical 
memory the host reserves for a virtual machine even when host memory is 
overcommitted."

The vmware tools provide drivers for the paravirtualised devices. They 
also provide the ability to 'balloon' memory - see the above article. 
Basically, ballooning is a memory reduction technique which reduces host 
memory usage by inducing artificial memory pressure in the VM, 
encouraging the VM's kernel to swap out things it doesn't need.

VMware tools or not, if the host is under memory pressure, it will 
attempt to reduce memory usage using several techniques. Transparent 
page sharing, memory compression and swapping don't require vmware tools 
- it's just the ballooning that does. In any case, memory reservation or 
"shares" for the VM should help - if the memory is reserved for the vm, 
the hypervisor won't try and reclaim memory from the vm.

I think having tools installed should be a good thing.

Kind regards,

Dylan


> freebsd-stable-request at freebsd.org 
> <mailto:freebsd-stable-request at freebsd.org>
> 26 August 2014 10:00 pm
> Send freebsd-stable mailing list submissions to
> freebsd-stable at freebsd.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> or, via email, send a message with subject or body 'help' to
> freebsd-stable-request at freebsd.org
>
> You can reach the person managing the list at
> freebsd-stable-owner at freebsd.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of freebsd-stable digest..."
>
>
> Today's Topics:
>
> 1. 10.0 interaction with vmware (Paul Koch)
> 2. drm error in dmesg since using newcons (Jamie Griffin)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 26 Aug 2014 17:16:57 +1000
> From: Paul Koch <paul.koch at akips.com>
> To: <freebsd-stable at freebsd.org>
> Subject: 10.0 interaction with vmware
> Message-ID: <20140826171657.0c79c54d at akips.com>
> Content-Type: text/plain; charset=US-ASCII
>
>
> Curious if anyone has an understanding of what actually goes on
> with VMWare memory control of a FreeBSD 10 guest when open-vm-tools
> is installed and how it could affect performance.
>
> Our typical customer environment is a largish VMWare server with
> an appropriate amount of RAM allocated to the guest, which currently
> runs FreeBSD 10.0p7 + our software, UFS root, and data stored on a
> ZFS partition. Our software mmaps large database files, does rather
> largish data collection (ping, snmp, netflow, syslog, etc) and
> mostly cruises along, but performance drops off a cliff in low
> memory situations.
>
> We don't install open-vm-tools at the moment, therefore we have a known
> amount of memory to work with (ie. what the customer initially
> configured the guest for), but our customers (or in particular, their
> VM guys) would really like vmware tools or open-vm-tools by default.
>
> >From what we gather, many sites choose to "over provision" the memory
> in the VM setups, and when memory gets low, the host takes back
> some of the RAM allocated to the guest.
>
> How does this work actually work ? Does it only take back what
> FreeBSD considers to be "free" memory or can the host start taking
> back "inactive", "wired", "zfs arc" memory ? We tend to rely on
> stuff being in inactive and zfs arc. If we start swapping, we
> are dead.
>
> Also, is there much of a performance hit if the host steals back
> free memory, and then gives it back ? We'd assume all memory
> the host gives to the guest is pre-bzero'ed so the FreeBSD wouldn't
> need to also bzero it.
>
> Paul.