Recently at the Belgium VMUG I gave a presentation in which I covered some design tips for VMware vSphere 4. I talked about some business decisions that, how boring they may seem, are crucial for your design. I covered some security requirements you should check with the security department of the organisation and of course advised good capacity planning which also is very important for your design.
What the average geek found most interesting where topics like: “What size of ESX host will you buy?”, “How to run vCenter in a VM”, “VMFS best practises”, “Understanding queue depth and lun size” and more….
For this presentation I would like to thank all the guys that worked with me together on this in Google Wave (See page 2). Thanks !!!!
Below you’ll find the PDF of my presentation.
Design tips for VMware vSphere 4
Great Document – has given me some food for thought for my next bit of design work !
Would you please explain about only running the virtual vCenter VM on 1st and 2nd host??
Please add a comment about the best way(s) to ask you questions about your presentation.
Thank you, Tom
Great Document – has given me some food for thought for my next bit of design work !
Would you please explain about only running the virtual vCenter VM on 1st and 2nd host??
Please add a comment about the best way(s) to ask you questions about your presentation.
Thank you, Tom
Thanks for the PDF!
Hi Tom,
(Also replied to you by e-mail)
Your question on why run vCenter on 1st and 2nd host only…. Well, if you have vCenter moved around constantly by DRS you don't always know on which host it is running. Now, if a real disaster happens, it might happen that you lose your vCenter and want to use direct connections to your ESX host to restart the vCenter VM. But when vCenter is down, you have no way of figuring out on which host the vCenter VM was last seen. You could connect to each host in your cluster and search for it there, but image doing this for 8 or 16 hosts with a manager breathing down your neck.
So the easiest way is to excluded the vCenter VM from DRS. It will now never be VMotioned without you knowing. If you now also agree upon with your fellow admins that vCenter should always run on the first host in the cluster. You always directly know where vCenter is. Should host1 require maintenance, you move vCenter to the second and move it back to the first afterwards.
Regards
Gabe
Thanks for the PDF!
Hi Tom,
(Also replied to you by e-mail)
Your question on why run vCenter on 1st and 2nd host only…. Well, if you have vCenter moved around constantly by DRS you don't always know on which host it is running. Now, if a real disaster happens, it might happen that you lose your vCenter and want to use direct connections to your ESX host to restart the vCenter VM. But when vCenter is down, you have no way of figuring out on which host the vCenter VM was last seen. You could connect to each host in your cluster and search for it there, but image doing this for 8 or 16 hosts with a manager breathing down your neck.
So the easiest way is to excluded the vCenter VM from DRS. It will now never be VMotioned without you knowing. If you now also agree upon with your fellow admins that vCenter should always run on the first host in the cluster. You always directly know where vCenter is. Should host1 require maintenance, you move vCenter to the second and move it back to the first afterwards.
Regards
Gabe
Perfect sense. Except that I would not say 1st and 2nd host, I would explain more like what you said here.
Your point is that one must always know which host(s) the VC VM is on, but which hosts in the cluster, it doesn't really matter.
In smaller environments this is easy, I'm sure in larger environments this can be difficult.
Thank you, Tom
Perfect sense. Except that I would not say 1st and 2nd host, I would explain more like what you said here.
Your point is that one must always know which host(s) the VC VM is on, but which hosts in the cluster, it doesn't really matter.
In smaller environments this is easy, I'm sure in larger environments this can be difficult.
Thank you, Tom
maybe you can also post the context as I hardly see any decisions based business requirements?
It does not matter Tom as long as it is documented indeed. I would personally prefer the approach that makes the most sense which is the first and second host in a cluster.
maybe you can also post the context as I hardly see any decisions based business requirements?
It does not matter Tom as long as it is documented indeed. I would personally prefer the approach that makes the most sense which is the first and second host in a cluster.