Wednesday, September 13, 2017
Wednesday, October 28, 2015
One customer called Cisco and got this recommendation from the vendor:
- Setup multiple vNICs on UCS - one for each FI (A and B) for vMotion, one for Management and then one or more for other VLANs for maximum flexibility. If we then match the vNICs that are attached to FI-A together for vMotion into the same Distributed Switch, we can avoid Northbound (external switch) traffic. We can also perform QOS/Traffic shaping at the Cisco UCS level.
It makes sense that the hardware vendor would suggest a hardware solution that highlights and uses the capabilities of their platform.
However, I don't think this is the optimum solution.
I would just leave the vNICs at 2 - one per FI. And don't have them set for failover - because if a path fails, I want to see that failure at the vSphere level and not have it hidden from me. I will have the vNICs setup to handle failures already in vSphere, so I don't need it twice.
Then, just have more portgroups - one for Management, two for vMotion (one per FI/vNIC - so all vNICs that are tied to FI-A are together in one portgroup and all vNICs that are tied to FI-B are together in another portgroup), and then additional portgroups as needed for VMs.
Adding additional vNICs does not change the amount of bandwidth available or the number of physical connections coming out of a blade - it is limited to 1 connection to each FI....so the rest is semantics - adding portgroups is effectively the same as adding vNICs.
Plus, using the VMware method allows you to use a single pane of glass to control and manage all those features.
In reality, it really makes little difference whether you use vNICs or Portgroups - all that changes is the point at which you are separating the traffic. In the vNIC case, you are separating it before vSphere sees it....in the Portgroup case you are allow vSphere to handle the separation.
The decision comes down to whether your business prefers to control this from the hardware or software side. Plus, are the features you require available in UCS or vSphere? If you really want to use NIOC or other Distributed vSwitch features, then choose the vSphere method.
I would definitely not do both - don't enable QOS or Traffic Shaping at the vSphere level and then also do it at the UCS level. You are adding complexity without adding benefit. Plus diagnosing issues becomes much more difficult.
Thursday, July 31, 2014
Recently, I had a client that wanted to re-organize their ESXi servers. They wanted all the IP’s nicely lined up and the host names changed.
But they were also using a VDS. This was my solution.
The only way I know of to accomplish this is to remove the host from the cluster and re-add it. Because the host is part of a VDS, you have to remove it from the VDS first before you can remove it from the cluster.
I had previously setup the cluster to use Host Profiles – THIS IS IMPORTANT! It will save tons of time.
These steps are for the vSphere Client.
So…here are the steps:
- Put the host into maintenance mode.
- Host->Configuration->vSphere Distributed Switch->Manage Physical Adapters->Remove one adapter (you do have more than one right?!)
- vSphere Standard Switch->Add Networking->Virtual Machine Type->Click through to Finish (we are going to migrate the VMK port, so we don’t need a new one)
- vSphere Distributed Switch->Manage Virtual Adapters-><the vmk# port> –>Migrate->The vSwitch you just created->enter the right VLAN!
- vSphere Distributed Switch->Manage Physical Adapters->Remove other physical ports
- Home->Networking->DVSwitch->Hosts Tab->right-click the host in maintenance mode->Remove from vSphere Distributed Switch
- Hosts and Clusters->Right Click the host in maintenance mode->Remove
- Go to the KVM console of the host and change the IP and hostname
- Back to the vSphere client->Cluster->Add host
- Host->Attach Profile (Manage Profile)
- Host Profiles->Apply Profile
- Host Profiles->Check Compliance
- Exit Maintenance mode
That should do it!
Saturday, July 26, 2014
Tuesday, June 17, 2014
Friday, June 13, 2014
I really like the new VMware VSAN technology. However, I can only think of one real use case.
VMware VSAN is a way to turn the commodity hard disks that sit inside your ESXi servers into a distributed storage array. It requires at least 1 SSD drive in each server, which it uses to increase the performance of the array.
It also requires a minimum of 3 hosts. This is where I start having problems with the product.
I have installed vSphere in many SMB’s and also large enterprise customers.
The SMB’s will typically purchase vSphere Essentials or Essentials Plus – it is a perfect fit for them. Provides them with enough capacity while being inexpensive enough to provide good value.
However, in order to make VSAN work, you really need 4 hosts or maybe 5. I want N+2 redundancy for my clients, so I want to be able to take a host down (maintenance), and still be able to function. But then what if a host that is in production fails? So, I require that the system can handle a failure while a server is in maintenance.
For a SMB client with 3 servers, this isn’t going to work….VSAN will fail if it goes down to 1 server. But in a shared storage environment (and I sell a lot of the little EMC 3150 storage arrays), this would not be a problem.
And a SMB customer doesn’t want to purchase extra servers just so his VSAN can function – better to spend the money on a shared storage array that is dedicated for the purpose and has redundant service processors that handle failures, online updates etc.
For large enterprise customers, you just won’t be able to fit the storage requirements they have into servers. Many of these customers are purchasing blades (Cisco UCS is product that I install alot and love!) and you simply cannot fit a lot of storage inside these units. In fact, I am now recommending just booting from either a) Auto Deploy server, or B) USB sticks (or a combination of both using the Stateless Caching feature of the Auto Deploy server.
So…where do I see this technology being useful? In a VDI (Horizon View) deployment. I would still see the customer using a SAN, but it makes sense to store the Replica’s (copies of the Golden Master images) on the VSAN for close and fast access.
This is just my opinion – let me know what you think.
Thursday, October 24, 2013
As a VMware consultant, I am constantly using the VMware products. As most of you know, the vSphere Client or “Thick” is going away and we will be left with only the Web Client.
I have several problems with this.
I have heard other people say this, and many times it is just, “Well, I don’t like the web client” or “I’m not comfortable with it because it is not familiar”. I thought I would give some rather more concrete reasons.
The biggest problem is that it is going to make my job harder. What do I mean?
- First, screen real-estate. On the exact same laptop, the vSphere Client lets me see way more stuff. Look at these examples taken on the same laptop (my home lab):
On the vSphere Client screen, I can see stats, datastores, networks all on one pane. With the Web Client, I have to click to another screen to see either the datastores or the networks. Plus, the Web Client just feels more crowded – I believe the fonts are bigger and so everything takes up more room. And I couldn’t find any way to move the Tasks pane to the bottom like the vSphere Client – though you can hide it completely though to give your middle pane more room.
- Tasks take more clicks and are sometimes difficult to find. Lets take an example that I do all the time. I often have to setup a small installation consisting of 2-3 hosts and 1 EMC NAS (often a VNXe). The VNXe is typically hooked up via iSCSI, and I often have only 4 NIC’s in the machine. This means I now have little choice but to use 2 of the iSCSI NICs for vMotion as well. I find that the best way to do this is make a single vSwitch with 2 NICs for the iSCSI traffic, but then change the failover order of the individual NICs so that they have only one NIC per VMKernel port (which is a requirement in order to do iSCSI multipathing on VMware).
So assuming that the vSwitch was already created with 2 NICs……to configure this in the vSphere Client, click the host in question, then the Configuration tab, then Networking, then click the VMKernel port, then Edit, then NIC Teaming and finally check the Override switch failover order and move the other adapters down to Unused adapters…like this:
How about the Web Client? Well…it took me a long time to figure out how to do it, but I did finally find the way. Click the host in question, the click the Manage tab, then the Networking tab, then you would think that it is under the VMKernel Adapters, but its not, you have to click the Virtual Switches, and then scroll down till you find the VMKernel ports, then click the VMKernel port till the box is highlighted and then click the Edit link (the pencil), and then go to Teaming and Failover, check the Override box and adjust the adapters till only one is Active and the rest unused….like this:
So…for the vSphere Client, it was 7 clicks to get to the screen where I could make the NIC changes, and for the Web Client it was 8 clicks plus some scrolling. It may not seem like much, but if things are not logically laid out, then it makes it more difficult. Even during writing this article, I found myself looking around for the right spots again in the Web Client. To make matters worse, I am supposedly a VMware expert….I can’t imagine how daunting this must feel to someone that is new to VMware.
- The Web Client is slower – considerably slower. At everything. Slower to refresh, slower to draw, slower to respond to inputs.
- The Web Client crashes. The browser window just becomes unresponsive and the only thing you can do is close the browser, and start it back up and then login again. I am not saying that this is necessarily VMware’s fault – browser issues, Adobe issues, Addon’s that are enabled – but that isn’t the users (my fault) either. I almost never have the vSphere Client crash and ultimately I have to compare usefulness of products. The fact that VMware wants to use a Web Based client is their technology decision, it is THEIR fault that they have decided to allow themselves to have many more variables involved.
- I can’t find a way to pass username/password to the Web Client as I could with the vSphere Client. I am logging into lots of different systems and I use a program called mRemoteNG to handle all my connections. With the vSphere Client, I can safely store the username/password in mRemote and then just double click the link and voila!, I am logged in and connected to either a ESXi or vCenter server. No such luck with the Web Client. This means I have to go lookup the username/password for each client and take extra time to login.
On that note, Is there going to be a Web Client for ESXi? Once the vSphere Client is gone, how do I connect directly to a ESXi server to manage it if the vCenter server isn’t running?
All of these things add up to wasting my time. In my industry, my time IS my money. The more efficient I am with my time, the more money I make per hour.
If VMware had just made the Web Client with the same interface as the vSphere Client, I think I would have a lot less to complain about. It would still be familiar, I would know where to find things. But they decided to change things. I don’t mind change, but it is supposed to make my life easier, not harder.
And this change definitely makes my life harder – and that’s not a good thing.