Powercli script to capture Cpu & Memory usage stats

Connect-VIServer <server> -User <user> -Password <password>
$allvms = @()
$allhosts = @()
$hosts = Get-VMHost
$vms = Get-Vm

foreach($vmHost in $hosts){
$hoststat = “” | Select HostName, MemMax, MemAvg, MemMin, CPUMax, CPUAvg, CPUMin
$hoststat.HostName = $vmHost.name

$statcpu = Get-Stat -Entity ($vmHost)-start (get-date).AddDays(-30) -Finish (Get-Date)-MaxSamples 10000 -stat cpu.usage.average
$statmem = Get-Stat -Entity ($vmHost)-start (get-date).AddDays(-30) -Finish (Get-Date)-MaxSamples 10000 -stat mem.usage.average

$cpu = $statcpu | Measure-Object -Property value -Average -Maximum -Minimum
$mem = $statmem | Measure-Object -Property value -Average -Maximum -Minimum

$hoststat.CPUMax = $cpu.Maximum
$hoststat.CPUAvg = $cpu.Average
$hoststat.CPUMin = $cpu.Minimum
$hoststat.MemMax = $mem.Maximum
$hoststat.MemAvg = $mem.Average
$hoststat.MemMin = $mem.Minimum
$allhosts += $hoststat
}
$allhosts | Select HostName, MemMax, MemAvg, MemMin, CPUMax, CPUAvg, CPUMin | Export-Csv “c:\Hosts.csv” -noTypeInformation

foreach($vm in $vms){
$vmstat = “” | Select VmName, MemMax, MemAvg, MemMin, CPUMax, CPUAvg, CPUMin
$vmstat.VmName = $vm.name

$statcpu = Get-Stat -Entity ($vm)-start (get-date).AddDays(-30) -Finish (Get-Date)-MaxSamples 10000 -stat cpu.usage.average
$statmem = Get-Stat -Entity ($vm)-start (get-date).AddDays(-30) -Finish (Get-Date)-MaxSamples 10000 -stat mem.usage.average

$cpu = $statcpu | Measure-Object -Property value -Average -Maximum -Minimum
$mem = $statmem | Measure-Object -Property value -Average -Maximum -Minimum

$vmstat.CPUMax = $cpu.Maximum
$vmstat.CPUAvg = $cpu.Average
$vmstat.CPUMin = $cpu.Minimum
$vmstat.MemMax = $mem.Maximum
$vmstat.MemAvg = $mem.Average
$vmstat.MemMin = $mem.Minimum
$allvms += $vmstat
}
$allvms | Select VmName, MemMax, MemAvg, MemMin, CPUMax, CPUAvg, CPUMin | Export-Csv “c:\VMs.csv” -noTypeInformation

Advertisements

Enabling Password Free SSH Access on ESXi

When people ask  “how” to enable password free SSH, the question I always ask in return is “should” you enable password free SSH?  In most situations I would dare say the answer is probably not.  I often find that the decision to enable password free access is not based on any real requirement, but rather is done for the sake of convenience – admins want easy access to their vSphere hosts.  In my opinion, this is a case where security should trump convenience.  However, having said that I do realize that there are valid situations where SSH access is unavoidable, and depending the situation it might make sense to enable password free access.  My point here is that just because you can setup password free SSH doesn’t mean it’s a good idea.  Keep in mind, once you enable password free SSH:


 

  • Anybody with access to the root account on the remote host will have full root access to your ESXi host.
  • Root users allowed password free access to ESXi are not affected by password changes.
  • Root users allowed password free access to ESXi are not affected by lockdown mode.

 

With that I’ll jump down off my soapbox and go over the steps to enable password free SSH.   It’s really pretty easy.  Two basic steps:

1.  On the remote host use “ssh-keygen” to create a private/public key pair.  You can use an RSA or DSA token.  Make sure you leave the passphrase empty/blank.

1

2.  Next, append the user’s public key (created by the ssh-keygen tool) to the /etc/ssh/keys-root/authorized_keys file on the ESXi host.  Here’s an easy way to do this  (I got this nifty syntax from here):

# cat /root/.ssh/id.dsa.pub | ssh root@<esx host> ‘cat >> /etc/ssh/keys-root/authorized_keys’

2

With the remote host’s public key stored in the “authorized_keys” file, anytime this user SSH’s to the vSphere host instead of prompting for a password the host will check the remote users public key against what’s in the authorized_keys file, and if a match is found access is allowed.

Note:  I’ve seen a few articles that mentioned the need to edit the /etc/ssh/sshd_config file.  On ESXi 5.0  you do not need to edit the sshd_config file. The file is already configured to allow password free SSH.  All you need to do is load the user’s public keys into the /etc/ssh/keys/authorized_keys file.

Advanced : VMware HA Important Points

Advanced : VMware HA Important Points

post source : isupportyou

VMWare HA Important Points

  • HA maintains the high availability of virtual machines when an event of host failure / isolation occurs by powering on them on running hosts.
  • Every host in cluster exchanges its heartbeat with other hosts to notify them that it is alive.
  • A host is declared as isolated when its heartbeat is not received within 12 seconds.
  • A host is declared as dead when its heartbeat is not received within 15 seconds, we can increase this duration to avoid false positives by defining an advanced setting das.failuredetectioninterval in vCenter.
  • If we set das.failuredetectioninterval to 60 seconds we can avoid false isolations, which means if an isolated host comes back within 60 seconds VM’s will continues to run on the same host, which means HA will never interfere.
  • When a host is declared as isolated after defined interval isolation response will be executed on that host.
    • If isolated response is set to “Leave Powered on” the vm’s will continues to run on the isolated, however if another host tries to power on the same vm on other host it may not be possible to do so, because of underlying lock mechanism provided by vmfs.
    • If isolated response is set to “Shutdown” the vm’s will undergo clean shutdown by the host and then they will be powered on other host.
    • If isolated response is set to “Power off” the vm’s will powered off immediately by the host and then they will be powered on other host. At the same time if the host has VM’s which are shutdown gracefully, they will never powered on new host. Only abnormally powered off vm’s will be powered on other hosts to avoid service interruptions.
  • When a host is declared as dead all the vm’s running on it will be powered on immediately on other hosts following admission control policies and restart priorities.
  • Admission control policies are defined to ensure sufficient resources are available to virtual machines when a host failure/isolation occurs, in other words HA will reserve some resources to provide room for virtual machines in worst case scenario. There are three policies available to make these reservations.
    • Host failures a cluster can tolerate
      • If we select this option, HA will reserve resources based on a concept called slots. “A slot is a logical representation of highest CPU and Memory reservations that satisfy requirements for any powered on vm in the cluster”. When slots are calculated a host with highest slots will be removed out of equation, this decision ensures resources for all the VM’s if any other host fails throughout the cluster.
      • A slot is defined from highest CPU and memory reservations in the cluster, if a VM has 4GHZ CPU and 1GB RAM and other VM has 2GHZ CPU and 4GBRAM, so 4GHZ and 4GB is defined as slot.
      • Number of slots available on a host will be calculated based on most restrictive number, for example if a host has 256GB of RAM and 16GHZ of CPU, it has 64 slots for memory and 4 slots for CPU, so the host will be considered to have 4 slots for failovers, which means it can accommodate 4 VM’s in an event of failure.
      • A custom slot size also can be defined using advanced options to increase number of slots and avoid resource wastage in case of a cluster has a VM with high amount  of resource reservations.
      • An example calculation of slots, Example 1
        • Host A -> 12GHZ + 12 GB
        • Host B ->  8 GHZ + 8 GB
        • Host C -> 12GHZ + 12 GB
        • VM 1 -> 2GHZ + 4 GB
        • VM 2 -> 1GHZ + 2 GB
        • VM 3 -> 4GHZ + 2 GB
        • VM 4 -> 4GHZ + 1 GB
        • VM 5 -> 2GHZ + 3 GB
        • VM 6 -> 3GHZ + 3 GB

So this cluster has 3 hosts with different set of resources, it has 32 GHZ CPU and 32 GB RAM throughout the cluster. As discussed earlier slot is calculated from the largest reservations of CPU and RAM assigned to the VM’s in this cluster. In our case the slot size would be 4GHZ and 4GB, it can satisfy the requirements for any powered on VM in this cluster.

So Host A has 3 slots, Host B has 2 slots and Host C also has 3 slots. A total of 8 slots available in this cluster.

If Host B fails this cluster will have only 5 slots available, this is called current capacity. Which does not satisfy to power on all VM’s so VM’s will be never powered or migrated to these hosts.

  • Another example 2
    • Host A -> 9GHZ + 9 GB
    • Host B -> 9GHZ + 6 GB
    • Host C -> 6GHZ + 6 GB
    • VM 1 -> 2GHZ + 1 GB
    • VM 2 -> 2GHZ + 1 GB
    • VM 3 -> 1GHZ + 2 GB
    • VM 4 -> 1GHZ + 1 GB
    • VM 5 -> 1GHZ + 1 GB

So this cluster has 3 hosts with different set of resources, it has 24GHZ CPU and 21GB RAM throughout the cluster. As discussed earlier slot is calculated from the largest reservation of CPU and RAM assigned to the VM’s in this cluster. In our case the slot size would be 2GHZ and 2GB, it can satisfy the requirements for any powered on VM in this cluster.

So HA has 4 slots, Host B has 3 slots and Host C also has 3 slots. A total of 10 slots available in this cluster.

If Host B fails this cluster will have 7 slots available, this is called current capacity. And we have 5 VM’s to power on so all can be powered on without any problem as they are not violating resource constrains.

  • Percentage of resources to be reserved
    • This is the most flexible mechanism to reserve resources for HA failovers.
    • This does not use slots concept to reserve resources, available resources will be calculated based on following formula
      • (Total available resources – Total reserved resources)/(Total available resources)
    • Using this option we can reserve resources at cluster level, not at host level.
    • There are no advanced options needs to be configured.
  • Dedicating a host for fail over
    • A dedicated host will be designated for failover purposes, this wastes resources as we need to dedicate a host and it is sitting idle all the time.
  • Restart priorities are followed in the below order
    • Agent based VM’s
    • FT enabled VM’s
    • VM’s with high priority option defined
    • VM’s with medium priority option defined
    • VM’s with low priority option defined
  • When a host is declared as dead all the VM’s running on it will be powered on on other hosts running in that cluster based on restart priority defined above.

HA in vSphere 4.1

  • It is called as Automated Availability Manager in this version.
  • When we configure HA on vSphere 4.1 cluster, the first 5 hosts will be designated as Primary nodes, out of these 5 one node will act as “Master Primary” and which will handle restarts of VM’s in the event of a host failure.
  • All the remaining hosts will join as Secondary Nodes.
  • Primary nodes maintain information about cluster settings and secondary node states.
  • All these nodes exchange their heartbeat with each other to know the health status of other nodes.
  • Primary nodes sends their heart beats to all other primary and secondary nodes
  • Secondary nodes sends their heart beats to primaries only
  • Heart beats will be exchanged between all nodes every second.
  • In case of a primary failure, other primary node will take the responsibility of restarts.
  • If all primaries goes down at same point, no restarts will be initiated, in other words to initiate reboots at least one primary is required.
  • Election of primary happens only during following scenarios
    • When a host is disconnected
    • When a host is entered into maintenance mode
    • When a host is not responding
    • And when cluster is reconfigured for HA.

 HA in vSphere 5.0

  • It is called as Fault Domain Manager in this version
  • HA is completely re-designed in this version, ha agent directly communicates with hostd instead of using a translator to communicate to vpxa. So every host has information of other host resources, which helps in an event of VC failure.
  • DNS dependency has been completely lifted off
  • When we configure HA on vSphere 5.0 cluster, the first node will be elected as master and all other nodes will be configured slaves.
  • Master node will be elected based on number of data stores it is connected to, and if all the hosts in cluster are connected to same number of data stores, host’s managed id will be taken into consideration. Host with highest managed id will be elected as master.
  • All hosts exchanges their heartbeats with each other to know about their health states.
  • Host Isolation response has been enhanced in this version, by introducing data store heart beating. Every host creates a hostname-hb file on the configured data stores and keeps it updated at specific interval. Two data stores will be selected for this purpose.
  • If we want to know who is master and who slaves are, just need to go to vCenter and click on Cluster Status from homepage in HA area.

VMware App Volumes Deployment Guide

Post Source Virtual langer

Installing and Configuring VMware App Volumes Manager

During VMworld 2014 it was announced that VMware was purchasing Cloud Volumes, an upstart for application virtualization technology. Fast forward to earlier this month and VMware officially released the product under the App Volumes name and made the software available to customers (as a standalone product or part of the Horizon View Enterprise bundle) as well as trial bits to give folks the chance to kick the tires.

App Volumes allows for the creation of containers or “AppStacks” for the delivery of a single application or multiple applications within a single stack. Shown in the picture below you can see with the use of the “CloudVolumes agent” the application stacks are decoupled from the operating system. Additionally, with the use of “Writable Volumes” user settings and changes can be captured and saved.

With all this goodness in hand, this first post in the series will cover the installation and configuration of the brains for App Volumes, the App Volumes Manager. In additional posts I will discuss the creation, presentation, and updating of AppStacks. Let’s get started!

The Prerequisites

  • Created Active Directory Service Account – Used for both LDAP Reads and vCenter Server permissions
  • Created “AppVolumes User” Role in vCenter (see eye chart at the end of the post for role permissions)
  • Windows Server 2012R2 virtual machine configured with 2vCPU’s and 4GB of RAM
  • MS SQL Database configured on remote MS SQL Server 2008R2 server
  • Trial software bits from VMware website -> HERE

The Install

Mount the VMware App Volumes ISO to the “VMware App Volumes Manager” server and execute the installer. Click “Next” on the Installation Wizard dialog:

Accept the the licensing agreement and click “Next”  to continue:

Choose the “Install App Volumes Manager” radial and click “Install” to continue:

The “App Volumes Manager Installation Wizard” dialog will be displayed. Click “Next” to continue:

Choose if you wish to have setup program install/configure a copy of SQL Server Express or utilize an existing SQL Server Database. For this example I am using an existing remote SQL Server Database:

Fill in the needed Database Server connectivity details and click “Next” when ready:

I had no need to change the default HTTP and HTTPS ports. Moving on, click “Next”:

I left the default Destination Location unchanged. Click “Next” to continue:

At this point we are ready for the actual installation. Click ‘”Install “ to proceed:

During my install this screen was accurate, it took about 8 minutes to complete the installation:

Once the installation completes click “Finish” to exit the installer:

The Configuration

With the completion of the installation we have to run through a quick “setup” process to configure VMware App Volumes Manager.

Launch the App Volumes Manager desktop icon:

A “Welcome to App Volumes Manager” webpage will be displayed. It provides an overview of the tasks that can be completed and initiated App Volumes Manager. Click “Get Started”:

The first tab that is displayed is the “License Information”. As I am using the trial version of the software we don’t have much to do here. One thing to point out, when using the trial version of the software only a single Appstack can be attached per user. Click “Next”  to continue:

Second tab displayed is for the configuration Active Directory. Provide the details for your domain, domain controllers (if you want to specify) and user with “Read” access to your directory. I provided a service account that I created for both Active Directory and vCenter permissions. Click “Next” to continue:

Configure the Active Directory group that will be added to the App Volumes Admin Group. For lab use I added my Domain Admins group. Click “Next”:

Next up is the Hypervisor Credentials tab. I am using the “vCenter Server”, as I am assuming most folks will, and the service account I created assigned to the “App Volumes User” vCenter Role I created. I also provided my ESXi hosts root account and password to enable the “Mount on host” setting. Click “Next”:

In the Storage tab we are configuring the location of where the Appstacks and Writeable volumes that are created will be stored. In my lab environment I configured both to use the VSAN Datastore:

Confirm the Storage Settings to proceed. To choose whether to “Import volumes in the background” or “Import volumes immediately”

Provide the vSphere Datastore to upload the volume templates and provide login in credentials for the ESXi host used for the data transfers. Click “Upload” to continue:

Finally, verify the selections/settings made in the previous tabs provide in the Summary. Click “Next” to proceed:

With all the steps completed and configured you are taken to the App Volumes Manager Dashboard:

From here we are good to install our AppVolumes agent and create our first AppStack. Stay tuned!

-Jason

vCenter Server Permissions

  • Datastore
    • Allocate space
    • Browse datastore
    • Low level file operations
    • Remove file
    • Update virtual machine files
  • Folder
    • Create folder
    • Delete folder
  • Global
    • Cancel task
  • Host
    • Local operations
      • Create virtual machine
      • Delete virtual machine
      • Reconfigure virtual machine
  • Resource
    • Assign virtual machine to resource pool
  • Sessions
    • View and stop sessions
  • Tasks
    • Create task
  • Virtual Machine
    • Configuration
      • Add existing disk
      • Add new desk
      • Add or remove device
      • Change resource
      • Remove disk
      • Settings
    • Interaction
      • Power off
      • Power on
      • Suspend
    • Inventory
      • Create from existing
      • Create new
      • Move
      • Register
      • Remove
      • Unregister
    • Provisioning
      • Clone template
      • Clone virtual machine
      • Create template from virtual machine
      • Customize
      • Deploy template
      • Mark as template
      • Mark as virtual machine
      • Modify customization specification
      • Promote disks
      • Read customization specifications

VMware Tools one-liners using PowerCli

VMware Tools one-liners using PowerCli

Post source Pario

This short post is about VMware Tools on VM guests running in a vSphere 5.x cluster/hosts.

“Connect by using integrated authentication. In this case, the credentials you are logged on to your machine must be the same as those for the server”

Connect-VIServer Server

This PowerCli one-liner creates a list of VM guests where the VMware Tools CDROM/ISO is mounted:

(Get-VM | Get-View | Where {$_.Runtime.ToolsInstallerMounted}) | % {$_.Name}

Unmount the VMware Tools installer CDROM on all VM guests. This is useful to run before you try to put at ESXi host in maintenance mode because VM guests thatare installing VMware Tools will not migrate because the VMware Tools is not on a shared storage. You will get the error message “The virtual machine is installing VMware Tools and cannot initiate a migration operation”.

(Get-VM | Get-View | Where {$_.Runtime.ToolsInstallerMounted}) | % {Dismount-Tools }

This last one finds all VM guests running Windows as guest OS and upgrades VMware Tools without a reboot at the end

Get-VM | Where {$_.PowerState -eq “PoweredOn” -and $_.Guest.OSFullName -match “Win*”} | % {Update-Tools -VM $_ -NoReboot}

VM Tools and Virtual Hardware Versions

Get-VM | Select Name, Version

But the returned object doesn’t have a root property for ToolsVersion or ToolsVersionStatus, for this we need to delve into the ExtensionData property and have a look around, once we have found the information it is fairly easy to add these to our object using the New-VIProperty cmdlet as below:

New-VIProperty -Name ToolsVersion -ObjectType VirtualMachine `
-ValueFromExtensionProperty ‘Config.tools.ToolsVersion’ `
-Force

New-VIProperty -Name ToolsVersionStatus -ObjectType VirtualMachine `
-ValueFromExtensionProperty ‘Guest.ToolsVersionStatus’ `
-Force

Now we have added these as a new property to our object (actually they are PowerShell Code Properties), we can use our old friend Get-VM to retrieve the information easily:

Get-VM | Select Name, Version, ToolsVersion, ToolsVersionStatus

Of course we can choose which list of VMs to get this information for:

For a Datacenter: Get-Datacenter London | Get-VM | Select Name, Version, ToolsVersion, ToolsVersionStatus

For a cluster: Get-Cluster Production | Get-VM | Select Name, Version, ToolsVersion, ToolsVersionStatus

For a host: Get-VMHost Host1.mydomain.local | Get-VM | Select Name, Version, ToolsVersion, ToolsVersionStatus

And we can also easily export this information into a csv file:

Get-VM | Select Name, Version, ToolsVersion, ToolsVersionStatus | Export-Csv -NoTypeInformation -UseCulture -Path C:\Temp\VMHWandToolsInfo.csv

Update sequence for vSphere 5.5 and its compatible VMware products

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2057795

 

Update sequence for vSphere 5.5 and its compatible VMware products (2057795)

Purpose

VMware has made available certain releases to address critical issues for several products including:

  • vCloud Director (VCD)
  • vCloud Networking and Security (VCNS) (formerly vShield Manager)
  • Horizon View
  • vCenter Server
  • vSphere Replication (VR)
  • vCenter Site Recovery Manager (SRM)
  • vCenter Operations Manager (vCOPS)
  • vSphere Data Protection (VDP)
  • vSphere Storage Appliance (VSA)
  • ESXi
  • vShield Edge
  • vShield App
  • vShield Endpoint

This article only encompasses environments running vSphere 5.5 and VMware products compatible with vSphere 5.5.

In an environment with vSphere 5.5 and its compatible VMware products, follow the update sequence described in the Supported Update Sequence table.

Note: This article refers only to the latest versions of VMware products that are supported by vSphere 5.5 and its update sequence. For a complete list of VMware products compatible with vSphere 5.5, see VMware Product Interoperability Matrixes.

Resolution

This table describes the sequence in which the vSphere 5.5 and its compatible VMware products must be updated:

Supported Update Sequence

  VCD VCNS View Composer View Connection Server VSA Manager vCenter Server VR / SRM vCOPS VDP ESXi VMware Tools vShield Edge vShield App vShield Endpoint View Agent / Client
Update Sequence Number 1                            
  2                          
    3                        
      4 4**                    
          5*                  
            6 6 6            
                  7*          
                    8        
                      9 9 9 9

* If you are using a Cisco Nexus 1000V, see vSphere 5.5 and its compatible third-party products in the Additional Information section of this article before upgrading vCenter Server (sequence step 5) or the ESXi hosts (sequence step 7).

Note: If you need to update multiple products in your environment, start with updating the product with the lowest sequence number. After you update the product, update the product with the next sequence number. If a product is not present in your environment, update the subsequent product. If you need to update two products with the same sequence number, the order of update does not matter.

Before you update vCenter Server, disable vCenter Server from vCloud Director. Also ensure that you stop or disable other VMware services so that they do not communicate with vCenter Server during the update process. For more information, see the product documentation.

Sample VMware product upgrade scenarios

Example 1

If you have the vCloud Director solution stack installed in your environment, the supported patch update sequence is:

  1. Update vCloud Director (sequence step 1)
  2. Update vCloud Networking and Security (vShield Manager) (sequence step 2)
  3. Update vCenter Server (sequence step 5)
  4. Update ESXi (sequence step 7)
  5. Update vShield Edge (sequence step 9)

Example 2

If you have SRM solution installed in your environment, the supported patch update sequence is:

  1. Update vCenter Server (sequence step 5)
  2. Update vSphere Replication (sequence step 6)
  3. Update ESXi (sequence step 7)

Example 3

If you have the vSphere Data Protection solution installed in your environment, the supported patch update sequence is:

  1. Update vCenter Server (sequence step 5)
  2. Update vSphere Data Protection (sequence step 6)
  3. Update ESXi (sequence step 7)

Example 4

If you have the vSphere Storage Appliance solution installed in your environment, the supported patch update sequence is:

  1. Update vSphere Storage Appliance Manager (sequence step 4)
    1. For a 2 node VSA cluster, see Upgrade a Two-Node VSA Environment in the vSphere Storage Appliance Installation and Administration guide
    2. For a 3 node VSA cluster, see Upgrade a Three-Node VSA Environment in the vSphere Storage Appliance Installation and Administration guide
  2. Update vCenter Server (sequence step 5)
  3. Update vSphere Storage Appliance Cluster (sequence step 6)

Example 5

If you have a Cisco Nexus 1000V virtual distributed switch solution installed in your environment, the supported patch update sequence is:

  1. Verify with Cisco the compatibility for the Nexus upgrade procedure. This will dictate the order for upgrading the vCenter Server and the ESXi hosts.
  2. Update vCenter Server (sequence step 5)
  3. Update ESXi (sequence step 7)

Note: If you are using the vSphere Client in your environment, VMware recommends that you upgrade the vSphere Client to version 5.5.

vSphere 5.5 and its compatible VMware products

This table provides information about the current version of released VMware products and the recommended action required to patch to the next level. The table also provides reference links to release notes and update procedure documents.

vSphere 5.5 and its compatible VMware products

Product Version Recommended Action Important Links
vCloud Director (VCD) 5.5.0 Update to 5.5.0 Release Notes
Update Procedure
vCloud Networking and Security (VCNS) 5.5.0 Update to 5.5.0 Release Notes
Update Procedure
Horizon View (View) 5.2.0 Update to 5.2.0 Release Notes
Update Procedure
vCenter Server 5.5.0 Update to 5.5.0 Release Notes
Update Procedure
vSphere Replication (VR) / vCenter Site Recovery Manager (SRM) 5.5.0 Update to 5.5.0 VR Release Notes
SRM Release Notes
Upgrading VR
Upgrading VR without internet access
Upgrading SRM
vCenter Operations Manager (vCOPS) 5.7.2 Update to 5.7.2 Release Notes
Update Procedure
vSphere Data Protection (VDP) 5.5.1 Update to 5.5.1 Release Notes
Update Procedure
vSphere Storage Appliance (VSA) 5.5 Update to 5.5 Release Notes
Update Procedure
ESXi 5.5.0 Update to 5.5.0 Release Notes
Update Procedure
vShield Edge 5.5.0 Update to 5.5.0 Release Notes
Update Procedure
vShield App 5.5.0 Update to 5.5.0 Release Notes
Update Procedure
vShield Endpoint 5.5.0 Update to 5.5.0 Release Notes
Update Procedure