Very thorough Tim :)
Kind regards, Paul Angus Regards, Paul Angus paul.an...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue -----Original Message----- From: Timothy Lothering [mailto:tlother...@datacentrix.co.za] Sent: 13 April 2016 09:42 To: users@cloudstack.apache.org Subject: RE: VM per HOST? Hi Mindaugas, As per previous responses, the trend is to keep to memory as you base benchmark for VM density, from personal experience, memory is always the limiting factor. vCPUs are rarely a bottleneck for general workloads (there are however specific instances where CPUs are the limiting factor). We do not use Memory over-provisioning, but do use CPU over-provisioning. We also have converged networking and storage connectivity, so the information below might vary from your configuration. These numbers below are a personal opinion and will vary from Provider to Provider. When looking at VM density on a specific host, consider the following: 1. Recommended pCore to vCore ratios, some hypervisor vendors publish this information freely on the web - see VMware Oversubscription best practices - https://communities.vmware.com/servlet/JiveServlet/previewBody/21181-102-1-28328/vsphere-oversubscription-best-practices%5B1%5D.pdf 2. From #1, consider using HT, the hit is between 10-15%, but you virtually double your core count, 3. Once an over-subscription value as been decided, for example 1:4 (pCore:vCore), then you can guestimate the average VM instance resources - we have seen more 4vCPU & 8GB RAM instances. Calculate the required memory from this value - i.e you can get between 16-30 hosts (per Sockect) using this configuration and need 256GB RAM. (you could get even more, but then you need to consider the impact on Customer VM instances) 4. With a reference VM count in hand, consider the disk IO and throughput, this will determine what will be required from a storage throughput aspect. Looking at the 2x CPU options you have presented, http://ark.intel.com/compare/83356,81705, I would personally opt for the E5-2630, 1. Lower RRP 2. Lower TDP 3. Lower Cooling requirements Thanks. Kind Regards, Timothy Lothering Timothy Lothering Solutions Architect Managed Services T: +27877415535 F: +27877415100 C: +27824904099 E: tlother...@datacentrix.co.za DISCLAIMER NOTICE: Everything in this e-mail and any attachments relating to the official business of Datacentrix Holdings Ltd. and its subsidiaries ('Datacentrix') is proprietary to Datacentrix. It is confidential, legally privileged and protected by law. Datacentrix does not own and endorse any other content. Views and opinions are those of the sender unless clearly stated as being that of Datacentrix. The person addressed in the e-mail is the sole authorised recipient. Please notify the sender immediately if it has unintentionally reached you and do not read, disclose or use the content in any way. Datacentrix cannot assure that the integrity of this communication has been maintained nor that it is free of errors, virus, interception or interference. -----Original Message----- From: Mindaugas Milinavičius [mailto:uabstarn...@gmail.com] Sent: Wednesday, 13 April 2016 10:00 AM To: users@cloudstack.apache.org Subject: RE: VM per HOST? Server/blade is HBA 8Gb FC connectivity with switch. Its more then enough:) 13 апр. 2016 г. 10:57 пользователь "Paul Angus" <paul.an...@shapeblue.com> написал: > I'd agree with that. Memory is nearly always the limiting factor when > it comes to VMs per host. > > -- unless you're talking about blades, and then you have to start > looking carefully at the connectivity between the chassis and the switch > fabric. > > > Kind regards, > > Paul Angus > > Regards, > > Paul Angus > > paul.an...@shapeblue.com > www.shapeblue.com > 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue > > -----Original Message----- > From: uabstarn...@gmail.com [mailto:uabstarn...@gmail.com] On Behalf > Of Mindaugas Milinavicius > Sent: 11 April 2016 13:53 > To: users@cloudstack.apache.org > Subject: Re: VM per HOST? > > Thank you, i'm thinking something like that too..... > > > > > Pagarbiai > Mindaugas Milinavičius > UAB STARNITA > Direktorius > http://www.clustspace.com > LT: +37068882880 > RU: +79651806396 > > Tomorrow's posibilities today > <http://www.clustspace.com/> > > - 1 Core, 512MB RAM, 20GB SSD, 1Gbps, Unlimited, Location: Romania, Los > Angeles, Ashburn Washington - 11EUR > - 1 Core, 1024MB RAM, 30GB SSD, 1Gbps, Unlimited, Location: Romania, Los > Angeles, Ashburn Washington - 18,7EUR > - 2 Cores, 2048MB RAM, 40GB SSD, 1Gbps, Unlimited, Location: Romania, > Los Angeles, Ashburn Washington - 27,5EUR > - 4 Cores, 4096MB RAM, 100GB SSD, 1Gbps, Unlimited, Location: Romania, > Los Angeles, Ashburn Washington - 46EUR > > > On Mon, Apr 11, 2016 at 3:49 PM, Stavros Konstantaras < > s.konstanta...@uva.nl > > wrote: > > > In our case (general purpose VMs) we decided to have the system's > > RAM as the reference point to create our VM limit. For example, if > > the server has 128GBs of RAM and the default VM profile is 1 vCPU + > > 4Gbs RAM, then our upper limit is roughly 30VMs per server. > > > > Over provisioning the CPU is usually not a problem but over > > provisioning the RAM can be the start of many problems . > > > > Kind Regards > > Stavros > > > > ---------------------------- > > Stavros Konstantaras > > Science faculty Research IT support (FEIOG) University of Amsterdam, > > Science Park 904, 1098 XH > > > > Fingerprint: E5E5 9B19 D1CD 88CD 4763 3465 A8DC 7C92 330F D59A > > > > > On 11 Apr 2016, at 13:09, Erik Weber <terbol...@gmail.com> wrote: > > > > > > On Mon, Apr 11, 2016 at 1:02 PM, Mindaugas Milinavičius < > > > mindau...@clustspace.com> wrote: > > > > > >> Hello, > > >> > > >> how many VM's do you creating per host? > > >> What you prefer E5-2650v3 or E5-2630v3 (less power, 2x cheaper > > >> CPU, and only ±20% less benchmark) > > >> > > >> > > > I'd say it depends on the workload. For generic purpose VMs CPU is > > usually > > > not the bottleneck and personally I'd pick the cheaper one. > > > > > > You should look into v4 CPUs while at it. > > > > > > -- > > > Erik > > > > >
