Your Daily VMware quiz!

Essendon

Had this idea about a daily VMware quiz where I'd pose a question everyday and give the answer the next day. Feel free to reply with an answer or wait for me to give the answer. I'll start off with one question everyday and perhaps up the number of questions if this thing gains traction.

Please note that the questions

- will be of varying levels of difficulty
- can be about anything VMware make (vCenter/ESXi/vShield/vCOPS/Workstation...anything really)
- will be the True/False, fill in the blanks, multiple-choice and design scenario variety

More importantly, try to reply to the question and dont be afraid that you may give the wrong answer. Let's make this a good learning tool! Feel free to suggest ideas and improvements that can be made to this thread.

The answer to the question will be given right under the question. But the answer's been written in white. So hold your mouse's left button down and drag it up to reveal the answer.

Essendon

Question 1

You need to upgrade your vSphere infrastructure from v5 to v5.5. You have the following products in this infrastructure:

- 6 ESXi hosts
- vCenter
- VUM
- 77 VM's

In which order would you upgrade the various parts?

Answer:

vCenter
VUM
Then use VUM to perform an orchestrated upgrade of your hosts and then the VM's (VMware tools first, then the VM hardware)

stryder144

First...awesome thread.

Second...I start class on Wednesday, so I had to look this stuff up. Anything that puts your nose in the book is great.

Third...seeing that I looked it up, I will refrain from actually answering the question.

kj0

vCenter
Hosts
VMs
VUM.

(VUM was the one I wasn't too sure about)


Is this question due to my mistake last week? :P

stryder144

The Official Cert Guide (pg 32/33) lists them in the following order:

1. vCenter
2. VUM
3. ESXi
4. VMs

Is this accurate?

jibbajabba

stryder144 wrote: »

Is this accurate?

It is. Another source is the official upgrade sequence KM

http://kb.vmware.com/kb/2057795

VUM is a component of vCenter so it will be upgraded alongside vc and then you move down the chain.

stryder144

Interesting. Looking forward to tomorrow's question!

tomtom1

stryder144 wrote: »

The Official Cert Guide (pg 32/33) lists them in the following order:

1. vCenter
2. VUM
3. ESXi
4. VMs

Is this accurate?

Correct, always start with the vCenter. It's the core of your vSphere environment, so always, always, start with that one.

GSXRules

jibbajabba wrote: »

It is. Another source is the official upgrade sequence KM

VMware KB: Update sequence for vSphere 5.5 and its compatible VMware products

VUM is a component of vCenter so it will be upgraded alongside vc and then you move down the chain.

Assuming VUM is installed on the same server as vCenter.

scott28tt

GSXRules wrote: »

Assuming VUM is installed on the same server as vCenter.

An old VUM can't upgrade hosts or VMs to a newer version than itself, so it would still need to be VUM after vCenter wherever things are installed.

JasminLandry

Awesome thread! I'll be following this one for sure, even though I probably won't know much of the answers

jibbajabba

tomtom1 wrote: »

Correct, always start with the vCenter..

Not QUITE

Check my link above. vCloud and View Components are upgraded before vCenter ... Unless you got a good rollback plan

Dakinggamer87

Awesome thread!! Great way to practice my vKnowledge

Essendon

Glad you guys are finding this fun/useful. Remember the aim is to learn and help others learn so it's important to discuss why some things are wrong and others are correct.

Question 2 A company has you as their VMware Consultant to solve a few problems they've been having in their infrastructure. The problems are: 1. There was a HA event several days when a host in a cluster failed taking down a number of VM’s with it. But HA was not able to restart all VM’s on the remaining hosts. The HA config is:



Why do you think this happened and what can you do to ensure it doesn’t happen again.

Answer:

Due to admission control not being enabled there werent not enough resources reserved for failover. Specifically there was not enough memory to support the the virtual machines on the remaining hosts.

To avoid this admission control should be enabled to tolerate a host failure of at least 1 or specify 25% of resources (assuming 4 node cluster).

Additional physical resources (RAM) likely needed to added to enable VM operation under this constraint considering the scenarios current overcommitment. This is one of the scenarios I've seen where there's considerable VM sprawl. People keep requesting VM's, the admins keep provisioning them and when a failover event happens they wonder why VM's didnt restart. Admission Control should always be enabled unless this was just a test cluster.

2. The same company has another cluster at a remote site where you discover that the hosts are like this:



Identify issues with the above config if the cluster’s HA Admission Control Policy is set to “Host failures a cluster tolerates” = 1. What’s happening as a result of this and what can you do to fix those issues.

Answer:

When “Host failures a cluster tolerates” = 1 given the cluster will not allow VM power after a point where a node failure would overcommit memory/cpu resources if a single node were to fail.

The issue we have is one of our hosts has a much larger amount of memory then the others. (An "unbalanced cluster") VMware needs to calculate a slot size based on a largest common VM in the cluster based on reserved resources to determine the amount of resources needed if a node fails. If no resource reservations are made then it will attempt to use a baseline slot size which can result in very large VM's not "fitting" into one of the smaller nodes under a failover scenario.

To overcome this you can:

- Use percentage of reserved resources instead of host failures. (this is recommended because there's no slot mechanism operating and you control how much available compute you reserve for failover.)

- Separate similar hosts/VM's into their own cluster. Plan ahead, always buy hosts that have the same amount of compute resources available or put them in their own cluster. If company policy dictates you have only one cluster, then use the %age reserved policy because it does not suffer from the restrictive slot mechanism that "host failures a cluster tolerates" suffers from.

Moral of question 2: Right size your VM's and DO NOT reserve memory or CPU unless you absolutely have to. If you do, it's highly recommended you use %age reserved as your admission control policy. If you find yourself reserving too much, put those VM's in their own cluster (I realize there's a slight management overhead but your better off with resource usage and covered in case of a HA event.

Asif Dasl

First off, what a great thread!!

My guess, and it is a guess, is that because you disabled admission control there wasn't enough resources so you couldn't power on all of the VMs and as a result of disabling never received an error from the VMs that they could not be powered on - the solution is to enable admission control so that you get a warning.

My second guess is that the host on the left failed and there was not enough resources for all of the VMs to run on the hosts, the solution is to increase the RAM substantially on at least one of the other hosts. But preferably all the hosts would have the same configuration.

I am probably wrong somewhere here, but like you say it's a great learning tool/experience!

Bloogen

1. Due to admission control not being enabled there was not enough resources reserved for failover. Specifically there was not enough memory to support the the virtual machines on the remaining hosts.

To avoid this admission control should be enabled to tolerate a host failure of at least 1 or specify 25% of resources (assuming 4 node cluster).

Additional physical resources (RAM) likely need to added to enable VM operation under this constraint considering the scenarios current overcommitment.

2. When “Host failures a cluster tolerates” = 1 given the cluster will not allow VM power after a point where a node failure would overcommit memory/cpu resources if a single node were to fail.

The issue we have is one of our hosts has a much larger amount of memory then the others. (An "unbalanced cluster") VMware needs to calculate a slot size based on a largest common VM in the cluster based on reserved resources to determine the amount of resources needed if a node fails. If no resource reservations are made then it will attempt to use a baseline slot size which can result in very large VM's not "fitting" into one of the smaller nodes under a failover scenario.

To overcome this you can:
- Choose to use memory/CPU reservations so VMware can accurately calculate the slot side.
- You could separate similar hosts/VM's into their own cluster.
- Or you could use percentage of reserved resources instead of host failures.

Essendon

Great answer there Bloogen. I'll add a line or two to the answer under the question and copy the rest word for word.

tomtom1

Bloogen wrote: »

1. Due to admission control not being enabled there was not enough resources reserved for failover. Specifically there was not enough memory to support the the virtual machines on the remaining hosts.

To avoid this admission control should be enabled to tolerate a host failure of at least 1 or specify 25% of resources (assuming 4 node cluster).

Additional physical resources (RAM) likely need to added to enable VM operation under this constraint considering the scenarios current overcommitment.

2. When “Host failures a cluster tolerates” = 1 given the cluster will not allow VM power after a point where a node failure would overcommit memory/cpu resources if a single node were to fail.

The issue we have is one of our hosts has a much larger amount of memory then the others. (An "unbalanced cluster") VMware needs to calculate a slot size based on a largest common VM in the cluster based on reserved resources to determine the amount of resources needed if a node fails. If no resource reservations are made then it will attempt to use a baseline slot size which can result in very large VM's not "fitting" into one of the smaller nodes under a failover scenario.

To overcome this you can:
- Choose to use memory/CPU reservations so VMware can accurately calculate the slot side.
- You could separate similar hosts/VM's into their own cluster.
- Or you could use percentage of reserved resources instead of host failures.

Or, in addition to this, you could use the HA advanced settings, like das.slotMemInMB and das.slotCpuInMHz to define a (maximum) slot size.

Essendon

Asif Dasl wrote:

First off, what a great thread!!

My guess, and it is a guess, is that because you disabled admission control there wasn't enough resources so you couldn't power on all of the VMs and as a result of disabling never received an error from the VMs that they could not be powered on - the solution is to enable admission control so that you get a warning.

Admission Control is quite analogous to bouncers not letting too many people in a club. You dont want too many people that you cant serve or handle. So you dont want more VM's than you can successfully restart in case of host failure. With Admission Control enabled, you dont get a warning instead it prevents you from powering up more VM's than you can restart successfully when there's a HA event. Note that it lets you create a VM but doesnt let you power it on if that VM is going to violate availability constraints.

Asif Dasl wrote:

My second guess is that the host on the left failed and there was not enough resources for all of the VMs to run on the hosts, the solution is to increase the RAM substantially on at least one of the other hosts. But preferably all the hosts would have the same configuration.

Yep, preferably all hosts should have the same amount of compute resources. You see what happens is although the bigger host (the one with 192GB RAM) has more HA slots than others, HA effectively ignores it for the purposes of calculation of the number of slots. If the number of slots in all other hosts is 50 while the bigger host has 100, HA doesnt consider that host as it calculates on the basis of a worst case scenario. This results in wastage of resources on the larger host which could've had more VM's powered up on it but is restricted by the admission control policy. In this scenario, it's recommended you use the %age reserved policy instead.

Hope this makes sense!

Essendon

@tomtom1 - I'd be careful with that too! Thing is if there's a VM with say 32GB RAM reservation and you set the slot size to say a value too small, the VM will occupy multiple slots and DRS may need to move things around to fit that in and reduce resource fragmentation. I know it doesnt "affect" anything as such, just putting it out there.

Essendon

Question 3:

1. A company new to virtualization has hired you on as their go-to person for the project of virtualizing their environment. The first question they ask is if vCenter should be virtual or physical. Why would you would recommend a virtual vCenter, come up with atleast 5 solid reasons.

- Costs: Reduced costs. You do not need to purchase, and maintain another physical server or it's power and space requirements.

- Backups: More efficient vCenter backups using hypervisor based backup solutions.

- Availability: You can leverage vSphere HA (and / or DRS) to give the vCenter virtual itself an optimale place in the cluster, which you cannot do with physical hardware, as you are always bound to the hardware itself. You can also provide simpeler HA support, as with physical hardware, you need to look at something like vCenter heartbeat.

- Recoverability: You can use snapshots before performing big vCenter upgrades and rollback when the **** hits the fan, if needed.

- Eat your own dog food: If you're a virtualization admin, you don't want stuff like the Windows or Linux OS'ses installed directly on physical hardware

- With the virtual vCenter, you can also chose the VCSA which is a serious alternative for companies running mostly Linux with VMware, as they have more knowledgeable staff on Linux.

2. The company is concerned that putting vCenter in a cluster with DRS enabled may make it harder to find among all VM's if there's, say a power outage in the datacenter, and you need to power on vCenter before other VM's. How can you ensure you can find the vCenter VM in such a scenario (remember DRS is enabled in the cluster)?

You should create a VM to host DRS rule that dictates that a VM "should" run on a specific host. In addition the rule you create should be a host affinity rule to maybe 2-3 hosts instead of only 1 or you lose the availability benefits of a virtual vCenter Server. You shouldnt create a "must" rule because both HA and DRS will respect a "must" rule even if it means downtime for the VM. People usually use the "must" for things like licensing constraints (with licenses being tied to a specific host name or to a certain processor type)

tomtom1

Essendon wrote: »

Question 3:

1. A company new to virtualization has hired you on as their go-to person for the project of virtualizing their environment. The first question they ask is if vCenter should be virtual or physical. Why would you would recommend a virtual vCenter, come up with atleast 5 solid reasons.

2. The company is concerned that putting vCenter in a cluster with DRS enabled may make it harder to find among all VM's if there's, say a power outage in the datacenter, and you need to power on vCenter before other VM's. How can you ensure you can find the vCenter VM in such a scenario (remember DRS is enabled in the cluster)?

Question 1
A good fit for my recent DCD studies, for either a physical or virtual vCenter, each has it's own pro's and cons. Here goes, I'd love to hear more reasons though!

1) Availability: You can leverage vSphere HA (and / or DRS) to give the vCenter virtual itself an optimale place in the cluster, which you cannot do with physical hardware, as you are always bound to the hardware itself. You can also provide simpeler HA support, as with physical hardware, you need to look at something like vCenter heartbeat.

2) Recoverability: You can use snapshots before performing big vCenter upgrades and rollback when the **** hits the fan, if needed.

3) Eat your own dog food: If you're a virtualization admin, you don't want stuff like the Windows or Linux OS'ses installed directly on physical hardware

4) With the virtual vCenter, you can also chose the VCSA which is a serious alternative for companies running mostly Linux with VMware, as they have more knowledgeable staff on Linux.

5) Inspiration has run dry.

Question 2:

You should create a VM to host DRS rule that dictates that a VM should run on a specific host. The difference with must is that if you only select 1 host in your DRS host group, putting that host into maintenance mode and letting the VM's migrate automatically will not be possible.

tomtom1

Essendon wrote: »

@tomtom1 - I'd be careful with that too! Thing is if there's a VM with say 32GB RAM reservation and you set the slot size to say a value too small, the VM will occupy multiple slots and DRS may need to move things around to fit that in and reduce resource fragmentation. I know it doesnt "affect" anything as such, just putting it out there.

I know, but I'd be sparse with reservations in general. If there isn't a contention on the specific hosts, the scheduler should be able to give every VM the amount of compute that it needs, and in HA it messes up the slot size.. So if it isn't needed, I'd stay away

Essendon

@tomtom1 - I'd stay away from reservations too! All too often, I have people saying - Oh my VM is not performing optimally, I need its memory to be reserved. Bah! Why do you think you need a reservation. All too often it's over-spec'd VM's that are the culprit. Too many vCPU's and very few actually used and they then wonder why performance suffers. I quite surprises me that VMware admins and system managers alike struggle to understand the idea of vCPU's v/s pCPU's.

I've also seen such complainants usually have an SQL backend to their application. Sometimes the problem lies in the SQL machine, either with the VM's config or with SQL hogging all available RAM on the VM. I've found that a DRS "should" rule fixes half the problems so the application and the database are on the same host, all traffic is local and as fast as the internal bus on the ESXi host. Some may think this is putting your eggs in one basket, well it's not because the application without the database and the database without the application are both equally useless...

tomtom1

Essendon wrote: »

I quite surprises me that VMware admins and system managers alike struggle to understand the idea of vCPU's v/s pCPU's.

To be quite honest, I've had a few run ins with admins that didn't get these concepts too, but once you are able to explain the concepts en show them that they're killing their environments with stuff like CPU RDY (%) and CSTP values, the light bolt goes on

Really like this concept, if you could work in some things related to the DCD, might create some nice discussion, as there is no one size fits all. You clearly have the experience to do so.

Xyro

Great thread, not that I have much to add to it since I will not be beginning VMware until April. It makes me look forward to these studies even more though!

Actually it makes me want to start them now.

Essendon

@tomtom1 - and some still dont care! What's more baffling is the way "Architects" that sell solutions to customers, they just go - we have a catalogue of super-heavy VM's (8 vCPU's, 32GB RAM), heavy VM's (4 vCPU's, 16 GB RAM) and light VM's (2 x vCPU's, 8 GB RAM) and tell the customer that they can choose their VM's. Customers being what they are, want the greatest thing available (even if it's at a premium) and just say we'll have 10 of the super-heavy variety and 30 of the heavy variety and 5 of the light kind, thanks!. It's almost as if they are buying firecrackers!

A request came in the other day to me build a super-heavy VM for a 30 user environment (all heavy and above need admin approval). The VM was going to be a Domain Controller!!! I almost spilled my coffee on the keyboard and a good long firm discussion with some people so they stop selling VM's like that.

Really glad that everyone's finding this useful. Even if you think you dont have anything to add, mere reading of such things is sure to be helpful in the future (at work and in your studies).

tomtom1

One word: LOL.

Bloogen

I will add to what tomtom1 has done a good job of answering already.

Question 1
1) Less costs. You do not need to purchase, and maintain another physical server or it's power and space requirements.

2) More efficient vCenter backups using hypervisor based backup solutions.

Question 2:
I will add that you should create a host affinity rule to maybe 2-3 hosts instead of only 1 or you lose the availability benefits of a virtual vCenter Server.

Essendon

Great answers guys! See under the question for my reply.

Essendon

Question 4 - true/false variety. If an answer is true, tell me why it's true. If the answer is false, again tell me why, right?!

- The maximum RAM for a vSphere 5.5 VM is 2 TB. True/False? False

- If an admin were to upgrade a VMFS 3 datastore to a VMFS 5 datastore, the block size of the datastore changes to 1 MB. True/False? False

- ESXi stands for Elastic Sky X integrated. True/False? (I know this is a trivia question!) True

- A customer has purchased ESXi Foundations and is thinking of using host profiles for ease of management. Host profiles will be available to them. True/False? False

- The "host-only" Networking setting in VMware Workstation will allow VM's to get out to the Internet. True/False? False

- vCenter 5.5 can manage ESXi 5.x hosts. True/False? True

- Changing the network label of a VM from "ProdVMs" to "FinanceVMs" will not cause a slight outage to the VM. True/False? False

- You can vMotion across clusters if the networking is setup correctly. True/False? True

- You like this quiz!. True/False?

You guys have done a great job of answering this set of questions, so I wont steal your thunder and copy your responses in here. Everyone else, please see tomtom1's, Asif and kj0's replies.