2008 Terminal Server / RDP on VMWare ESXi 5.1

[icepcsupport]

Hi,
I am new to VMware and need a little guidance, hope that I will find an answer.

I need a best practice guide to follow. Done a lot of research but seem to find only old posts related to vmware 4. I’m about to use Vmware 5

I have the following new hardware:
HP DL 360 G7, 2 x XEON E5606 @ 2.13 quad core (8 cores in total), 30GB RAM, 5 X 300GB 6G DP 10K SAS (1 hot spare) in RAID 5
On the ESXI 5.1 host I have running
1. Windows 2008 R2 Terminal server allocated 4 vCPU (2 sockets and 2 cores), 14 GB RAM and 250 GB allocated for OS / apps – C drive only, dedicated vSwitch team (2 NICS)
The TS will be used by max of 30 users.
2. Windows 2008 R2 DC allocated 4 vCPU (2 sockets and 2 cores), 14 GB RAM and 250 GB allocated for OS – C drive only 2 NICS to be shared with the Management Interface

Here are a couple of questions that I have:
- CPU – The server has 2 physical processors, how should I allocate these processors to the two servers?
- Memory, the server has 30gb ram, again how should I spread this between the two servers and the esxi console
- Memory Ballooning, can someone explain if I do anything here, I’ve read it causes issues with Remote desktop services.
- We have configured the server with 1 Raid 5 Logical drive and 1 hotpare, Any issues here?
- Different datastores for OS / Apps
- Power policy – should I disable power features from HP BIOS and let VMWare manage it, is the anything we need to enable?
- Passtrough for NIC’s
- Is 2 GB of RAM enough for the host
- Any known issues deploying Terminal Services RDP on VMWare
- VMWare Email Alerting, does anyone know how and where I setup email alerting, I’d like some sort of email alert if something went wrong like for example a network card losing a connection or a dead power hard drive?

- Kind Regards
Andrei

 

[cabraun]

Your line of thinking on how virtualization works in vSphere is a bit off base.

Let's start with CPU.

Best practice would say to start with 1 vCPU per VM and increase as needed from there. Since you only have 2 VMs on this host I would say that your are OK with the 4 per that you are currently using as you should not run into any contention. If additional VMs (even 1) are added to this host though at some point in the future, you will likely see things like CPU ready times increase which will be a problem. I might suggest busting your DC down to 2 vCPU especially if all it is doing is DC duties.

Don't "pin" VMs to specific processors. VMs will use CPUs as needed. If your VM has an operation needing 2 CPUs, it might use P1-C1 and P2-C3 for one process and the next time P1-C2 and P1-C4. Your VM doesn't care nor does the hypervisor and neither should you.

RAM.

Well the hypervisor will take it's RAM right off the top. Back in the day the maximum that the hypervisor could be assigned was 800MB. I am not sure off the top of my head how much 5.1 will use, but it is a minimal amount I am sure and not anything that you will need to concern yourself with changing. However it is not as you have described where if you have 30GB and you give 28 to your 2 VMs that leaves 2 for the hypervisor.

You can assign your VMs as little or as much as you like, even more than the 30 you have. Keep in mind though that your swap files will be based on the amount of memory you assign your VMs so if you give both your VMs 48GB then you will need to have 96GB of disk space (minus any reservation you have set) to accommodate that swap file. Doing something like that is called memory over commit. Again, I might suggest busting your DC down to 8 or even 4GB of vRAM especially if all it is doing is DC duties.

As far as ballooning, there is nothing you need to configure there. It is a memory reclamation technique that the hypervisor uses in the background. Essentially when a VM needs more physical RAM than the host currently has available, the hypervisor will force a VM or VMs to start swapping memory pages to disk to free up RAM for use by the VM that needs it at that moment. It just happens (as long as VMTools is installed in the guest) and there is nothing you need to do. If you notice that there is a lot of ballooning going on though, you should add more memory to the host as it absolutely will impact performance.

Disk.

If you are using the same spindles for all of your storage needs, it doesn't really make much sense to break down your apps from your OS from your database from your logs etc. There is no performance benefit to gain. If you want to have different VMDKs for each that is fine for separation within the OS to give you a warm fuzzy feeling, but in the end it won't make any difference if you lose 2 drives in your RAID 5 array, as all your data will be gone nor will there be any performance improment such as if you used RAID 5 for a DB and RAID 1 for your logs.

Alerts.

If you have vCenter, you can configure alarms and alerts to e-mail you or what not regarding things like diskspace thresholds or NICs flapping in the breeze.

 

[Provogeek]

Great explanation cabraun,

My 2copper on the CPU and memory; Don't assign resources to a virtual machine just because you have the resources. Only assign resources (and by resources I mean CPU and memory) that the virtual machine needs. Start at the minimum (1 vCPU 2GB RAM), then give it more if you find performance lacking. Allocating all your resources to the two planned VM's will make things annoying if you decide you want another VM on this system.

Straggler questions:

Let ESX manage the power, but you are a single server environment, you won't use any of the power policy features in vSphere.

Passthrough NIC's? That's more VMWare Workstation way of networking, little different in ESX. They are considered "Uplinks" from the vSwitch that the Port Groups are attached to. For your deployment with only two NIC's in the host, you will be fine with the VM port group and the Management port group assigned to the same vSwitch (should be vSwitch0 in this case). Then just assign both NIC's as uplinks to the vSwitch.
- The whole networking things is the part most of my customers get confused on. It helps to simplify it by considering every Ethernet port on the back of your server to be a physical switch port, not a NIC.

Terminal services works great on ESX. Just setup one up my self last Friday for a customer.




=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Brent Schmidt Senior Network Engineer
Keep IT Simple[/color red]

http://www.kiscc.com

Novell Platinum Partner Microsoft Gold Partner
VMWare Enterprise Partner Citrix Gold Partner

 

[icepcsupport]

Thanks guys,
Much appreciated.
I have installed the server on the network yesterday and will configure over the weekend.

Regards

Andrei