From owner-freebsd-stable@FreeBSD.ORG Tue Aug 26 13:39:25 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 970BDB6 for ; Tue, 26 Aug 2014 13:39:25 +0000 (UTC) Received: from smtp.teambox.fr (smtp.teambox.fr [212.129.12.31]) by mx1.freebsd.org (Postfix) with ESMTP id 300B63763 for ; Tue, 26 Aug 2014 13:39:24 +0000 (UTC) Received: from mail.teambox.fr (mail.teambox.fr [212.129.12.27]) by smtp.teambox.fr (Postfix) with ESMTPSA id 502211202D0 for ; Tue, 26 Aug 2014 15:30:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.local.mindstep.fr (Postfix) with ESMTP id B1F03FCA617 for ; Tue, 26 Aug 2014 15:30:03 +0200 (CEST) (envelope-from patrick.bihan-faou@teambox.fr) X-Virus-Scanned: by amavisd-new on ZunoBox at mail.local.mindstep.fr Received: from mail.local.mindstep.fr ([127.0.0.1]) by localhost (mail.local.mindstep.fr [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ixVIBbG6IuQT for ; Tue, 26 Aug 2014 15:30:03 +0200 (CEST) Received: from [192.168.25.62] (crest.mindstep.com [88.167.204.204]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.local.mindstep.fr (Postfix) with ESMTP id 6A828FCA429 for ; Tue, 26 Aug 2014 15:30:03 +0200 (CEST) (envelope-from patrick.bihan-faou@teambox.fr) Message-ID: <53FC8BD9.3070903@teambox.fr> Date: Tue, 26 Aug 2014 15:30:01 +0200 From: Patrick Bihan-Faou Organization: TeamBox SARL User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: 10.0 interaction with vmware References: <20140826171657.0c79c54d@akips.com> In-Reply-To: <20140826171657.0c79c54d@akips.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 13:39:25 -0000 Hi, From what I understand of the VMWare tools is that it adds a kernel module that comunicates with the host. When the host is under memory pressure it claims some of the memory used by each VM by asking the kernel module to grab RAM. This active RAM is "reserved" by the kernel module and can then be used by the host for another VM. This mechanism will increase the memory pressure inside your VM, which can lead to some swapping or freeing of otherwise less used memory pages in the OS. This cooperative mode of sharing the memory pressure experienced by the hypervisor is called "ballooning" in VMWare terms. The kernel module responsible to implement the VM side of this si called vmmemctl.ko. If the memory requirements cannot be met using this "ballooning" technique (or if none of the VM have the vmware tools enabled), you will start to see swapping at the host level, which will be much worse than swapping at the VM level. This is the main reason why you should run the vmware tools. Regards, Patrick. On 26/08/2014 09:16, Paul Koch wrote: > 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.