ESXi optimal guest config

[grp]

Hello all,

I plan to deploy a new virtual infrastructure. In particular:

1. One (1) ESXi 5 hypervisor running on an HP compliant server (via SD card). 16GB memory, 2 quad-core CPUs.

2. The server will be connected to an external 4TB HP storage array via iSCSI.

All the guests will be relatively small (running CentOS and Windows Server 2003 and 2008), except for one which has to have 2TB storage space and it will be running CentOS (5 or 6).

My questions are simple:

1. Should I create 32-bit or 64-bit guests? I have no special needs that would force the creation of 64-bit guests, I am just asking in terms of performace/resource allocation.

2. Should I create my guests using the same layout of CPUs as the host (ie. 2 quad-core VCPUs), or as single-cpu, single-core guests?

3. Should I create one 2TB virtual disk for my large guest? Or, for example, should I create a disk in the array and access it via NFS or something?

4. Should I store the large disk as one piece or 2GB pieces?

5. I intend to backup the server to another standalone machine through the network. Is there a faster/better way to backup the large guest apart from transferring the data via a 1Gbps network link?

Thank you all in advance

[Slingsh0t]

A few responses to your queries:

1. If the apps and services you're going to run have 64bit versions then why not go for 64bit guests?  I doubt you'll see any real impacts with regards to resource contention unless you excessively provision memory and CPU to the VM's...

2. Always allocate 1vCPU and then work your way up to additional CPU's depending on bottlenecks.  Sometimes you know in the case of heavily utilized VM's that 1vCPU will be a bottleneck, in that case add in an extra cpu and continue to work your way up as required.

3. You could create a 2TB vmdk for your guest, an alternative option could be an RDM to a LUN on your array?  Perhaps go with a virtual rdm so you can still snapshot the CentOS vm...

4. I'd store it as one large file instead of splitting it, I don't believe you'll have an option to split it into smaller 2GB chunks (perhaps someone can clarify this).  This is also assuming you're using vmfs5 or 3 with 8mb block size.

5. You could thin provision your 2TB disk which will make the backup process faster in the short term.  Perhaps differential or incremental guest OS level backups may be a more feasible way of managing the backup of that vm.

Hope this may help with your deployment :smileyhappy:

[grp]

Thank you for your detailed reply. I would just need some clarification:

1. How should I determine the existence of a VCPU bottleneck? At guest level or ESXi level? Any suggestions/tools/resources? Also, an important question: HOW should I increase VCPUs? Increase cores or processors?

2. I have to admit I haven't thought the RDM solution. Seems nice. But I am not sure what you mean by a virtual RDM. Also, why can't I snapshot a normal RDM?

3. What exactly is 'thin provisioning'?

4. So far, I am doing incremental backups at guest OS level, using Acronis 9.7 agents. In my test ESXi environment, I have tried Backup Exec 2010 R3 as well as Acronis 11 Virtual. In my opinion, they are both problematic.I haven't been able to do a satisfying backup/restore under any scenario. Very slow, buggy. Apart from that, I do not have so many guests to having to backup at ESXi level. I will most probably continue doing the backup at guest level. In my 2TB guest -a mail server as you might have guessed- I will soon be switching to maildir format, so I guess the incremental backup will be considerably faster. So I am seeking the best solution for backing up guest OSs directly.

[Slingsh0t]

No worries, happy to try and help where possible.

1. The process I've followed in the past with sizing VM's appropriately is in the case of physical-to-virtual migration, run some software such as platespin recon which will monitor resource usage patterns over time (4 weeks or so).  This will give a recommendation on how many CPU's, how much mem etc, to allocate to the VM.  If I've been asked to spin up a new VM with more than 2 vCPU's I'll normally ask why the extra compute is needed as in most cases people immediately think "the more the better" which can cause unnecessary contention on the hypervisor when all those vCPU's aren't even needed.  If you think you have a server that will be demanding on the cpu, then give it 2 and see how it goes over time.  Monitor resource usage from both within the guest and at the esxi level.  If you find you get insufficient performance run perfmon and see what the guest is doing.  High cpu usage for one vm will suggest a bottleneck and an instance where increasing the vcpu count might improve performance.

2. When you configure a VM with an RDM, you can select either direct access to the lun or virtual access which is where a file (a link to the physical lun) will be stored in with your VM on the datastore.  If you snapshot the virtual machine when it has physical access to the rdm, it will only be able to snapshot any virtual disks (vmdk's) and thus any changes on the rdm will not be able to be rolled back.  When it's a virtual rdm and you take a vm snapshot, it will write changes to the vmdk on the datastore instead of on the rdm so you will still be able to roll back.

3. I just meant a Thin Provisioned virtual disk.  If you pre-allocate a 2TB vmdk to a vm and it isn't full, then you want to back that vmdk up at the esxi level, thats a big file to store.  A Thin provisioned disk is only as big as the utilization of said disk, could mean a smaller file to backup unless you're using the entire 2TB's.

4. A couple of options:  Have the OS drives of all VM's in vmdk's on an "OS" datastore (my guess is you're already planning/doing this).  Have a seperate Datastore for app disks that perhaps have data that may not be suitable for vmdk backups, put your 2TB vmdk in this datastore.  Configure ESXi level backups to only occur on the OS datastore, leave the in guest file backup in place for the 2TB drive only.  Alternatively just make a 2TB lun for the mail server and again do an os-level backup of that drive?  Sorry I'm not very experienced on the backup side of things so these suggestions may not be the best solution...

[satya1]

grp wrote:

Hello all,

I plan to deploy a new virtual infrastructure. In particular:

1. One (1) ESXi 5 hypervisor running on an HP compliant server (via SD card). 16GB memory, 2 quad-core CPUs.

2. The server will be connected to an external 4TB HP storage array via iSCSI.

All the guests will be relatively small (running CentOS and Windows Server 2003 and 2008), except for one which has to have 2TB storage space and it will be running CentOS (5 or 6).

My questions are simple:

1. Should I create 32-bit or 64-bit guests? I have no special needs that would force the creation of 64-bit guests, I am just asking in terms of performace/resource allocation.

2. Should I create my guests using the same layout of CPUs as the host (ie. 2 quad-core VCPUs), or as single-cpu, single-core guests?

3. Should I create one 2TB virtual disk for my large guest? Or, for example, should I create a disk in the array and access it via NFS or something?

4. Should I store the large disk as one piece or 2GB pieces?

5. I intend to backup the server to another standalone machine through the network. Is there a faster/better way to backup the large guest apart from transferring the data via a 1Gbps network link?

Thank you all in advance

hi please find below answer to your question.

1-use 64 bit

2-use guest layout

3-if can configure disk arres is better and faster than single disk

4-sore in one disk

5-use replication method for backup so that only what ever changes you made that will update to back up instead of all data

Yours,

Satya