Lat night I joined Damien Karlson on the professionalvmware.com brownbag session. The topic I covered was an overview of vCloud Networking Basics and then talking about the design considerations to remember when creating these networks.

This was my first design topic on vCloud and I think it went over very well. Everything from this podcast was a product of my own findings and I'm happy the way it turned out. I'm by no means a vCloud expert so I appreciate any feedback, comments, and corrections.

Thanks everyone that joined and I hope when you watch this presentation it's valuable. You can download the slide deck below (with all my speaking points in the comments section of each slide) or preview it below. You can also watch the recorded video webcast below as well.

**Update**

There will be new tools added to the presentation that weren't even seen in VEGAS! So come catch the most updated presentation!

Didn't make it to VMworld in Vegas? Bummed you won't be seeing #CIM1940 in Copenhagen? No problem! David Davis and I have been graciously invited by Xangati to do a world-wide webinar on October 26th! This webinar will be an encore presentation of #CIM1940; The Top 10 Free Tools for vSphere in 2011! This is your chance to watch one of the highest rated sessions from VMworld 2010 and to see everything that was new in 2011. If you weren't able to make it to our session in Vegas, then this is your chance to watch it and see what you missed.

If you happened to catch our session at VMworld, you would know that we don't just show 10 tools, it's probably closer to 30. We give credit where credit is due for all the members of the VMware Community that dedicate time and effort into producing all these free tools. This session appeals to every person who has an interest in vSphere. We will talk about some of the free tools that beginners and novices can use that are easy out-the-box solutions and we will discuss some of the tools that require a bit of CLI work that appeal to those experts out there. We scoured hidden corners of the web to bring you the greatest content available. So come one and all to see the "greatest webinar on earth"!

I can guarantee that you will come back armed with more knowledge than you expected because this isn't a single product pitch, heck, it's not a product pitch at all. This is a webinar focused on giving vSphere admins what they want, knowledge to overcome obstacles in every day situations.

Here are some of the responses we received from our session in Vegas at VMworld 2011:

• "Best little gems, can't wait to try them out!"
• "Even better than last year, best session for the whole week"
• "One of the best presentations I attended. Had actual usable content instead of a sales pitch."
• "One of the best sessions I attended"

We have to thank Xangati for sponsoring this WebEx because it wouldn't be possible without them. So show them some love too.

vCloud Director networking is one of the trickiest pieces of the stack. Put it this way, if you can understand vCloud Networking, then understanding everything else is vCloud should be fairly simple. I don't want to get into the concepts of "what is an external network?" or "what is a fenced network?" because a lot of the information is already available. I would encourage you to watch Mike DiPetrillos VMworld 2010 & 2011 talks called "vCloud Networking Finally Explained." Or check out Massimo's blog post vCloud Director Networking for Dummies. This is geared towards making you understand the layers of Organizational Networks and how it relates to External networks, etc.

This is going to be mainly focused on things that need to be setup that you don't normally find in the install guides.

First thing is first, you must think about design.

How many external networks do you need? An external network should be a VLAN that A) already exists within your corporate network that you want connections attached to such as a dev/test network, connections to IP based storage, etc or B) VLANs for vCloud external access to the internet. The amount of external networks is completely dependent on your environment, and will solely rely on where the VMs inside the vCloud need connections. These external networks can be Layer 2 or Layer 3 networks.

I have to say thanks to my friends Chris Colotti and Dave Hill verifying this for me. I'm currently in the middle of writing a blog post on vCloud Director networking that will talk about the creation and installation of networking components and found this little tidbit of information.

To understand what I'm talking about, you need to know what the difference is between a static portgroup and an ephemeral portgroup on a vNetwork Distributed Switch. These definitions are taken from KB Article: 1010593:

• Static Static Binding (Default): means that the dvPort is assigned to the virtual machine at configuration time. When all the ports are booked by virtual machines, it is not possible to connect to any more virtual machines, regardless of whether the connected virtual machines are powered up or not, and an error message is displayed.

• Dynamic Dynamic Binding (being deprecated): means that the dvPort is assigned at the moment of powering the virtual machine up. This option allows for over committing the number of dvPorts.

• None (Ephemeral ports): (Ephemeral Ports or No Binding) this behavior resembles the behavior in the standard vSwitch. If you select this option, the number of ports are automatically set to 0, and the Portgroup allocates one port for each connected virtual machine, up to the maximum number of ports available in the Switch.

In vCloud Director 1.0.X, any port groups that were created by vCD were given an ephemeral setting. The reason for setting it as ephemeral was to make sure that the creation and destruction of VMs didn't waste unused ports on a the vNetwork Distributed Switch. Thereby giving vCloud Director the safety net and availability to not worry about capping the dvSwitch's maximum setting or having to worry about setting the static port totals.

Hey Now! I was invited by Rick Vanover from Veeam to be a guest on the Veeam Community Podcast and we talk about all things about VMworld, home labs, and the "Three Views from You". Thanks again to Rick and the Veeam team for allowing me to be a part of this... it's always a blast

Here is the description:

In this episode, Rick Vanover hosts Kendrick Coleman. Kendrick (or Kenny) is a virtualization professional based in Louisville, KY. Kenny also blogs at KendrickColeman.com and has presented a few times at VMworld. In this episode, Rick and Kenny talk about virtualization home labs and a miscellaneous state of the union regarding virtualization.

Kenny is in the hot seat for "Three Views from You."

You can check out the podcast below or you can listen to it at Veeam's Podbean.

UPDATED VERSION!!!

Please go to - Design vCloud Director on VCE Vblock Systems - 2.0

Over the past few months, I've been working on a project with Chris Colotti and Sumner Burkhart of VMware along with Jeramiah Dooley and Sony Francis of VCE on a collaboration effort to design a best practice for running VMware vCloud Director on a Vblock.

It all began when I took the class VMware vCloud: Architecting the VMware Cloud and I had this urge to create a design so Vblocks could be deployed in a standard fashion so you could easily have vCD up and running on a Vblock in little time. There were many design considerations to take into account because the Vblock has many components and each of which has it's own constraints. I remember reading a blog from Chris Colotti called vCloud on Vblock – Findings from the field, so I got in touch with him via twitter to see if he would want to collaborate on such an effort. Once he was on board, Jeramiah and Sony reached out to me internally to see if they could join in. We decided it was best to draft up something that addresses everything we see today on current Vblock models along with vCloud Director 1.0.X and associated technology. This paper doesn't address the recently announced vCloud Director 1.5 components but most will remain unchanged except 1 or 2 sections depending upon changes in related technologies in the upcoming months.

This document is a joint effort between five people and doesn't reflect the supportability from our employers. This document is merely a reference architecture for running vCloud Director on a Vblock and it's associated technologies such as VNX, Fast Cache, Fully Automated Storage Tiering (FAST), Cisco Nexus 1000v, vNetwork Distributed Switch (vDS), vShield Edge, and more.

THIS HAS BEEN UPDATED. PLEASE VISIT VMware vSphere 5 Host NIC Network Design Layout and vSwitch Configuration [Major Update]

As vSphere has progressed, my current 6, 10, and 12 NIC designs have slowly depreciated. In an effort to update these to VMware vSphere 5, I took the 2 most popular configurations of 6 and 10 NICs and updated the Visios to make them a bit more pretty. I also don't know how much longer these will be necessary as the industry moves forward with 10GbE as a standard.

The assumption of these physical NIC designs is that these hosts are going to be configured with Enterprise Plus Licensing so all the vSphere features can be used. I didn't create a bunch of different designs as before because ideally you would want to stick with a simple design that meets a bunch of criteria for most people. In addition, I have updated these configs for performing multi-pathing for iSCSI and removing the use of etherchannel configurations because those were mostly needed on standard vSwitch configurations. I would also recommend to start moving everything over to a vNetwork Distributed Switch configuration because it is the easiest way to standardize across all of your hosts. vSphere 5 implemented a better HA and failed host policy in vSphere 5 so the use of a hybrid solution is fading as well.

Another assumption that has been depicted in every diagram is the physical switch configuration. These configurations can be done via Cisco 3750Gs with cross-stack links so it's viewed as a single switch or a single highly available enterprise switch such as a Cisco 4500 or can be implemented in a vPC configuration of dual Cisco Nexus 5000 or 7000s. The most important thing to keep in mind is that the switches in these configurations are enterprise class and you aren't connecting two switches via LACP because if you are doing that then the load teaming/balancing settings needs be re-configured.

All of this information is freely available in a few whitepapers that are a part of VMware vCloud Architecture ToolKit (vCAT) 2.0. These sets of documents are very in-depth and offer a great learning experience for anyone looking into vCloud Director. Note: I'm not discovering anything new, I am just merely pointing out some of the caveats and thought considerations that may be brought up.

vCloud Director extends the capabilities of the vSphere layer and focuses on delivering an IaaS model where by consumers can request resources from a cloud environment. vCloud Director also packages the vCloud API along with it that allows custom applications to be written so you can talk to a vCloud instance.

Let's dive into the first standout feature of vCloud 1.5: SQL Database support. Originally, vCloud Director was only supported on Oracle databases, which may have been a big influence into it's lack of early adoption. I have written an article called Installing vCloud Director 1.5 With SQL Server 2008 that details the steps to install vCloud Director using SQL Server. Some design considerations to take into account now is your SQL Database VM Sizing and perhaps having multiple SQL VMs. There are many components in a vCloud Design that utilize a SQL database: vCloud Director, vCenter(s), VUM(s), Chargeback(s), vCenter Orchestrator, and more. The size of your VM is now greatly effected if you have all these databases living on a single VM. Of course it can be done, but there is also the possibility to split it out into multiple VMs. A constraint to keep in mind for running vCloud on SQL or Oracle is cross-compatibility if you ever decide to switch. Moving from Oracle to SQL isn't an easy process as indicated in a 167 page document. VMware recommends a 4vCPU VM, 16GB of RAM and 100GB of Storage.