(Presentation) Design tips for VMware vSphere 4

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

Design tips for VMware vSphere 4

  • Chris Dearden

    Great Document – has given me some food for thought for my next bit of design work !

  • tom12010

    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

  • Chris Dearden

    Great Document – has given me some food for thought for my next bit of design work !

  • tom12010

    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

  • http://jaredlog.com Jared Evans

    Thanks for the PDF!

  • http://www.GabesVirtualWorld.com Gabrie van Zanten

    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

  • http://jaredlog.com Jared Evans

    Thanks for the PDF!

  • http://www.GabesVirtualWorld.com Gabrie van Zanten

    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

  • 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

  • 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

  • http://www.yellow-bricks.com/ Duncan

    maybe you can also post the context as I hardly see any decisions based business requirements?

  • http://www.yellow-bricks.com/ Duncan

    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.

  • Pingback: Top 5 Planet V12n blog posts week 44 – VMvisor

  • http://www.yellow-bricks.com/ Duncan

    maybe you can also post the context as I hardly see any decisions based business requirements?

  • http://www.yellow-bricks.com/ Duncan

    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.

  • Pingback: VMUG Aftermath » Yellow Bricks