Become a vExpert!

February 28th, 2012 Posted in Virtualization
5 Comments »

So today FedEx made be very happy. I received a package with some great vExpert goodies (messenger bag, travel tag and the awesome certificate). Thank you John, Alex and the rest of the awesome folks at VMware who helped send this over to my doorstep.

Now I know most of you must be saying so what’s the big deal? Well it is a big freaking deal. Because that not all you get. Over the course of the year you are spoiled completely with things like:

  • License of all kinds (vSphere, View, vShield, vCloud SRM etc)
  • Access to Beta programs (imagine running vSphere 5 before it got released, seeing vCOM in action)
  • Access to new solutions that are in the making
  • Access to some secrets that could put your life at risk (ok just kidding, but some good pre-release info etc)
  • Conferences of all kind..
  • Access to an awesome vExpert community (remember being surrounded by smart people is an awesome thing)
  • Opportunity to speak with people who love to hear your feedback which means you could in fact have an influence on some next major solution/release
  • Cool corner at VMworld/PEX for you to hangout with the gurus
  • And a few more things that I don’t think I am allowed to talk about (just to be clear, it’s all good)

Basically its everything that I mentioned and a whole lot more, in theory you will not be able to consume all that is offered because if you do so your spouse will begin to hate you and your kids will forget your face. So there, if you ever wanted to get a deep dive and an opportunity to make a difference, here is your chance. Not to mention you also get to be called a vExpert which is pretty awesome as well. But in all seriousness it’s more about having the opportunity to enhance your skills and introduce yourself to all kinds solutions that you didn’t even know existed. See how the industry is changing and how you can position your organization so that you look like a rockstar every single day. IT is all about learning till the last day, and with the vExpert program the learning never ends.

Enough said, so how exactly do you become a vExpert? You will have to go on a 1000 mile run followed by some rock climbing, grab the bucket of water from the top the mountain and bring it down without spilling anything on a bike that’s lit on fire.. ok seriously it’s very simple and straight forward. And trust me the application process has become even simpler (no, I am not saying anyone will get accepted, you just don’t have to fill out a bunch of stuff like one had to in the past). The standards are still high, if you are deserving, the panel will see it and you will make it.

What is the vExpert program and what’s the criteria to become one?

to honour individuals who go above and beyond their everyday job requirements to share their technical knowledge and expertise with others; to help enable these individuals to make an even greater impact in the world; and to keep a high standard of vExpert recipients

If  you think that you fit the bill, go to the address here vmware.com/go/vexpert2012  and see what path you qualify for and apply. Hurry up, the applications are only open until March 15th 2012. Sometime’s the hardest part is taking the first step :)

Edit: After receiving some comments on Twitter, I just want to clarify something, the stuff I got was for last year. The vExperts 2012 are not announced yet and you can still apply until March 15th 2012. Obviously vExperts 2012 will not be announced until some time after March 15th.

Read More

HA Admission control – Percentage of cluster resources

February 28th, 2012 Posted in Virtualization
15 Comments »

I am sure we are all aware of why HA is all important and awesome to have. It helps you to finish your coffee, smoke your cigarette before rushing towards a server that just went down. Ok maybe not that but you get the idea right. Another thing to keep in mind regarding HA is the admission control policy. I like to call this the policy that saves you from yourself. Basically it keeps check of how many resources are available and how many will be needed for a failover to happen. It keeps you honest and ensures that the HA’s promise is not broken.

As we already know there are three types of Admission Control Policies to choose from:

  • Host failures cluster  tolerates
  • Percentage of cluster resources reserved as failover spare capacity
  • Specify a failover host
“Host failure cluster tolerates” creates slots which at times could create issues specially if you only have a a few VMs with High CPU counts and memory reservation. Of course you can look at advanced settings that could address this and Duncan can tell you all there is to know about this. The second option which is selecting a percentage of resources is my personal favorite specially due to the flexibility that it provides. We will go over that in a little bit. The last option which lets you specify a failover host is the one thats rarely used and rightly so. After all why would you want a host to just sit there and wait until something goes wrong?
As you may have already noticed, vSphere 5 gives you the option to specify a percentage of failover resources for both CPU and memory. Prior to vSphere 5, this was not the case. I think this is an excellent addition and our clusters will now be more flexible then ever.

25% is whats placed in there by default and what this really means is the 25% of your total CPU and total memory resource across the entire cluster is reserved for your cluster. So in other words, if you have an 8 node cluster, 25% of your resources or resources equal to two host (assuming its a balanced cluster) are reserved for an HA incident. If this happens to be a 32 node cluster and if this is a balanced cluster, resources that equate to 8 nodes will be reserved as 8 is 25% of 32. So keep that in mind before deciding what number to put there. You can’t reserve more than 50% of your resources.

Below is how the resources are calculated for the hosts:

The total host resources available for virtual machines is calculated by adding the hosts’ CPU and memory resources. These amounts are those contained in the host’s root resource pool, not the total physical resources of the host. Resources being used for virtualization purposes are not included. Only hosts that are connected, not in maintenance mode, and have no vSphere HA errors are considered.

So how do you know how much head room do yo have left in the cluster? On your cluster summary tab, you will notice there is no longer a place for you to look at slot size as this method does not use slot sizes. It basically gives you a simple view of how much room you have left.

The Current CPU Failover Capacity is computed by subtracting the total CPU resource requirements from the total host CPU resources and dividing the result by the total host CPU resources. The Current Memory Failover Capacity is calculated similarly.

In vSphere 5, vSphere HA uses the actual reservations of the virtual machines. If a virtual machine does not have reservations, meaning that the reservation is 0, a default of 0MB memory and 32MHz CPU is applied.

So assuming you went with the default of 25% for each resource, 0% as current failover capacity is something you should hope never to see. You are seeing that in my screenshot (above) because my cluster happens to be empty and has no hosts. Lets, say you went ahead and turned on a few VMs and your cluster shows something like below, (98% CPU and 95% memory), this is something to be happy about. This basically means you have 98% of CPU available and 95% of memory available in your cluster.

There is one thing to keep in mind, though 98% of my CPU and 95% of my memory appear under my current failover capacity, this does not account for the 25% of whats reserved for an HA incident. At least thats what I was able to see by the few tests that I ran. What this means is that I can only power on VMs that account for no more than 98-25 = 73% of CPU and 95-25=70% of memory thats free in the cluster. For everything else HA should try to save me from myself.

Let’s look at a quick example to see how these numbers are calculated:

  • The Configured Failover Capacity is set to 25% for both CPU and memory.
  • Cluster is comprised of three hosts, each with 9GHz and 24GB of memory.
  • There are 4 powered-on virtual machines in the cluster with the following configs (assume overhead is 100mb for all VMs in this case):
    • VM1 needs 2GHz and 1GB (no reservation)
    • VM2 needs 2GHz and 2GB (2GB reserved)
    • VM3 needs 1GHz and 2GB (2GB reserved)
    • VM4 needs 3GHz and 6GB (1GHz and 2GB reserved)

So what does our cluster have? Our cluster has 9GHz+9GHz+9GHz = 27GHz of CPU and 24GB+24GB+24Gb=72GB of memory. (These amounts are those contained in the host’s root resource pool, not the total physical resources of the host).

How much resources are we using with our four VMs that are powered on?

Memory = VM reservation + overhead = 0+100+2048+100+2048+100+2048+100= 6544MB = 6.4GB

Note we only used 2048 for VM4 even though it had 6GB configured. Thats because it only had 2GB reserved. Also, VM1 had no reservation so only overhead was used.

CPU = If no reservation use 32MHz for vSphere 5 = 32MHz+32MHz+32MHz+1GHz= 1.096GHz

So what is our current failover capacity?

Memory = (72GB – 6.4Gb)/72= 91%

CPU = (27GHz-1.096GHz)/27= 95.94%=96%

Wow, that is a lot of cluster resources left. Now lets take 25% off from our numbers to come up with exactly how many VMs can we power on before HA starts screaming back with an error.

Memory = 91- 25 = 66%

CPU = 96-25 = 71%

Now keep in mind, selecting the percentage for admission control policy isn’t going to solve all your problems. But I do think that this setting is far better than complex slot sizes and what not. This gives one a simple view of how much room you have in your cluster without messing around with slot sizes. However, unlike cluster host tolerates setting where you can simply add hosts like crazy, using the percentage method may require you to revisit your percentages as you add or remove hosts. At the same time it also gives you more flexibility. So next time you are setting a cluster, think about whats important to you.

 

, , , ,
Read More

Restricting Domain Admins from vCenter

February 21st, 2012 Posted in Virtualization
5 Comments »

This morning I was talking to a friend who asked me how can he restrict the domain admins in his domain from having Admin access in vCenter. This is a very typical concern usually in bigger environments where roles are distributed. This might be common knowledge for some of us but for those who don’t know this yet, read on.

When you setup vCenter on windows (notice I said windows because we also have vCSA now), by default the local administrators group is given Admin access in vCenter. You can see this in the “Permissions” tab in vCenter.

Obviously this also means that the “Domain Admins” also have Administrator access in vCenter. Why? Because Domain Admins are also part of the local administrators group. So what can you do?

  1. Create a security group in AD and call it something that makes sense
  2. Add the appropriate parties to this group (at least add yourself)
  3. Log into the vCenter server as an Administrator and create a local group on this server with an appropriate name
  4. Add the group we created in step 1 to the local group we just created
  5. Also add the local Administrator account to this local group (why?, in case your AD goes kaboooom!!)
  6. Log into the vCenter using the vi client
  7. Go to the very top of the tree and click on the permissions tab
  8. Add the local group we just created
    • Right click on the empty space
    • Click “Add Permissions”
    • Click “Add” on the next screen
    • Make sure that you have selected “server” from the drop down menu in the domain section (not your domain)

    • Find the local group we just created and highlight it. Click “Add”
    • Click “Ok”
    • On the next screen, make sure you select “Administrator” from the drop down and ensure that “Propagate to Child Objects” is checked

    • Hit “Ok”

Now all users that are part of the local group (step 3) and the AD group (step 1), should have admin access to the vCenter.

But wait, your domain admins still have access. Right click on the “Administrators” group under the permissions tab and click “Delete”.

But before you do this last step, please please please make sure that access from the other groups we created is working as expected and you do have Admin rights on the vCenter via that group, create a test account or something but make sure that works. Once you have confirmed that, remove the Administrators group and you should be all set. Now your Domain Admins are still administrators on the vCenter server but they are not vCenter Admins, of course they can change this if they want to, but hey we can only do so much. It may not be a bad idea to give your Domain Admin’s read only rights, this usually keeps them from getting annoyed and who knows they may never realize that they only have read only access.

Again, make sure your access works before you remove the Administrators group from vCenter, or else you may have an extremely secure environment where no one is an Admin :D

, ,
Read More

vCSA and host files

February 17th, 2012 Posted in Virtualization
No Comments

I am all for using DNS for name resolutions and host file entries could very easily become a management nightmare specially when it’s not documented. However, I do understand that at times there may be a reason for one to add a host file entry for testing purposes or perhaps your communication line with your DNS has been cut off. Don’t ask me why but crazy stuff happens.

So if you are working with the vCenter Server Appliance(vCSA) and have to enter your hosts in the host file of the vCSA so that appliance can resolve your hosts properly, this is what you do.

  • Either SSH or get to the console of vCSA
  • Once you are at the command prompt, type “vi /etc/hosts” (you could use a different editor, I prefer vi)
  • Add your hosts in the following format: <ip_address> <hostname>
  • Save the file and vCSA should now be able to resolve the hosts with their hostnames

Again, DNS is obviously the way to get this done. This is just a work around and if you decide to do this, please document or have a very sharp memory.

 

 

, ,
Read More

vCloud client for iPad

February 14th, 2012 Posted in Virtualization
No Comments

After the vSphere and View client, VMware has now made the vCloud client available for the iPad. You can download the client from the App store and start managing your vCD environment using your tablet. Of course it’s a free app like the previous ones. You can manage your existing vApps and the VMs associated with those vApps, deploy new vApps, check their status and even share that info via email all from your iPad. There are more details and  a nice video here. For everyone else, best way to learn it is to spin it up and try it for yourself. Of course you need an existing vCD instance that you will need to connect to. Have fun!!

, ,
Read More

VNC and vSphere 5 for Mac users

February 14th, 2012 Posted in Virtualization
2 Comments »

The other day I was testing out the vSphere web client and posted about some of the challenges fot the unfortunate mac users. Sveeny took the time to comment on the post a work around which has been secretly used by many vSphere outlaws for years. I mentioned the lack of ability to install the client integration plug-in on OS X which pretty much keeps you from not only accessing the VMs console but also disallowing connecting any virtual devices connected on the client machine.

Sveeny mentioned that one can use VNC for this and he is right, he said:

A little workaround for the console issue. You can enable vnc for every vm.
First you have to enable VNC on the firewall.
then you have to set the following parameters in the vm advanced config:
RemoteDisplay.vnc.enabled:true
RemoteDisplay.vnc.port: 5900 (for every vm on a host a different from 5900-5999)
RemoteDisplay.vnc.password:

Open finder press +k and enter vnc://esxhost:5900

Here are some detailed info on setting this up.

However there a few things I wanted to point out that doesn’t make me a fan of this approach.

To start, the connection is made by using the hostname/IP of the host the VM is running on followed by the port that was assigned to the VM. This means on your DRS enabled cluster, your VNC connection may not be the same all the time as the VMs will move around. This will probably not be a good idea for large clusters where DRS can have more fun. Not to mention with DPM turned on this can be even more fun.

I am sure a lot of complaining and crying went around before the firewall finally showed up in ESXi. Going back and opening up ports for VNC is perhaps less secure than leaving it closed. Yes, the firewall on each host will have to be configured to allow VNC connections to that hosts.

I also see this as an added overhead. Not in terms of computing resources as much as in man hours and actual $. Why? Remember each VM in your environment that you want to connect via VNC will have to be configured appropriately. Each .vmx will have to be updated for this to work. Also, I am unsure about how well connecting virtual devices from client machines work with VNC.

And finally I have been unable to confirm if connection via VNC is supported. From what I understand, this is an unsupported setup.

Overall, this is not a bad work around if you are desperately in need for access to the console and are running an OS/browser that does not support the client integration plug-in for the web client. But my preference and recommendation will be to hope and cry for client integration plug-in to work on the OS X at the least. And obviously Chrome, after all its one of the most popular browser. Knowing the web client is still fairly new, I am sure all these capabilities will come in with time, this is just my way of crying and saying “VMware, please hurry up”.

, ,
Read More
Older Entries