The study guide is 700+ pages of VMware content that would be very useful to admins even if you are not studying for the VCP. It covers a huge amount of topics from installs to setting networking and store. These chapters are not small high level ones, they really go into a good amount of info and spell out the details for you.

Each of the chapters has questions at the end to help you review the information that you just gained. This seems like a decent approach to learning tech info. Overall I would say that the book is worth the price to anyone studying for the exam and it is currently selling for around $30 on Amazon.

Consider reading my list of vCloud best practices when you are done with this list, since they are used together often.

vShield Manager

• Do not deploy vShield manager appliance to a cluster that it will be protecting, can cause connection to itself and vCenter to be lost. (With vShield 5.0.1 you can exclude the appliance from protection, but I would still avoid)
• Access to default services like DNS, syslog, NTP and other similar services that all your VMs need access to should be created as Layer 3 low precedence rules at the datacenter level.
• To provide additional resiliency beyond HS considering using Fault Tolerance (FT) for protecting vShield Manager

vShield App instances (Appliances)

•  When deploying use local datastore on host if available to prevent accidental vMotion
• Consider setting DRS host affinity to make sure the vShield app appliance does not get vMotioned off of host, DRS is disabled by default for the appliance VM.
• Follow vSphere hardening recommendations for virtual switches
• Use Security Groups to group together server of same functions (Domain controllers, Web server, DB server etc.)
• Ensure that the HA restart priority for the vShield App appliance is set to high to ensure it is the first to restart, making sure that its running before the VMs its protecting are started.

I don’t plan on teaching you how to use Orchestrator, there is a good book by written by Cody Bunch on Orchestrator. What I do want to talk about is some ideas of what you might be able to use Orchestrator for and get your creativity flowing.

Orchestrator ideas:

Idea 1:

A workflow that clones a VM from a template , nothing exciting right. Well what if you could have the workflow do the customization part for you? So what does this mean, well the workflow could look at the template you are deploying from and then select a License Key for the proper OS that is being used. Then it could place the VM in the Active Directory OU of your choosing. Try doing this type stuff with standard vCenter customization templates, the licensing would take multiple customization files and the OU part would require the template to already belong to the OU you want it to end up in. This would add a lot of layers of complexity to your environment doing it the old way. But with a Orchestrator workflow you can accomplish this and make your admins lifes easier.

Idea 2:

The idea here is not that much different from Idea 1, but it involves VCD. So the idea would be that we have several Organizations setup inside of VCD and the VMs from each Org need to belong to a different OU in Active Directory. Well you probably say there is no easy way to do that. You are right but with Orchestrator we can create a blocking task and a workflow with logic in it that will listen to the request coming from VCD and do a look up for which Org is requesting the VM and match that to logic provided in the workflow that will let it know with OU to use.

Idea 3:

This idea came from one of the local VMware reps that I work with. The idea is to use Infoblox for IP and DNS management for vCloud. To make this work a blocking task would be created that would step in when a new vApp was created and use the Infoblox plug-in for Orchestrator. To give you an idea of how this would work in simple terms. You would deploy vApp and select that it grab an IP from a static pool in VCD. This allows the VM to be created but the IP is only temp and is taken from a small pool that is used just for this purpose. Then the blocking task will step in and request a permanent IP from Infoblox and register it with DNS. The workflow will then go back into VCD and change the IP address selection method to static-manual because it was now being provided from Infoblox.

These are some basic ideas but ones that I know people might be able to use. The whole idea is to get you thinking about what types of automation you might be able to accomplish with Orchestrator by providing some examples.

If you have some workflows that you have already created or an idea for one drop me a comment to add to the discussion to help others.

What it comes down to is there are a few layers or roles within partners and customers that need to be trained on a new product. I’ve broken it out below into 3 classes that vendors should offer for their products. These translated into software or hardware products I believe.

• How do I design for your product – This should be an design / architecture focused class. In this class we should be talking about customer requirements, sizing decisions and other things that might affect how I would create a design for Product X.
• How do I install your product – This class is focused on install and implementation work. I think this is pretty straight forward, what are the pitfalls to look out for when setting up your product etc.
• How do I manage your product – So this one might be a bit more customer focused but partners still need to be able to understand this and be able to assist their customers on these types of issues. What types of tasks do you expect me to have to complete on a daily, weekly and monthly basis. How do I patch or upgrade your product and these types of tasks.

To me it seems that if these classes were available I could pick out the one that I needed at the time to gain the knowledge that I needed. For me I would usually start out with the design course but also need to understand the other parts at some point.

Out of all the Vendors that I deal with VMware seems to be the one closest to this model. They do have a limited amount of design classes. The most popular VCP related course is heavily focused on the install porting with a bit of management. And the newer performance related courses would fall into the management area. I would like to see other vendors take this approach also.

As an example you have a large environment with several clusters and you create and publish some new rules that affect only a couple of VMs. Will vShield manager push the rules out to every App appliance in the vCenter Datacenter, every cluster or just the cluster or host that has the VMs affected?

The answer is vShield manager only pushes out the rule updates to the vShield appliances that are affected. So only the ones that are protecting the VMs that the new rules apply to. As an example you can create vShield App rules at the datacenter level, cluster level, port group or per vNic. So based on what level the rule was created at and which App appliances are protecting that level determines where the rules are pushed to.

To update vShield manager you need to download the gZip package from VMware. When you look at the download options for vShield there is an OVF package that deploys a fresh version of the appliance or there is a zipped package that you use for updates. Grab the update package and use for the next step.

In Figure 1 below you can see that after logging into the management page of the vShield Manager appliance you need to navigate to the “Settings & Reports” option in the left tree. Then choose the updates tab and then upload settings. This will present you with the option to upload the zipped update file that you downloaded earlier.

Figure 1 - vShield manager update

Once the upload process starts you will see a progress indicator like the one shown in Figure 2 below. If you have any issue in uploading the update package I would suggest restarting the vShield Manager appliance and maybe trying Internet Explorer.

Figure 2 - vShield upload

Once the update package has been installed you will see an Install option on the Update Status page in vShield manager shown below in Figure 3. This screen shows you the installed release of vShield and if you click the arrow next to the install button you will get more details about the release version that the upgrade package contains. Once you are ready to update click the Install button to proceed. Note that this is at least some what disruptive to your network traffic, I have not fully investigated. But the vShield manager appliance does reboot and then below I will discuss how this affects the App appliances.

Figure 3 - vShield update install

Before the actual upgrade starts you will be asked to confirm the Install before proceeding, example below in Figure 4.

Figure 4

Once the upgrade process begins you will see a status page like the one shown below in Figure 5. The page appears to show you the stages for the update. I must admit that I was impatient and hit refresh part way through the process and it happen to be when the vShield manager appliance was about to reboot and the page did not refresh. I then was not able to reconnect to the the page until the update had completed, so I’m not sure if this page updates you very well to the status of the process.

Figure 5

After vShield manager has finished it’s own upgrade process it then needs to update the appliances that sit on each of your hosts for vShield App or Edge if you are using them. In my case I was using vShield App to test out some items. You can see from Figure 6 below that each VM had been updated and powered on VMs were suspended and updated. The process was pretty quick but does affect your VMs. I would say that this process would require some serious planning in a production environment and I would look to see if there is a method of delaying this part of the update so that you could have specific control of the timing and order of your hosts and clusters that are updated.

Figure 6

Lastly I looked at the vShield App device that was running on my host to see if it was restarted in the update process. After taking a quick look at the events of the VM it was not restarted (Figure 7), just appears that the update was pushed to it by vShield manager.

Figure 7

Now that the entire upgrade has finished you can view the updated version in the vShield manager console as show in Figure 8. You should confirm that it matches the build version of the package that you were installing.

Figure 8

Hopefully these steps shed some light on the process of upgrading vShield manager, but I suggest that before executing in your production environment you do some lab testing of the process yourself. To make sure that you account for things that unique to your environment.

The idea of an elastic vDC allows you to add another resource pool to a provider vDC which in turn presents this capacity up to the Org vDC. Now today this option is only available for Org vDCs that are setup for the Pay as You Go allocation model. What it allows you to do is add in the resources from additional vCenter resource pools to a provider vDC. Thus allowing you to grow the resources that are presented up to any Org vDCs using the proper allocation model.

You can see from the image at the bottom of this post that the first resource pool presented is marked as the primary and is what would be used to provide resources to Org vDCs that are using the Allocated or Reserved allocation models.

To add another resource pool you must navigate to the provider vDC that you wish to add the resources to and select the resource pool tab. Then simple click the green plus icon to add the resources by selecting from the vCenter that you choose. Below is a summary of the VMware KB that describes the features and limitations as they stand today.

One of the key defining characteristics of a cloud is elasticity, which means that the container through which a tenant consumes resources can grow and shrink. In vCloud Director 1.5, Pay-As-You-Go organization vDCs are made elastic. Now, multiple resource pools can be added to a single provider vDC and capacity from all of these resource pools can be made available to a single Pay-As-You-Go organization vDC.

This elasticity is restricted to:

• Only the Pay-As-You-Go organization vDCs. The Reservation Pool and Allocation Pool vDC are still bound to a single provider vDC resource pool.
• A single vCenter Server Datacenter (provider vDC resource pools cannot span multiple vCenter Server Datacenters)

The system administrator is allowed to add/remove multiple resource pools to/from an existing Provider vDC, thus making it possible for a Provider vDC to be backed by multiple resource pools. When the provider vDC is created, user selects a primary resource pool. Allocation Pool and Reservation Pool organization vDCs consume resources from this primary resource pool. After creating the provider vDC, additional resource pools can be added to the provider vDC, so that Pay-As-You-Go organization vDCs using that provider vDC can expand, as required, to accommodate more virtual machines.

Found the above info in VMware KB

First step was to take a snapshot of the VCD appliance for a temp backup in case things went terribly wrong. So I shutdown the appliance and took the snapshot.

Step 1: Download upgrade .bin file and copy to VCD appliance

Step 2: Log into the console of the VCD appliance as root

Step 3: You should shutdown the VCD services before upgrading. See notes from VMware KB also listed below.

To gracefully shut down a cell in vCD 1.5.x:

1. Log in to the target cell as root.
2. Navigate to $VCLOUD_HOME/bin/ (typically /opt/vmware/vcloud-director/bin/).
3. Suspend the scheduler by running this command:cell-management-tool -u username -p password cell -q true
4. View the tasks that are running using this command:cell-management-tool -u username -p password cell -t
5. When the task count reaches zero, shut down the cell by running this command:cell-management-tool -u username -p password cell -s

Below is a sample of the command to suspend the scheduler. Spelling this out for those that are not very awesome with Linux.

The next image is examples on steps 4 & 5 from the VMware KB above for viewing tasks running and shutting down the cell.

Step 4: You have to set the .bin file for the upgrade to be executable. Use the command below and image as an example. If you are upgrading using a newer .bin file then the name will be slightly different due to version or build numbers.

# chmod +x vmware-vcloud-director-1.5.1-622844.bin

Step 5: Ok we are now ready to kick off the upgrade. Issue the following command to start the upgrade process.

# ./vmware-vcloud-director-1.5.1-622844.bin

Once the process starts you are going to be asked to confirm that you want to upgrade now, example shown below.

Now that the upgrade has finished you are going to see a warning like the one below that is telling you that you will need to upgrade the database schema before starting VCD again.

Step 6: Next you need to run the upgrade command from the folder specified in image in prior step. This will upgrade the Oracle database included with the VCD appliance. See an example below.

It will ask you to confirm the upgrade of the database as show in image below.

Step 7: After the database upgrade completes it will prompt you to start the VCD services or you can start them manually afterwards if you wish.

Step 8: Now that the upgrade is completed you will need to login to the admin portal and check the version. One thing to note is that it took several minutes after the services started up before I was able to log into the portal.

The main focus of VMware while creating VMFS seems to be making it easier to manage storage in virtual environments. In VMFS-5 the number of storage related objects that need to be managed by an VMware administrator are far less. For example you can now use larger and fewer datastores, because the scaling limits of VMFS-5 have been increased.

VMFS-5 New Features

• Unified 1MB File Block Size. Past versions of VMFS used 1,2,4 or 8MB file blocks. The larger block sizes would allow you to create files larger than 256GB. There is now just one block size in VMFS-5 allowing you to create up to 2TB VMDK files using the 1MB file blocks.
• Larger Datastores. In previous versions of VMFS, the largest datastore size without extents was 2TB-512 bytes. With VMFS-5 this limit has been increased to 64TB.
• Smaller Sub-Block. VMFS-5 introduces a smaller sub-block. The new size is now 8KB rather than the old 64KB size from previous versions. Now a small file less than 8KB but larger than 1KB in size will only consume 8KB rather than 64KB. This will reduce the disk space being consumed by these small files.
• Small File Support. Support for files less than or equal to 1KB, now use the file descriptor location in the metadata for storage rather than file blocks. If they grow above 1KB, these files will then start to use the new 8KB sub blocks. The net result is a reduction in space consumed by small files.
• Increased File Count. VMFS-5 now allows support for more than 100,000 files. In VMFS-3 the limit was 30,000 files.
• ATS Enhancement. ATS is now used all through VMFS-5 for file locking. ATS (Atomic Test & Set) is a Hardware Acceleration primitive, and is part of the VAAI (vSphere Storage APIs for Array Integration). This improves the file locking performance over previous versions of VMFS.

Upgrade considerations and effects

I can say with all confidence that there is no reason not to upgrade to VMFS 5. The question would be how will you go about the upgrade process to VMFS 5? You can do a non-disruptive in place upgrade without affecting any running virtual machines on the datastore. The second option is if you have the space create a new datastore and migrate your virtual machines over to it once created. I have explained the differences between the two methods below and what drawbacks an upgrade might have below.

One of the biggest drawbacks that I came across was the performance hit that you could take on your Storage vMotions. Since upgraded datastores retain their original block size it could be larger than the unified 1MB size in VMFS-5. You will not get the VAAI benefits of faster Storage vMotions when migrating a virtual machine between datastores with different block sizes. This means that Storage vMotions will revert back to an application level Storage vMotion and the process will take 2 to 5x longer than a hardware assisted copy.

This negative affect on svMotions would affect manual migrations but would have a big effect on Storage DRS where VMs are move based on storage performance decisions.

Facts about VMFS-3 to VMFS-5 Upgrades

• You can upgrade from VMFS-3 to VMFS-5 is a non-disruptive operation. Your VMs can continue to run on the datastore.
• Upgraded VMFS-5 can use the new 1KB small-files feature.
• Upgraded VMFS-5 can be grown to 64TB, same as a newly created VMFS-5.
• Upgraded VMFS-5 has all the VAAI ATS improvements that a newly created VMFS-5 has.

What’s different newly created vs. upgraded VMFS-5 datastores

• Upgraded datastores continue to use the previous file block size which may be larger than the unified 1MB file block size.
• Upgraded datastores continue to use 64KB sub-blocks and not new 8K sub-blocks.
• Upgraded datastores continue to have a file limit of 30720 rather than new file limit of greater than 100,000 for newly created VMFS-5 datastores.
• Upgraded datastores continue to use MBR (Master Boot Record) partition type; when the VMFS-5 volume is grown above 2TB, it automatically & seamlessly switches from MBR to GPT (GUID Partition Table) with no impact to the running VMs.
• Upgraded datastores continue to have its partition starting on sector 128; newly created VMFS5 partitions will have their partition starting at sector 2048.

RDM – Raw Device Mappings

• There is now support for passthru RDMs to be ~ 60TB in size.
• Non-passthru RDMs are still limited to 2TB – 512 bytes.
• Both upgraded VMFS-5 & newly created VMFS-5 support the larger passthru RDM.

Other Facts.

• The maximum VMDK size is still 2TB -512 bytes on VMFS-5.
• The maximum size of a non-passthru (virtual) RDM on VMFS-5 is still 2TB -512 bytes.
• The maximum number of LUNs supported is still 256 on an ESXi 5.0 host.

I would recommend based on all the information listed in this chapter that the best method to migrate to VMFS-5 is to create new VMFS-5 datastores. To do this you will of course need to have the storage space to do this and you can then evacuate your existing stores one by one with Storage vMotions. It’s a bit of a shell game moving VMs around as you create new datastores but you will end up with a storage environment that is not affected by any limitations carried over from VMFS-3.

How to upgrade a datastore to VMFS 5

Now that you have either installed or upgraded some hosts to ESXi 5 you probably have datastores that are still at the VMFS 3 level. With vSphere 5 you will be able to continue running your VMs on a datastore that is at VMFS 3 but will want to upgrade them when possible. The upgrade is non-destructive but I would recommend that you make sure you have verified backups of any VMs running on the datastore being upgraded or Storage vMotion them off before upgrading.

During the writing of this book we did numerous tests in a lab environment and each test VMFS upgrade of a datastore with powered off VMs succeeded without issues.

Another thing to note is the option to select your block size on a datastore is gone. When upgrading a VMFS 3 datastore to VMFS 5 it will retain its original block size. All freshly created VMFS 5 datastores will have a block size of 1MB. They will both act the same, allowing you to create a datastore greater than the previous 2TB limit. You are still bound with a 2TB limit for individual VMDK files.

Upgrade datastore to VMFS 5 from vSphere Client

Of the different methods using the vSphere Client is the easiest method to upgrade a datastore to VMFS 5. If you refer to Figure 1 below, you will be looking at a view of the datastore. From this view you can see the selected datastore type is still VMFS 3. Just below you will have the option to click on “Upgrade to VMFS 5” which will kick off the upgrade.

Figure 1: Datastore view

Prior to the upgrade process starting you will see a warning that looks like the one in Figure 2 below. The warning is letting you that any hosts not capable of communicating with VMFS 5 datastores will lose their ability to read or write to them.

Figure 2: VMFS upgrading warning

Upgrade datastore to VMFS 5 with esxcli command

This method will use the esxcli command and can be executed from the ESXi shell or a remote vCLI prompt. This gives you flexibility on where you can run it from and include in scripting.

The command syntax will look like the one of the options listed below, depending on whether you choose to use the Volume name or the UUID for the datastore. This method does not provide any warnings or ask for any confirmations, refer to Figure 3 below.

#esxcli storage vmfs upgrade –l volume_name

#esxcli storage vmfs upgrade – volume_uuid

Figure 3: esxcli command example

Figure 4 below shows the command syntax for the CLI command.

Figure 4: esxcli help

Upgrade datastore to VMFS 5 with vmkfstools command

This method has been around for a while and most of you might has used this to upgrade to VMFS 3. One thing of note is you will not be able to use vmkfstools to upgrade to VMFS 5 from the remote vCLI. This command can only be run from the ESXi shell on the host.

To perform the upgrade you will use the command structured like the one listed below and in Figure 5 below.

#vmkfstools –T /vmfs/volumes/datastore_name

You will be warned about having no active connections to the datastore while upgrading. Also a warning to backup any data on the datastore and to make sure that no ESX(i) 3.x/4.x are still trying to access the datastore.

Figure 5: vmkfstools command

How to back up your ESXi configuration

There are many reasons that you would want to back up your ESXi configuration, of which the two main ones would be before upgrading to a new versions or for DR reasons.

If you are going to be upgrading an existing ESXi host to ESXi 5 you should backup your host configuration before proceeding. With vSphere 5 upgrades there is no option to roll back like there was with vSphere 4 upgrades. This means that a failed upgrade would require you to install ESXi 4.x and restore the configuration.

To backup an ESXi host you will need the vCLI installed on a server or you can also use the vMA.

# vicfg-cfgbackup –server ESXi_host_ip –-username username –-password password –-s backup_filename

How to restore your ESXi configuration

Another really nice thing about ESXi is that it’s just as easy to restore your backed up configuration as it was to grab the backup. Simple install a clean version of ESXi matching the version that the backup was taken from. Connect to the host using vCLI or your vMA appliance as issue the restore command shown below.

# vicfg-cfgbackup –server ESXi_host_ip –-username username –-password password –-r backup_filename

How to back up your ESX configuration

There is not one command to back up an ESX hosts configuration unfortunately.

To accomplish this you will need to back up the following items in a manual fashion.

• Back up local VMFS files system – templates, VMs * .iso files
• Back up any custom scripts
• Back up your .vmx files
• Back up the files in /etc/passwd, /etc/groups, /etc/shadow and /etc/gshadow directories. The /etc/shadow and /etc/gshadow files might not be present on all installations.

How to restore your ESX configuration

If you need to roll back from a failed upgrade or recover from a disaster and need to restore your host follow this short process. First you will need to install ESX 4.x the version level that you were running at the time you backed up your files.

Once you have ESX 4.x installed and running at its previous level you can now restore the files you backed up earlier. This can be done many ways but a couple of simple ways would be to use winSCP or Veeam FastSCP, both are free and easy to use.