Your Daily VMware quiz!

dave330i

Q. 44 - Upgrade to 5.5.

Essendon

LOL, nice one Dave!

Essendon

-- Troubleshooting scenario --

Q 45

You are the Virtualization Consultant at your company and have been delegated the responsibility of fixing some issues a customer’s having. The issues:

- Random slowness throughout the day. Slowness is more pronounced in the evening, about 8pm is when it’s at its worst.
- Some SQL jobs time-out.
- Host failure happened the other day, all machines on affected host did not power up on other hosts.

The environment:

- HP Blade environment, 2 x 10GbE backplanes, single chassis
- 5 x ESXi 2-way 4 core 5.0 hosts in 1 cluster, HT not enabled, HA enabled, DRS not enabled, no datastore clusters, 192GB RAM on each blade
- LUN’s have varying number of machines on them.
- There’s considerable variation in the config of the VM’s:

o 40 x VM’s with 1 vCPU and 4 GB RAM
o 20 x VM’s with 2 vCPU’s and 8 GB RAM
o 20 x VM’s with 4 vCPU’s and 12 GB RAM
o 5 x VM’s with 8 vCPU’s and 32 GB RAM, these are running SQL workloads

How/what/where would you start troubleshooting this situation? Ask me questions you have, say you want to know what kind of array the customer’s running, number of LUN’s – basically, ask me questions which would help you arrive at a solution for the customer. Issues described at the top have been left vague/unclear deliberately.

J.Tot

Q44 Multiple Answers :

1. Use RDM and present the larger disks directly to the VM
2. Use Guest OS iSCSI Initiator and connect directly to the LUN
3. Add multiple 2TB vmdk's to the OS, stripe within the OS

Essendon

Yep, you are right J. Tot - I forgot to mention that the manager wanted the VM's in an MSCS cluster. So without considering the MSCS cluster, your answers are correct. If you consider the cluster, then my answer's correct. Thanks for your input.

kj0

Essendon wrote: »

-- Troubleshooting scenario --

Q 45

You are the Virtualization Consultant at your company and have been delegated the responsibility of fixing some issues a customer’s having. The issues:

- Random slowness throughout the day. Slowness is more pronounced in the evening, about 8pm is when it’s at its worst.
- Some SQL jobs time-out.
- Host failure happened the other day, all machines on affected host did not power up on other hosts.

The environment:

- HP Blade environment, 2 x 10GbE backplanes, single chassis
- 5 x ESXi 2-way 4 core 5.0 hosts in 1 cluster, HT not enabled, HA enabled, DRS not enabled, no datastore clusters, 192GB RAM (Total=768GB) on each blade
- LUN’s have varying number of machines on them.
- There’s considerable variation in the config of the VM’s:

o 40 x VM’s with 1 vCPU (T=40) and 4 GB RAM (Total=160GB)
o 20 x VM’s with 2 vCPU’s (T=40) and 8 GB RAM (Total=160GB)
o 20 x VM’s with 4 vCPU’s (T=80) and 12 GB RAM (Total=240GB)
o 5 x VM’s with 8 vCPU’s (T=40) and 32 GB RAM (Total=160GB), these are running SQL workloads

How/what/where would you start troubleshooting this situation? Ask me questions you have, say you want to know what kind of array the customer’s running, number of LUN’s – basically, ask me questions which would help you arrive at a solution for the customer. Issues described at the top have been left vague/unclear deliberately.

I've done up the totals and added them in. For the VMs not restarting with HA, could be Admission Control most likely not satisfied with the resources available. Is each lot of VMs sitting on that particular host or are they all mixed across the 5 hosts?

During the day, resource contention is most likely taking place, however, with Back ups (Not mentioned in this thread, but the question was asked) running, they would be taking a hit on performance which is more than likely occurring during the evening. Can you please verify the time Backups occur.

How many disks and what type (speed) and configuration are they in?

QHalo

Essendon wrote: »

Great points guys, another thing you could check is if the disk holding the database/logs has enough space. And if your vCenter is virtual, then you logon directly to the host, locate the vCenter VM and extend the disk. If you have a number of hosts, then "pin" vCenter to a host by disabling DRS for the VM holding vCenter.

To pin you don't have to disable DRS technically. You can create a 'Should run on' rule for that VM so you know where it will be. That rule will also allow you to put the host in maintenance mode without user intervention by disabling completely.

Deathmage

I have to say guys I'm up to page 5 but these questions are awesome, learning a little bit more each time I read onward. So many things about vApps and Resource pools that I wouldn't have thought about!

Will defiantly finish reading this before the exam on Wednesday, and the flashcards over @ Cards: the exam - vcp5 | Quizlet

Keep them coming, I like reading these, heck maybe even I'll take a crack at them.

Deathmage

jibbajabba wrote: »

We use Thin on Thin ... I don't know who made that decision .. I am the guy who supposed to support the infrastructure but I was on holiday when it was implemented. Anyway, I don't like Thin on Thin simply because I have seen customers out of a sudden using a heck of a lot more storage than anticipated. If your pool on the SAN runs low there is usually not much you can do to fix it unless you buy another shelf.

So yes, alerting / monitoring is very important (and staff not ignoring the mails for weeks *sigh*). As for thin provisioned LUNs. We use 4TB LUNs (again, for no real reason I don't think) and I personally think it is pointless to have thin provisioned LUNs at that size given the average VM size in our environment (we got 250GB - 1TB VMs) ... In cases like that I would either

a. Use 4TB LUNs - Thick provisioned VMDKs
b. Use larger LUNs - Thin provisioned VMDKs

and in both cases Thick LUNs

Simply I like to know where I am at with the storage. The problem I think is the business in most cases. Buy small, sell big, hope it works out

I was "Beta Testing" Dell Equallogics years back and I managed to make the Dell guy speechless. He was all over the Thin on Thin thing. So we received an early model (pre Production 4000 Series it was I think) so he left it with us (not leaving our office for the day obviously) and let me play with it. Took me 15 minutes to "blow it up".

I left the setup as is - at that point 500GB LUNs thin on thin .. so we had 10 VMs or so .. So I kicked off some clones ... some snapshots, some removals, some more clones, some uploads and deployed some OVFs.

I "overrun" the system to a point where the alerting was somewhat overrun and the whole thing locked up lol ..

Needless to say the Dell guy lost the colour of his face ... Was not recoverable ..

Ok, it was a pre-release model and it was probably unlikely to happen in production anyway. My point is, you rely very heavily on proper alerting when using thin on thin and in my experience, even thin on thick, caused problems eventually.

I would LOVE to hear from an architect about environments implemented where either implementation made perfect sense. VCDX anyone ?



By the way - speaking of thin provision and storage vmotion - depending on your SAN you may see that you have to keep reclaiming space using VAAI because of all those svmotions ...

So I follow this discussion, sorry little late to the game.....

But thin on thin or thin on thick basically is the VM VMDK's or VM folders or I guess datastores inside of vCenter are thin provisioned with the physical storage layer (on the SAN/NAS) is thin provisioned meaning dynamically used when needed.

So in reversal, thin on thick means the VMDK's are stored on datastores than are thin provisioned but the physical lun on the SAN/NAS is thick provisioned?

Basically is left to right, the VMDK's provisoing format built onto the datastore format?

Am I following this correctly?

tomtom1 wrote: »

I know, but he never finished it, so that's a real shame.

@jibbajabba: This was the table I mentioned, found it on joshodgers website.


So we should be good with a percentage of 13% percent, seeing as in his opinion N+2 becomes relevant at the 9th host.

What does N stand for?

Red_Dragon

N Stands for Nintendo.

No but seriously, N stands for Components.

Deathmage

Hmmm.... really components? - Maybe I miss that equation in my studies.....

Anyways I just read threw all of the questions and I'm honestly wondering if those questions are just super hard or if I'm not studying enough for the VCP, like pages 1 to 6 were so hard I was scratching my head half the time. I tried really hard to work through them without looking at the answers.

The last few pages I was able to troubleshoot fine.

If these questions are meant for someone with a DCD then I can shed a sigh of relief, If not I'm going to do more reading or cancel my exam on Wednesday, maybe 4 months of study isn't enough, eek!

dave330i

Deathmage wrote: »

If these questions are meant for someone with a DCD then I can shed a sigh of relief, If not I'm going to do more reading or cancel my exam on Wednesday, maybe 4 months of study isn't enough, eek!

I remember many of the questions in this thread being above VCP.

Edit: in the table you posted, N is for the number of ESXi hosts in the cluster that'll provide resources. In a HA cluster with admission control enabled, the basic formula is N (# of host providing resources) + x (# of redundant hosts) = total # of ESXi hosts in the cluster.

Deathmage

dave330i wrote: »

I remember many of the questions in this thread being above VCP.

Edit: in the table you posted, N is for the number of ESXi hosts in the cluster that'll provide resources. In a HA cluster with admission control enabled, the basic formula is N (# of host providing resources) + x (# of redundant hosts) = total # of ESXi hosts in the cluster.

So I follow, if you have a 3 host cluster with one has a HA spare in-case the 1st two go off then it would be a N+1 (2+1)?

Essendon

I dont quite follow you, think of it as this - the 'x' stands for the number of hosts you can sustain the loss of and continue to run your workloads on the remaining ones. So with N + 1, you can sustain the loss of 1 host and run all your VMs, with N + 2, two hosts can be lost (or not unavailable, think maintenance mode) and other hosts still handle your VMs. Better?

Deathmage

Essendon wrote: »

I dont quite follow you, think of it as this - the 'x' stands for the number of hosts you can sustain the loss of and continue to run your workloads on the remaining ones. So with N + 1, you can sustain the loss of 1 host and run all your VMs, with N + 2, two hosts can be lost (or not unavailable, think maintenance mode) and other hosts still handle your VMs. Better?

Yes sir, I'm learning disabled so I take a little longer to learn than others but it's funny my IQ is 129, never understood it myself why I take so much longer than others to learn if my IQ is so high.

Deathmage

Not sure if I can post in here a question that I just found on a practice test that I had difficulty on in the exam:

vCenter reports a connectivity problem with a ESXi 5.x host that is not a member of a cluster. An Administrator attempts to connect directly to the host using vSphere Client but fails with the message "an unknown connection error occurred. Virtual machines running on the host appear to be running and report no problems.

What two methods would likely resolve the issue without affecting the VM's?

To me I think it's: (underlined is my choice)

1) Enter the service mgmt-vmware restart command from either SSH or local CLI

2) Enter the services.sh restart command from either SSH or local CLI

3) Select reboot host in the DCUI

4) Select Reboot Management Agents in the DCUI

did I royal screw that up?

Essendon

I may just go with 2 and 4, option 1 may reboot VMs under some particular conditions (I think)

Deathmage

Essendon wrote: »

I may just go with 2 and 4, option 1 may reboot VMs under some particular conditions (I think)

The answer is 2 and 4, but thanks for pointing out why the 1st is a bad one! - probably why I got the question wrong. See I did nothing in a command-line for my studying nor do I even know how to get to command line (half the problem, lol)

dave330i

Definitely 4. Probably 2.

Deathmage

this might be helpful for my study but how do I access the DCUI? - I only know it from reading. after taking the practice exams I see I had gaps in my studying.

Would it be as simple as making a SSH connection via putty to the esxi host (or can it happen to the vcenter applicance) and typing 'dcui' in the linux command prompt?

nevermind I'm a ar tard, the DCUI is the bloody yellow and black screen on the esxi host (hides in corner)

well that's something I learned, option 1 doesn't even work in CLI.

tstrip007

Yah that happened to me yesterday after I patched a host. About 20 min after I had powered back on VM's the host went non responsive and vm's showed disconnected. Couldn't access the host directly through the client. However, all VM's were fully functioning and accessible via RDP. Restarted mgt agents. I have iLO configed on most of my servers and use that to access the DCUI.

Verities

Deathmage wrote: »

Not sure if I can post in here a question that I just found on a practice test that I had difficulty on in the exam:

vCenter reports a connectivity problem with a ESXi 5.x host that is not a member of a cluster. An Administrator attempts to connect directly to the host using vSphere Client but fails with the message "an unknown connection error occurred. Virtual machines running on the host appear to be running and report no problems.

What two methods would likely resolve the issue without affecting the VM's?

To me I think it's: (underlined is my choice)

1) Enter the service mgmt-vmware restart command from either SSH or local CLI

2) Enter the services.sh restart command from either SSH or local CLI

3) Select reboot host in the DCUI

4) Select Reboot Management Agents in the DCUI

did I royal screw that up?

I actually ran into this issue earlier this year, in our environment with a 4.1 host. I restarted the management agents via SSH and everything went smooth (if you don't have SSH enabled on the host, you can use PowerCLI to turn it on). You won't cause any issues on your VMs (unless you're running them with Automatic Startup/Automatic Shutdown) only your host if its running a specific task. I think I followed the KB 1003490 (article ID) but it was a while ago, so I don't particularly remember.

Deathmage

tstrip007 wrote: »

Yah that happened to me yesterday after I patched a host. About 20 min after I had powered back on VM's the host went non responsive and vm's showed disconnected. Couldn't access the host directly through the client. However, all VM's were fully functioning and accessible via RDP. Restarted mgt agents. I have iLO configed on most of my servers and use that to access the DCUI.

See my only issue is this, maybe it's a design flaw in my home cluster but I only have a single uplink for the management VMkernel while my vMotion/Production/vStorage both are two uplinks in a failover policy. It's no so much I don't have the connections I just was lazy, lol, I have 8 nic's per host (Broadcom 4 slot nic riser card) but needless to say before when I tried to restart the Management Agents the process happened but then my SSH console locked up and I couldn't gain access to the host but I could ping the IP from my laptop/PC it just wouldn't allow a SSH. I had to drop the host to fix it... However I'm curious if you guys know roughly how long it takes for the Management Agents to restart? ...I'm thinking I jumped the gun thinking it would happen fast...

as for SSH I just enabled mine from the Security pane in on the hosys inside of vCenter but of course you can do it directly from the client into the host and from the DCUI. However if you don't have a KVM with a monitor connected to the server (like me) it can be fun to wiggle behind my rack to hook up a vga to my KVM

I'm pondering if even if it's a test cluster if I should make a vlan for iDRAC just in-case of this situation...but I'm just not sure if I even have a iDRAC configured if I could access the DCUI from iDRAC so kind of scratching my head at this point...

Verities wrote: »

I actually ran into this issue earlier this year, in our environment with a 4.1 host. I restarted the management agents via SSH and everything went smooth (if you don't have SSH enabled on the host, you can use PowerCLI to turn it on). You won't cause any issues on your VMs (unless you're running them with Automatic Startup/Automatic Shutdown) only your host if its running a specific task. I think I followed the KB 1003490 (article ID) but it was a while ago, so I don't particularly remember.

hmm... now to figure out why the restarting on the management agents didn't go smooth for me, lol! - I always get the issues, lol!!!!

Verities

Deathmage wrote: »

See my only issue is this, maybe it's a design flaw in my home cluster but I only have a single uplink for the management VMkernel while my vMotion/Production/vStorage both are two uplinks in a failover policy. It's no so much I don't have the connections I just was lazy, lol, I have 8 nic's per host (Broadcom 4 slot nic riser card) but needless to say before when I tried to restart the Management Agents the process happened but then my SSH console locked up and I couldn't gain access to the host but I could ping the IP from my laptop/PC it just wouldn't allow a SSH. I had to drop the host to fix it... However I'm curious if you guys know roughly how long it takes for the Management Agents to restart? ...I'm thinking I jumped the gun thinking it would happen fast...

I'm pondering if even if it's a test cluster if I should make a vlan for iDRAC just in-case of this situation...but I'm just not sure if I even have a iDRAC configured if I could access the DCUI from iDRAC so kind of scratching my head at this point...



hmm... now to figure out why the restarting on the management agents didn't go smooth for me, lol! - I always get the issues, lol!!!!

Management agents are pretty quick to restart; I don't have a 100% accurate time in seconds, but definitely less than a minute. As for the management agent restart issue...do you have Automatic Startup/Shutdown for VMs enabled?? I really can't comment on the iDRAC question since I've never used it or set it up before.

Deathmage

Verities wrote: »

Management agents are pretty quick to restart; I don't have a 100% accurate time in seconds, but definitely less than a minute. As for the management agent restart issue...do you have Automatic Startup/Shutdown for VMs enabled?? I really can't comment on the iDRAC question since I've never used it or set it up before.

Turns out I just let it run this time, clocked it taking 3 minutes and it was successful and once it restarted the SSH connection reconnected. I was just impatient earlier. But no Automatic is setup, they aren't control in that manner everything is manual.

Verities

Deathmage wrote: »

Turns out I just let it run this time, clocked it taking 3 minutes and it was successful and once it restarted the SSH connection reconnected. I was just impatient earlier. But no Automatic is setup, they aren't control in that manner everything is manual.

Good to know. Maybe the times are based on server performance. Sometimes it can be very hard to be patient especially since, as a society, we are used to having everything right now.

Deathmage

I swear my answers are correct?

Is this app broken?



erg, I think those asnwers are for a NFS datastore, shoot.

kj0

Deathmage wrote: »

I swear my answers are correct?

Is this app broken?



erg, I think those asnwers are for a NFS datastore, shoot.

A and B. Definitely B. If you Unmount, then you would not lose anything from the datastore.

rajrajhans

hey its quite good idea

tomtom1

A and B would be correct indeed. When "deleting" NFS you wouldn't lose data.