Low budget VMware capacity planning (part 1)

Today I started a research on options regarding capacity planning for an esxi deployment. Basically this project aims to virtualize ~30 physical servers.

First things first, I need to know whats the kind of load (cpu, mem, disk) I have globally. After that hopfully I will be able to size the hosts and begin the migration.
A chat with some esx ppl over #vmware follows:

[08:14am] MindTheGap: hello ppl. Im looking for metrics on how to plan an esx deployment, specially regarding client loads. Ok, I can measure network troughput, iops, MB/s but how do you size cpu requirements?
[08:14am] milestone: MindTheGap why not use the vmware capacity planner?
[08:14am] MindTheGap: I mean, a 20% load on a pentium4 means something completely different on a xeon
[08:20am] MindTheGap: i'm mostly calculating presentload/presentprocessorghz = X/futurecpughz where X would me the estimated load on the future processor but due to different architecture of newer processors, ghz also dont mean nothing.
[08:21am] MindTheGap: milestone, capacity planner is not free, at least the last time I looked up.
[08:22am] milestone: MindTheGap maybe it is worth the money... How bis is your setup?
[08:22am] MindTheGap: that would be presentload/presentprocessorghz = X/futurecpughz*numberofcores
[08:22am] twkm: empirical testing might prove useful to obtain your own ratios.
[08:22am] MindTheGap: milestone, not that big. something like 30 physical servers to be virtualized on a very tight budget.
[08:23am] twkm: ahh, good old very tight.
[08:23am] MindTheGap: :)
[08:23am] twkm: always enough money to have 30 servers, never enough to have 3 really good ones.
[08:23am] MindTheGap: tell me about it...
[08:24am] MindTheGap: its the fact of life of most Sysadmins
[08:24am] twkm: i like vmware's roi calculator. almost impossible to get it to present results for a transition.
[08:24am] johnt: capacity planner is only available for trained vmware partners at http://optimize.vmware.com/
[08:25am] johnt: MindTheGap perhaps you should calculate in Operations / Second
[08:26am] johnt: . /should/could/
[08:27am] MindTheGap: johnt, how should I do it? on a linux (to be)guest for instance?
[08:27am] twkm: that's the tricky bit, with today's processors, even with the p4.
[08:28am] twkm: put the known 20% p4 load on a proposed xeon (you can get an eval box, nyet?), and see what you get. tricky, but it can be instructive.
[08:29am] MindTheGap: johnt, I actually have not poked around /proc/ but I assume some statistics would be scattered there, yes?
[08:29am] twkm: esx, yes. esxi, no.
[08:29am] MindTheGap: twkm, sure, but Im trying to avoid it.
[08:29am] twkm: esx(i) is not linux.
[08:30am] MindTheGap: im talking about metrics, once i have it I can do it for the (would be)host as well
[08:30am] MindTheGap: and since the hosts have the same specs its ok
[08:30am] twkm: as you said, different cpu's. it won't be a constant.
[08:33am] MindTheGap: I got 3 maybe 4 hosts. all of them are Dell t410 with perc6i driving 2x 15k 500GB SAS, 8GB RAM and E5504 Nehalem procs.
[08:33am] twkm: if you are using esx for your eval you'd want to look at /proc/vmware/...
[08:35am] MindTheGap: i plan to use esxi on stand alone mode for now than maybe go for vsphere later on depending on the budget.
[08:36am] twkm: then you cannot see any stats on the host, and you'll have to get them via the api (e.g., in vsphere client).
[08:36am] MindTheGap: johnt, the operations/sec sounded good. can you elaborate on that please?
[08:37am] MindTheGap: im focusing on the guests now, then I will size the hosts and plan on how I will distribute the guests.
[08:40am] MindTheGap: twkm, I will measure the processor of the hosts while running linux on them, after taking 5% of esxi overhead maybe I will get a goot aproximation. well, I think
[08:40am] twkm: sounds like a starting point.
[08:45am] MindTheGap: so, just for the sake of clarity. there are no options for a "semi-professional" esxi deployment regarding to capacity planning, yes? either I do it by hand, creating my own metrics as I go or I will need to contact a vmware partner and give'em loads of money, is it correct? Dont take me wrong I'm not cheap I just dont have the money.
[08:46am] twkm: the not professional option is what you just got.
[08:46am] twkm: for the money spent you got the sort of results one would expect.
[08:47am] MindTheGap: twkm, oh, I very certain of that. but like I said, got no money but have to do it anyway.
[08:48am] MindTheGap: Actually it will be a good exercise. will make a post out of it. thanks everyone.
[08:49am] MindTheGap: I will start to hang out here more as I'm also preparing for my VCP next month, so I hope to chat w you all again. thanks twkm and johnt.
[08:50am] twkm: cpp;/
[08:50am] twkm: *boggle*
[08:50am] twkm: make that ... cool.

 

So, as I suspected, there are no options for a small scale deployment. Either you go for a full consulting with a VMware partner or you do it yourself.

Since some shops don’t have the money to spend on a full scale VMware solution, there is a gap between a low end deployment and a high end one.

Being so, I’ll move on with a diy aproach…

For the iops, mb/s and io contention I will use a very simple sampling of iostat output treated with awk resulting on a csv i can load on a spreadsheet.

Lets start with an awk script:


# Utilização: iostat -k N Y | awk -f iostat.awk > arquivodesaida.csv
# Exemplo: iostat -k 1 60 | awk -f iostat.awk > iostat.csv
BEGIN {
printf("%10s ;%10s ;%10s ;%10s ;%10s","CPU(Sy+Us)","I/O Wait","iops","kB_read/s","kB_wrtn/s")
}
(NF==6 && !/sda/ && !/evice/) {
printf("n%10s ;%10s ;", $1+$3, $4)
}
/sda/ {
printf ("%10s ;%10s ;%10s", $2, $3, $4)
}

This script gives me a nice output like this:

CPU(Sy+Us) ; I/O Wait ; iops ; kB_read/s ; kB_wrtn/s
16.55 ; 10.41 ; 195.29 ; 214.72 ; 516.47
0 ; 0.00 ; 0.00 ; 0.00 ; 0.00
0.25 ; 0.00 ; 0.00 ; 0.00 ; 0.00
0 ; 0.00 ; 0.00 ; 0.00 ; 0.00
0.5 ; 0.00 ; 0.00 ; 0.00 ; 0.00

to be continued…

proftpd daemon on VMware ESXi

Running an ssh server within ESXi is a must nowadays, at least for me and for all those shell junkies out there 🙂

Now, try to transfer large files over ssh with scp or rsync and you’ll be pissed. Even on gigabit networks maximum throughput will be just a few MB/s.

This is expected behavior as explained here and here.

If you want to speed things up you could use vSphere Client’s datastore browser, VMware Converter and friends but you REALLY WANT to do it from ESXi shell so lets run ProFTPD:

1 – Get this file.
Its just an oem.tzg with proftpd daemon bundled, as well as its proftpd.conf.
ps. this oem.tgz was put together using the one from Dell Embedded ESXi 4 install image. It should be safe to use on any server brand though. Here and here there are the generic instructions if you would like to build your own.

2 – Copy it to ESXi /bootbank/oem.tgz.

3 – Add this line to /etc/inetd.conf.
“ftp stream tcp nowait root /usr/sbin/tcpd proftpd”

4 – Reboot ESXi.

Ftp will be happily listening on port 21 after boot.