Tag Archives: VCAP

My VCAP5-DCA Experience

Everyone does it right?  Spew out what they thought after writing the VCAP5-DCA exam.  Well, here I am again, being a follower :).

On December 19th, 2013 I made the 2.5 hour drive to Ottawa, Ontario to sit the VCAP5-DCA.  Honestly, the drive wasn't that bad!  We got a break in the snowfall and ice storm for a few days so I guess I scheduled it at the right time of year.  The only complaint I have is that I only passed a couple of Tim Horton's along the way, so the coffee intake was not the greatest – which is probably a saving grace in then end since there are no scheduled breaks during the exam to go to the bathroom.

I arrived at the Exam Centre roughly 45 minutes before my exam started.  I sat down in the food court of the building where the exam center was located, masked one more LUN and made my way up the elevator to sit my exam.  I walked into the Pearson testing Centre 30 minutes before my exam was scheduled to start, hoping to maybe get an early start.  That said, they cannot technically sit anyone any closer than 15 minutes from their start time, so I sat in a chair quietly staring at the floor for 15 minutes.

Ok, on to the exam itself.  Like everyone else has said the exam is fair.  Not once did I see it stray from the blueprint – which would be hard to do since the blueprint pretty much covers everything!  As far as the questions go all I can say is read them slowly.  I actually missed one task on the first question that I caught when I was reviewing a few things.  

I basically started at question 1 and worked my way straight through to the end.  Any question that I didn't finish or that I didn't feel like doing at that time I skipped and wrote down on my little magic erase board.  Let me tell you, when I got to question 26 I was a little worried as I had about 10 numbers written down on that board 🙂  From there, I used the remaining time to go back through the questions and knock off the ones I skipped intentionally.  When they were done, I went on to the questions that I didn't quite understand that well and began working on them.  That's when my time ran out!!!  

Yes, time once again took it's toll on a VCAP test taker!  The 3.5 hours that they give you felt like 10 minutes to me.  I was working so hard and fast that I couldn't believe my eyes when the 5 minute warning came up.

As far as latency goes I only had one period of about 5 minutes where things were very slow to respond.  It didn't really play a factor in my not finishing the exam.  There were some other anomalies with my exam but I'll leave them to VMware's education support to look at!

I walked out of the room with an eery feeling – I knew I did well on most of the questions I finished, but I did leave a lot on the table.  I figured it could go either way!  And then, on January 3rd (which I thought was an impressive turn around for the holiday season) I got the email stating that I had passed with a score of 396!  Needless to say I was stoked!

So, as for tips there is nothing new that I can write down that isn't already written in the many VCAP experiences that are out there.  I'll outline a few that I thought were the most useful

  • Do the stuff that you know how to do first.  If you need to skip a question just scribble down the number and move on.  Time is of the essence, so don't sit around thinking about one given task too long.  Get done what you can!
  • Use the Adobe advanced find for the documents.  This will allow you to search all the documents at once!  Great time saver if you are looking for an advanced setting and you aren't sure what piece of documentation it is in.
  • Use the vSphere Client located on your FIRST screen!  DO NOT try and RDP into vCenter and use the client there – I did this for one question and it is deadly slow.
  • If you need to use a putty window and/or an RDP window just use it and leave it open.  Don't close it, you will just waste time trying to re-open it later.
  • Ugh, try and remember the administrator/root password.  They are all the same but given it's a new password it can be hard to type in multiple times!
  • The best tip I can give you is to know your stuff.  The more you know the easier this exam is.  The more you have done these things in a lab or in your day job it gets even easier.  You can use my 8 weeks of VCAP page (Big thanks to Tom Verhaeg for his help) to brush up on what I have done in the last 8 weeks.  The holy grail for the blueprint however, has to be Josh Coen and Jason Langers Unofficial VCAP5-DCA Study Guide!  Get it and print it and practice it!

That's about it for me with this one!  What's next?  Maybe DCD, but certainly a little family / down time is next in line!

8 weeks of #VCAP – The rest of Section 2 – Port Binding, CLI, and DPIO

Section 2 of the blueprint is a pretty big one, and some of the pieces warranted their own post – however there are a lot of small little skills that don’t really require a complete tutorial so I thought I would just slam them all in here!

Determine use cases for and apply Port Binding settings

vSphere offers three types of port binding in their vSwitch settings (Distributed Virtual Switch only)– all of which are explained below

  • Static – the port will be assigned immediately on connection to the vSwitch.  The VM will stay connected to this port even when it’s powered off.  The only way to free up the port is to explicitly remove the NIC from the VM.  Static Ports are managed through vCenter Server
  • Dynamic – Port is connected when the VM is powered on and then disconnected when the VM is powered off.  Dynamic ports are managed through vCenter Server.  This method has been depreciated in vSphere 5.x
  • Ephemeral – Both static and dynamic port binding has a set number of ports, in ephemeral, the ports are actually created and destroyed on the VM power on/power off event therefore requiring a bit more overhead.  That said, these are managed by the host, therefore, networking can still be connected/disconnected in the event that vCenter Server is unavailable.

Choosing a port binding method is pretty easy – Right click on your port group, chose edit settings and it should be front and centre in the General section.

Image 1

As far as use-cases go, really ephemeral only needs to be used in recovery purposes since they are a bit more demanding in terms of overhead.  Also, ephemeral does not maintain port-level permissions and controls when a VM is rebooted, since the port will be destroyed and recreated.  For the most part it’s best to use Static port binding – and since 5.0 offers an auto expand feature to dynamically grow the number of ports by a specified interval, you shouldn’t have to worry about running out of ports.

Command Line goodness

The networking section references the ability to use command line tools to manage both standard and distributed virtual switches.  Obviously I can’t go over every command and every switch.  Just be sure to know how to use esxcfg-vswitch, esxcfg-vmknic, esxcfg-route, the networking namespaces in esxcli, as well as some of the PowerCLI cmdlets around networking (Get-VirtualSwitch, Get-NetworkAdapter, Get-VMHostNetwork, etc).

Hint – for the PowerShell command line stuff you can quickly find the PowerCLI commands associated with networking (or anything for the matter) by utilizing the Get-VICommand cmdlet and passing a search string.  IE, to return all cmdlets containing ‘net’ you can use the following

Get-VICommand –Name *Net*

Determine use cases for and applying VMware DirectPath I/O

I’ve never used DPIO – that said, there it is on the blueprint so I’d better figure it out.  As for use cases, honestly I haven’t seen many.  For the most part utilizing the virtualized hardware seems to perform well enough, but if you need the tiny bit performance improvement it claims to provide there are a couple of steps to get it running.

First up we need to configure pass-through on the host itself.  This is done on the Configuration tab under ‘Advanced Settings’.  Simply select ‘Configure Pass-through’ and select the device you want to present to a VM.


Once you are done this you will need to restart the host in order to complete the next step, so go ahead and do that.

As for presenting the pass-through device to the VM this is done just as you would do any other piece of hardware (In ‘Edit Settings’ of a VM).  Simply select PCI Device as your hardware and follow the wizard.  You should see your device that you had setup for pass-through earlier in the dropdown box as shown below.


From here you will need to ensure that your guest OS has the correct drivers in order to install this hardware as it is presented directly to the VM.  Aside from creating a memory reservation on your VM there are also a ton of features that are unavailable when you utilize DPIO.  Things such as vMotion, HA, DRS, Snapshots, Hot add, Fault tolerance are all not supported – probably why there is such low adoption.

And I think that should just about wrap up networking.  There is some teaming information mentioned, but honestly I find this to be VCP level knowledge and I’m just going to assume you already know it 🙂  Good Luck!

8 weeks of #VCAP – CDP and LLDP

Well, 8 weeks of VCAP has dwindled down into a serious 8 days of VCAP – and for now, how about a little bit of random information from the Networking section of the blueprint.

First up, CDP and LLDP

These are relatively easy to configure, however there are a few different modes that they can be run in, therefore I thought it would be best if I write them down in hopes that maybe I’ll remember them if any scenarios require me to configure them.

Basically the functionality of the two protocols is identical – they both provide discovery of ports connected to a virtual switch.  CDP however supports just Cisco physical switches whereas LLDP supports any switch supporting LLDP.  Another note, CDP can be enabled on both vSphere Standard Switches and vSphere Distributed Switches – LLDP – dvSwitch only!

So let’s have a look at the dvSwitch config first.  Like I mentioned earlier it’s pretty simple. From the properties tab of a vSphere Distributed Switch select ‘Advanced’.  From here its as simple as setting the status to Enabled, the type to either CDP or LLDP, and the Operation mode (explained below).

  • Listen – ESXi detects and displays information from the associated physical switch port, but all information in regards to the virtual switch is not available to the physical switch.
  • Advertise – ESXi presents information in regards to the virtual switch available to the physical switch, but doesn’t detect any information in regards to the physical switch port
  • Both – Does both advertise and listen.


Now that we are enabled we can view what information we receive inside of the Networking section of a hosts configuration tab.  To do so, simply expand out your physical uplinks and click the information icon (shown below).


And that’s all there is for that – with the distributed switch anyways.  To get CDP working on a standard switch we are once again back into the command line interface.  Probably good to brush up on these commands anyways since its also mentioned in the blueprint.  So, Let’s say we wanted to configure CDP on a vSphere Standard Switch called vSwitch0 to a value of Both.  We could use the following command

esxcli network vswitch standard set –v vSwitch0 –c both

And that’s all there is to that – valid options for –c would be both, listen, advertise or down.  To view we could use the same process as above.

8 weeks of #VCAP – Syslog scenario by @tomverhaeg

Company policies state that every syslog capable device or server should send these logs to an appropriate syslog collector. Your colleague has already set up the VMware syslog collector on a separate machine, located at You have been tasked with setting up the syslog clients on the ESXi hosts, and ensuring that syslogs arrive on the syslog server.

To configure the syslog collector on the ESXi hosts, we will be using the esxcli system syslog namespace. This allows us to set different options regarding the local and remote (which is what we want) syslog.

Let’s review the default config first by using the following command:

~ # esxcli system syslog config get

Default Rotation Size: 1024

Default Rotations: 8

Log Output: /scratch/log

Log To Unique Subdirectory: false

Remote Host: <none>

We see that no remote syslog is being used. Let’s configure one, using this command:

~ # esxcli system syslog config set –loghost=

Now that we have configure a remote loghost, we need to reload the syslog daemon to apply the configuration changes. Esxcli can help us once again:

~ # esxcli system syslog reload

You might think that we’re ready now, but when we check our syslog, we don’t see syslog yet. Bummer! For this problem, I’ll reference to the ESXi firewall post (http://blog.mwpreston.net/2013/11/19/8-weeks-of-vcap-the-esxi-firewall/) as with the default security level, this outgoing traffic will be dropped. We need to enable the firewall rule for syslog (udp/514, tcp/1514).

~ # esxcli network firewall ruleset set -r syslog -e true

And reload our changes:

~ # esxcli network firewall refresh

And now, we see our host logs coming in. The VMware syslog collector stores it logs by default in C:\ProgramData\VMware\VMware Syslog Collector\Data


8 weeks of #VCAP – Fault Tolerance by @tomverhaeg

You might know VMware Fault Tolerance already, since the VCAP exam builds on the VCP knowledge. But still, it is in the blueprint, so it might be wise to go over it.

Fault Tolerance, often abbreviated as FT is a technique in which a shadow VM of a running VM is kept in lockstep with the primary. This basically means that all memory and CPU calculations on the primary VM also will be executed on the secondary VM.

In case of a host failover, a VM with fault tolerance enabled can switch over from the primary to the second VM in a matter of seconds, taking right over where the primary stopped. This allows for a better uptime of that VM and avoids the VM restart that HA would do.

There are a few host requirements for running FT:
-> You need to have a cluster where HA is enabled

-> All hosts needs to access the same (shared) datastores

-> There needs to be physical processor support

-> VMkernel ports need to be configured for vMotion and FT logging

There are also some VM requirements for running FT:

-> The VM can only have one (1) vCPU, so no vSMP

-> The VM disks need to be eager zeroed thick provisioned

-> No non re-playable devices (CD ROM, USB devices etc).

-> No snapshots

Configuring the VMkernel port for FT logging

Conform VMware best practices for FT, it it wise to use a dedicated NIC for FT logging (preferably even 10 gigabit), but configuring FT logging is as easy as selecting a checkbox on a VMkernel port:


Enabling FT on a VM

Enabling FT is rather simple, right-click the VM -> Fault Tolerance -> Turn on Fault Tolerance. You might get a popup saying that a reservation (memory) will be created for the full memory allocation of this VM, and that the disk will be eager zeroed out.


After it walks through the process of enabling fault tolerance, you get a nice blue icon in your inventory:


After powering on the FT VM, on the summary page, you also see some info about the FT status:


Testing VMware FT

Now that we have a running FT VM, we might as well test it. We have 2 options for testing it:

Test failover – The primary VM does a failover to the primary VM, and then spawns up a new secondary VM.

Test restart secondary – The secondary VM is re-spawned and the FT configuration is protected again.


After doing a failover of the primary VM, a new secondary VM will be spawned, so the status after doing the failover might be like this:


Troubleshooting VMware FT

So, all is happy, but since we’re doing the VCAP exam, we might expect some troubleshooting.

On the summary page of the host, you can see if the host is configured and ready for FT. If it isn’t, the reason why will also be mentioned:


In the image above, there isn’t a VMkernel port configured for FT logging. So go into your networking and check that FT logging box.

Also, when the VM mentions something like this, the secondary VM is not running, so do a restart or migrate secondary:


8 weeks of #VCAP – Section 3 scenario – CPU Affinity!

Thanks once again to Tom Verhaeg for this great scenario.

The voice team has recently setup Cisco Unity. The VoIP administrator sends you an e-mail. To comply with Cisco best practices, the Cisco Unity VM needs to have CPU affinity set. You really don’t like this, but the VoIP administrator and your boss insist. Make it happen……..

Damn, this really isn’t a fun thing to do. CPU affinity restricts a VM only to run on specific cores / processors that you specify. There may be some requirements for this (such as the above), but overall you shouldn’t do it. This breaks NUMA architecture, and more important, Fully Automated DRS! To support this, the DRS level should either be manual or partially automated.

The process itself isn’t that complicated. Edit the settings of the VM and go to the resources tab. Under advanced CPU, you find the option for CPU affinity.


If you do not see the Scheduling Affinity piece on a DRS-Cluster host, you are running DRS in fully automated mode. You can set DRS to manual for this VM by going to the cluster settings, and under DRS select Virtual Machine options. Set the DRS mode for this VM to either disabled, manual or partially automated.


8 weeks of #VCAP – More Networking Scenarios by Tom!

Another top notch scenario built by Tom Verhaeg! (blog/twitter)  Thanks Tom!

Your recent work on the new portgroup was top notch! Now, the network administrators have some new requirements. You currently use one vNIC for the DvS. A second pNIC has been connected to the network and you have been tasked with adding it to the DvS. Also ensure that the DvS_StorageNetwork Port Group only uses the new pNIC and does VLAN tagging on VLAN ID 20.

Another networking objective. Whoohoo! Allright, let us first check out the current network adapters available on the host:


Allright, so vmnic2 is the one that we can add to the DvS_AMS01. Go over to the networking view (Ctrl + Shift + N) and edit the settings of your DvS. We first need to check if the DvS allows for 2 uplinks, instead of just 1.


And check this out! It’s still set to 1. This is a good one to remember for the exam, on the DvS object itself, you configure the maximum number of physical adapters (also called uplink ports) per host. So set that one to 2 and let’s continue with adding vmnic2 to the DvS.

Since the host is already connected to the DvS, click the DvS and select Manage Hosts. You will find your host, and you can add the second nic.


You could also do this from the hosts and clusters view, do whatever works for you.

Now that we have added that pNIC to the DvS, we need to create the DvS_StorageNetwork port group. Remember that we need to do VLAN tagging on VLAN ID 20 here. Create the new port group now, it’s settings should look like this:


Now, for the last part: As ESXi does load balancing by default (originating port ID based) we will now have load balancing on the DvS_ProductionNetwork, which is great, but not what we need for the Storage Network.

Open up the settings of that port group and go to the Teaming and Failover section.


Both uplink ports are now under Active Uplinks. Let’s review real quick what the options are:

Active Uplinks – actively being used for traffic flow

Standby Uplinks – will only become active until a failure occurs on one of the active uplinks

Unused Uplinks – this adapter will never be used for this port group

We need to ensure that it will never use this uplink, so move the dvUplink1 over to the Unused Uplinks. It should then look like this:


8 weeks of #VCAP – Network Scenario by @tomverhaeg

First off I want to thank Tom Verhaeg (blog/twitter) for providing this scenario.  Tom had gotten in contact with myself and wanted to do what he can to help our with the 8 weeks of #VCAP series as he is going through a similar type process as me in studying for the VCAP5-DCA.  So props to Tom for taking the time and initiative to give back.  Hopefully we see more from him in the coming weeks!  Even better for myself as I can run through some scenarios that I didn't make up 🙂  Be sure to follow Tom on Twitter and check out his blog  Thanks for the help Tom!!!

Your company leverages the full Enterprise Plus licensing and has set up a Distributed vSwitch. Recently, the number of ports needed on a particular portgroup exceeded the number configured. You are tasked with creating a new Portgroup, called DvS_ProductionNetwork which only connects the running VM’s and also functions when vCenter is down.

Off we go again. So, let’s recall. There are 3 different options of port binding on a DvS. 

Static binding – Which creates a port group with a manual set number of ports. A port is assigned whenever a vNIC is added to a VM. You can connect a vNIC static binding only through vCenter.

Dynamic binding (Deprecated in vSphere 5.0!) – A port is assigned to a vNIC when the VM is powered on, and it’s vNIC is in a connected state. You can connect this dynamic binding only through vCenter.

Empheral binding – A port is assigned to a vNIC when the VM is powered on, and it’s vNIC is in a connected state. This binding method allows the bypass of vCenter, allowing you to manage virtual machine networking when vCenter is down.

So, that’s the one we need! Empheral binding! Luckily, it’s quite simple to configure. Hop over to the networking inventory (Ctrl + Shift + N) and create the new port group. Give it a name and leave the number of ports on the default of 128.

Now edit the settings of this port group, and select the Empheral binding under the port binding dropdown. Also note, that the number of ports is greyed out now.



8 weeks of #VCAP – Storage Scenarios (Section 1 – Part 2)

Hopefully you all enjoyed the last scenario based post because you are about to get another one 🙂  Kind of a different take on covering the remaining skills from the storage section, section 1.  So, here we go!

Scenario 1

A coworker has come to you complaining that every time he performs storage related functions from within the vSphere client, VMware kicks off these long running rescan operations.  He's downright sick of seeing them and wants them to stop, saying he will rescan when he feels the need to, rather than having vSphere decide when to do it.  Make it happen!

So, quite the guy your coworker, thinking he's smarter than the inner workings of vSphere but luckily we  have a way we can help him.  And also the functions we are going to perform are also part of the VCAP blueprint as well – coincidence?  Either way, the answer to our coworkers prayers is something called vCenter Server storage filters and there are 4 of them, explained below…

RDM Filter (config.vpxd.filter.rdmFilter) – filters out LUNs that are already mapped as an RDM

VMFS Filter (config.vpxd.filter.vmfsFilter) – filters out LUNs that are already used as a VMFS datastore

Same Hosts and Transports Filter (config.vpxd.filter.sameHostsAndTransporstFilter) – Filters out LUNS that cannot be used as a datastore extent

Host Rescan Filter (config.vpxd.filter.hostRescanFilter) – Automatically rescans storage adapters after storage-related management functions are performed.

As you might of concluded it's the Host Rescan Filter that we will need to setup.  Also, you may have concluded that these are advanced vCenter Server settings, judging by the config.vpxd prefixes.  What is conclusive is that all of these settings are enabled by default – so if we need to disable one, such as the Host Rescan Filter, we will need to set the corresponding key to false.  Another funny thing is that we won't see these setup by default.  Basically they are silently enabled.  Anyways, let's get on to solving our coworkers issue.

Head into the advanced settings of vCenter Server (Home-vCenter Server Settings->Advanced Options).  From here, disabling the host rescan filter is as easy as adding the config.vpxd.filter.hostRescanFilter and false values to the text boxes near the bottom of the screen and clicking 'Add' – see below

hostrescanfilterAnd voila!  That coworker of yours should no longer have to put up with those pesky storage rescans after he's done performing his storage related functions.

Scenario 2

You work for the mayors office in the largest city in Canada.  The mayor himself has told you that he installed some SSD into a host last night and it is showing as mpx.vmhba1:C0:T0:L0 – but not being picked up as SSD!  You mention that you think that is simply SAS disks but he persists it isn't (what is this guy on crack :)).  Either way, you are asked if there is anything you can do to somehow 'trick' vSphere into thinking that this is in fact an SSD.

Ok, so this one isn't that bad really, a whole lot of words for one task.  Although most SSD devices will be tagged as SSD by default there are times when they aren't.  Obviously this datastore isn't an SSD device, but the thing is we can tag it as SSD if we want to.  To start, we need to find the identifier of the device we wish to tag.  This time I'm going to run esxcfg-scsidevs to do so (with -c to show a compact display).

esxcfg-scsidevs -c

From there I'll grab the UUID of the device I wish to tag, in my case mpx.vmhba1:C0:T0:L0 – (crazy Rob Ford).  Now if I have a look at that device with the esxcli command I can see that it is most certainly not ssd.

esxcli storage core device list -d mpx.vmhba1:C0:T0:L0

ssd-noSo, our first step is to find out which SATP is claiming this device.  The following command will let us do just that

esxcli storage nmp device list -d mpx.vmhba1:C0:T0:L0

whichsatpAlright, so now that we know the SATP we can go ahead and define a SATP rule that states this is SSD

​esxcli storage nmp satp rule add -s VMW_SATP_LOCAL -d mpx.vmhba1:C0:T0:L0 -o enable_ssd

And from here we need to reclaim the device

esxcli storage core claiming reclaim -d mpx.vmhba1:C0:T0:L0

And, another look at our listing out of the device should now show us that we are dealing with a device that is SSD.

esxcli storage core device list -d mpx.vmhba1:C0:T0:L0

ssd-yesSo there you go Mr. Ford, I mean Mr. Mayor – it's now SSD!!!!

And that's all for now 🙂

8 weeks of #VCAP – Random Storage Scenarios (Section 1 – Part 1)

So my 8 weeks of #VCAP is quickly turning into just under 4 weeks of #VCAP so as I attempt to learn and practice everything on the blueprint you might find that I'm jumping around quite a bit.  Also, I thought I would try presenting myself with a scenario with this post.  Now all of the prep for the scenario is made by myself, therefore it's a pretty simple thing for me to solve, but none the less it will help get me into the act of reading a scenario and performing the tasks that are on it.  So, this post will cover a bunch of random storage skills listed in Objective 1 of the blueprint – without ado, the scenario

Scenario 1

Let's say we've been tasked with the following.  We have an iSCSI datastore (iSCSI2) which utlizes iSCSI port bonding to provide multiple paths to our array.  We want to change the default PSP for iSCSI2 from mru to fixed, and set the preferred path to travel down CO:T1:L0 – only one problem, C0:T1:L0 doesn't seem to be available at the moment.  Fix the issues with C0:T1:L0 and change the PSP on iSCSI2 and set the preferred path.

​Alright, so to start this one off let's have a look first why we can't see that second path to our datastore.  If browsing through the GUI you aren't even seeing the path at all, the first place I would look at is claimrules (now how did I know that 🙂 ) and make sure that the path isn't masked away – remember the LUN Masking section.  So ssh on into your host and run the following command.

esxcli storage core claimrule list


As you can see from my output lun masking is most certainly the cause of why we can't see the path.  Rule 5001 loads the MASK_PATH plugin on the exact path that is in question.  So, do you remember from the LUN Masking post how we get rid of it?  If not, we are going to go ahead and do it here again.

First step, we need to remove that rule.  That's done using the following command.

esxcli storage core claimrule remove -r 5001

Now that its gone we can load that current list into runtime with the following command

esxcli storage core claimrule load

But we aren't done yet!  Instead of waiting for the next reclaim to happen or the next reboot, let's go ahead and unclaim that path from the MASK_PATH plugin.  Again, we use esxcli to do so

esxcli storage core claiming unclaim -t location -A vmhba33 -C 0 -T 1 -L 0

And rescan that hba in question – why not just do it via command line since we are already there…

esxcfg-rescan vmhba33

And voila – flip back into your Manage Paths section of iSCSI2 and you should see both paths are now available.  Now we can move on to the next task, which is switching the PSP on iSCSI2 from MRU to Fixed.  Now we will be doing this a bit later via the command line, and if you went into the GUI to check your path status, and since we are only doing it on one LUN we probably can get away with simply changing this via the vSphere Client.  Honestly, it's all about just selecting a dropdown at this point – see below.

managepathsI circled the 'Change' button on this screenshot because it's pretty easy to simply select from the drop down and go and hit close.  Nothing will happen until you actually press 'Change' so don't forget that.  Also, remember, PSP is done on a per-host basis.  So if you have more than one host and the VCAP didn't specify to do it on only one host, you will have to go and duplicate everything you did on the other host.  Oh, and setting the preferred path is as easy as right-clicking the desired path and marking it as preferred.  And, this scenario is completed!

​Scenario 2

The storage team thanks you very much for doing that but requirements have changed and they now wish for all of the iSCSI datastores, both current and any newly added datastores, to utilize the Round Robin PSP.  How real life is that, people changing their mind 🙂

No problem you might say!  We can simply change the PSP on each and every iSCSI datastore – not a big deal, there's only three of them.  Well, you could do this, but the question specifically mentions that we need to have the PSP set to Round Robin on all newly added iSCSI datastores as well, so there's a bit of command line work we have to do.  And, since we used the vSphere Client to set the PSP in the last scenario, we'll do it via command line in this one.

First up, let's switch over our existing iSCSI datastores (iSCSI1, iSCSI2, iSCSI3).  To do this we will need their identifier which we can get from the GUI, however since we are doing the work inside the CLI, why not utilize it to do the mappings.  To have a look at identifiers and their corresponding datastore names we can run the following

esxcfg-scsidevs -m

maptodatastoreAs you can see there are three datastores we will be targeting here.  The identifier that we need will be the first string field listed beginning with t10 and ending with :1 (although we don't need the :1).  Once you have the string identifier of the device we want to alter we can change its' PSP with the following command.

esxcli storage nmp device set -d&nbsp;t10.FreeBSD_iSCSI_Disk______000c299f1aec010_________________ -P VMW_PSP_RR

​So, just do this three times, once for each datastore.  Now, to handle any newly added datastores to defaulr to round robin we need to first figure out what SATP the iSCSI datastores are utilizing, then associate the VMW_PSP_RR PSP to it.  We can use the following command to see which SATP is associated with our devices.

esxcli storage nmp device list

defaultsatpAs you can see, our iSCSI datastores are being claimed by the VMW_SATP_DEFAULT_AA SATP.  So, our next step would be to associate the VMW_PSP_RR PSP with this SATP – I know, crazy acronyms!  To do that we can use the following command.

esxcli storage nmp satp set -s VMW_SATP_DEFAULT_AA -P VMW_PSP_RR

This command will ensure that any newly added iSCSI datastores claimed by the default AA SATP will get the round robin PSP.

At this point we are done this scenario but while I was doing this I realized there might be a quicker way to to change those PSP's on our existing LUNs.  If we set associate our SATP with our PSP first then we can simply utilized the following command on each of our datastores to force them to change their PSP back to default (which will be RR since we just changed it).

esxcli storage nmp device set -d t10.FreeBSD_iSCSI_Disk______000c299f1aec010_________________ -E

Of course we have to run this on each datastore as well – oh, and on every host 😉

Scenario 3

Big Joe, your coworker just finished reading a ton of vSphere related material because his poor little SQL server on his iSCSI datastore just isn't cutting it in terms of performance.  He read some best practices which stated that the max IOPs for the Round Robin policy should be changed to 1.  He requested that you do so for his datastore (iSCSI1).  The storage team has given you the go ahead but said not to touch any of the other datastores or your fired.

Nice, so there is really only one thing to do in this scenario – change our default max IOPs setting for the SCSI1 device.  So, first off, let's get our identifier for SCSI1

​esxcfg-scsidevs -m

Once we have our identifier we can take a look on the roundrobin settings for that device with the following command

esxcli storage nmp psp roundrobin deviceconfig get -d t10.FreeBSD_iSCSI_Disk______000c299f1aec000_________________

rr-getinfoAs we can see, the IOOperation Limit is 1000, meaning it will send 1000 IOPs down each path before switching to the next.  The storage team is pretty adamant we switch this to 1, so let's go ahead and do that with the following command.

esxcli storage nmp psp roundrobin deviceconfig set -d t10.FreeBSD_iSCSI_Disk______000c299f1aec000_________________ -t iops -I 1

Basically what we define with the above command is that we will change that 1000 to 1, and specify that the type of switching we will use is iops (-t).  This could also be set with a -t bytes and entering the number of bytes to send before switching.

So, that's basically it for this post!  Let me know if you like the scenario based posts over me just rambling on about how to do a certain task!  I've still got lots more to cover so I'd rather put it out there in a format that you all prefer!  Use the comments box below!  Good Luck!

8 weeks of #VCAP – iSCSI Port Binding

My plan is to go over all the skills in Objective 1.3 but before we get into PSA commands and what not let's first configure iSCSI port bonding – this way we will have a datastore with multiple paths that we can fiddle around with 🙂

First off iSCSI port binding basically takes two separate paths to an iSCSI target (the paths are defined by vmkernel ports) and bonds them together.  So, we need two vmkernel ports.  They can be on the same switch or separate switches, but the key is that you can only have one network adapter assigned to it.  Meaning the vSwitch can contain multiple nics, but you need to ensure that the config is overridden on the vmkernel level to only have one NIC active.  Let's have a look at this.  Below you will see the current setup of my vmkernel ports (IPStore1 and IPStore2).


As you can see, my configuration here is actually wrong and needs to be adjusted – remember, one nic per vmkernel port.  So, with a little click magic we can turn it into what you see below.


Basically, for IPStore1 I have overridden the default switch config on the vmkernel port, setting vmnic0 as active and vmnic1 as unused.  For IPStore2 we will do the same except the opposite (hehe, nice, that makes no sense) – basically, override but this time set vmnic1 as active and vmnic0 as unused.  This way we are left with two vmkernel ports, each utilizing a different NIC.

Now that we have the requirements setup and configured we can go ahead and get started on bonding the vmkernel ports together.  This is not a hard thing to do!  What we are going to want to do is right-click on our software iSCSI initiator and select 'Properties'.  From there we can browse to the 'Network Configuration' tab and simply click 'Add'.  We should now see something similar to below.


As you can see above, our VMkernel adapters are listed.  If they weren't, that would indicate that they are not compatible to be bonded, meaning we haven't met the requirements outlined earlier.  By selecting IPStore1 and then going back in and selecting IPStore2 ( I know, you can't do it at the same time 🙂 ), then selecting OK, then performing the recommended rescan you will have completed the task.  We can now see that below inside of our 'Manage Paths' section for a datastore that has been mounted with our iSCSI initiator we have some nifty multipath options.  First, we have an additional channel and path listed, as well, we are able to switch our PSP to thinks like Round Robin!


And kapow!  That's it!  We are done!  In the next post we will look at how to perform some PSP/PSA related commands against this bad boy!