This is a second post from the other blog post that I put out this morning called vSphere 5.1 vCenter Virtual Appliance and vSphere Web Client Video Tutorial Series.

In this video I look at a bunch of new features of vSphere 5.1 that can be seen from the new vSphere Web Client. Enjoy!

Xangati has released a new feature to their product set called the storm tracker. This allows more visibilitiy into the infrastructure. After seeing this for the first time, it was pretty cool. it integrates all the cool Xangati features such as the DVR functionality but also brings in WMI integration. So think about this. A storm is present, you can see that it's on host 05 in your cluster, you can see that its on VM-X, but what caused that problem? WMI integration now lets you playback the recording and actually see the windows process that was running that attributed to the storm. pretty cool. They will be at VMworld so definitely go check them out! Here is there Press Release

I'm building out a new vCloud environment and I'm building it on a block only Vblock. That means the array doesn't have NFS capabilities to present out. I had to be creative and I figured creating an OpenFiler VM would be easy. You need to have a NFS share created that all cells can access because that's where transfers happen. Read about that more at Chris Colottis blog Gotcha: vCloud Director Clone Wars Part 1 (Overview)

I'm not going to teach you how to create a NFS share on an OpenFiler VM because that's been done before. Read here Configure NFS shares in Openfiler for your vSphere homelab

I eat my own dog food and follow my own how-to's and when I got to Step 9 in How To Install VMware vCloud Director 1.5 From Beginning to End about setting permissions on the NFS share, I ran into an issue. When trying to change the ownership with my usual chown -r "vcloud:vcloud" transfer/ , it said the operation was not permitted, even though I was root.

This is an update to an older post and I wanted to overhaul it for the Indy VMUG... This was also another VMworld submission that didn't get the votes. See what you guys are missing out on? :)

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. I also added in a few more designs as inclusion of Fiber Channel has also been requested.

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. So if you are using a standard vSwitch, please make adjustments appropriately.

They key to any design is discovering requirements. I shouldn’t have to say it because that’s really the first rule of design. That being said, I don’t think I need to talk about it any deeper. Once you have your design requirements, you need to start thinking about the rest of these components. The goal of any good design is finding a perfect balance of redundancy and performance. You need to strive for that perfect balance on redundancy and performance while keeping budgetary constraints in mind.

Here is a comprehensive list of default username and passwords for most of the VMware products. If you're like me, you tend to get alot of these confused. If I left any off, please let me know in the comments.

Horizon Application Manager

http://IPorDNS/SAAS/login/0

http://IPorDNS

Horizon Connector

https://IPorDNS:8443/

vCenter Appliance Configuration

https://IPorDNS_of_Server:5480

username: root

password: vmware

Here was a VMworld session that didn't get picked, so here we go...

The biggest difference between vSphere and vCloud is that whatever you are trying to accomplish in vCloud Director all depends on the design. With vSphere, there are pretty standard practices to designing a standard layout. There are options in vSphere design to meet certain criteria, but you ultimately can't design for vCloud Director until you have a strong understanding of the effects of vSphere design.

After designing for a few vCloud Director environments, I wanted to create a list that anyone can reference so you can nail down the top design criteria. Without further ado in no particular order..

1. Is vCloud Director actually necessary?

I'm not going to lie, there is a bunch of hype out there about vCloud Director. Since the inception of Project Redwood, it was touted as the generation of VMware's cloud offering. Every product from every vendor is working on vCloud integration, with partners, contractors, and vendors are pushing for it's adoption, and VMware itself seeing vCloud being the next vSphere. But what does that mean for you? I would imagine atleast 90% of IT shops today have some sort of virtualized environment and that's the stepping stone. If you are thinking of adopting vCloud, you have to ask yourself, "what am I really trying to accomplish?"

The answer to this question is going to be unique for everyone. Are you a service provider, an enterprise customer, or a SMB user? Are you just looking for a portal with a self-service catalog? Are you trying to create multi-tenant networks?

I've done vSphere 5 NIC designs using 6 NICs and 10 NICs but this one is going to be a bit different. I'm only going to focus on 10GbE NIC designs as well as Cisco UCS. Let's be honest with ourselves, 10GbE is what everyone is moving to, and if you are implementing vCloud Director, it's probably going to be in a 10GbE environment anyway.

I've always considered that a good vCloud design is based on a good vSphere design, which still stands and holds true for the most part. In a few recent engagements I've been involved in, I've seen architects want to use 4 NICs for their vCloud Hosts… and here's why

When you are designing a vCloud environment, most people will tend to use VCDNI (vCloud Director Network Isolation… soon to be VXLAN) which involves a little bit more complexity when it comes to the design. During the deployment of a VCDNI network a new port group is created on the vNetwork Distributed Switch (vDS). This port group is automatically created by vCloud Director and therefore inherits the following features (which are strongly recommended to NEVER change):

• The default NIC behavior is to always choose dvUplink1 on the vSphere Distributed Switch
• dvUplink1 is set as the Active NIC while all other NICs attached to the vDS are set to Stand-by
• The port group is set as "route based on originating port id"
• The security settings are the original defaults with:
  • Promiscious Mode: Reject
  • MAC Address Changes: Accept
  • Forged Transmits: Accept

So what does this potentially mean for your design and NIC considerations? It usually means that the NIC assigned to dvUplink 1 will be constantly utilized. I honestly don't know if the VCDNI/VXLAN port groups will choose a different dvUplink other than dvUplink1, but in all of my testing only dvUplink1 has been chosen. You need to take this into account so these are a few designs I have created using 4x10GbE, 2x10GbE and 2x1GbE, and 2x10GbE with UCS.

While at a customer site this past week, I was confronted with a situation. But before I get to that, lets talk about vCenter and vCloud Design.

First thing is first, you should be vaguely familiar with vCloud Architecture Toolkit (vCAT). One important topic it discusses is the placement and use of vCenter when it comes to vCloud Director. It's a recommended practice to have 2 vCenter servers in a vCloud environment. Use 1 vCenter server for hosting Datacenters/Clusters/VMs that are relevant to vSphere and vCloud Infrastructure Components. Use another vCenter server for hosting vCloud Resources. Why's this?

1. Separation of management domains. It's important to know that vSphere and vCloud are different animals. Just because you are a vSphere admin, it doesn't make you a vCloud admin. By separating the two environments, you are letting vSphere admins access VMs that are outside the Cloud, and manage VMs that are considered vCloud Infrastructure.
2. vCenter becomes abstracted. ESXi abstracts the hardware layer, and vCenter is the central management point. vCloud Director abstracts the resources that belong to vCenter and present those to vCloud as Provider Virtual Datacenters.
3. Saves vSphere Admins from themselves. Have you've ever watched what happens when you add a vCenter server to vCloud Director? vCloud Director takes charge. It does it's own thing by creating folders, resource pools, port groups, appliances, etc. Everything that is created by vCloud has a set of characters that proceed it to become unique identifiers. If a vSphere admin has access to a Distributed Virtual Switch, and notices some random portgroup ending with HFE2342-FEF2123NJE-234, he is probably tempted to delete it. If a user goes crazy and starts deleting objects directly from vCenter without vCloud's knowledge, its havoc.
4. Relieve Stress on vCenter. As Duncan pointed out below in the comments, if a tenant of the cloud is issuing a bunch of requests, it could possible render the vCenter server unusable. By separating out the workload among 2 vCenter functions, you will not impact a vCenter server responsible for management functions.