Guide for upgrading VMware ESXi (5.1 to 5.5U2)

Guide for upgrading VMware ESXi (5.1 to 5.5U2)

Introduction

While i continiously have to deal with ESXi hypervisors in my Sysadmin job, i also have to take care of that they’re up to date. And because it’s a recurring task, updating an ESXi is quite easy as long as you pay attention to certain things.

This guide is about those nitty gritty details and how to update the ESXi Hypervisor only by using vSphere Client and the esxcli.

Start with the prerequisites

At first we should get the details about which version of ESXi we have running as well as its Image-Profile version. Turn on the vSphere Client and connect to your ESXi. Now select your ESXi in the left folder list and you can see your actual version on the blueish bar on the right which tell something like this:

esxi.example.com VMware ESXi, 5.1.0, 123456

In the General tab below you can find the Image Profile version as well. We will now update both of them.

To make sure you can update directly to the new version you want to have, check out the following Link for a update matrix. For us the update path from 5.1 directly to 5.5 Update 2 is possible.

Updating
ESXi Main Version

At first, make sure that SSH is enabled and allowed in the ESXi firewall. Now get the offline bundle package for the desired version, for exmaple:

update-from-esxi5.5-5.5_update02-2068190.zip

You can get those updates in your personal VMware portal!

Upload this to your hypervisors datastore via SCP or the vSphere clients built-in datastore manager and login to your esx command line afterwards:

ssh username@esxi.example.com

Now migrate all your virtual machines to another hypervisor or shut them down. After you’ve done this put your esxi into maintenance mode to prevent automatic restarts of your VM’s:

esxcli system maintenanceMode set –enable on

The next step is testing and if everything is fine there, finally installing it:

# Remove the --dry-run option to finally install the update
esxcli software vib update –depot=/vmfs/volumes/datastore1/update-from-esxi5.5-5.5_update02-2068190.zip --dry-run

If the update wen’t successful, reboot the machine and recheck it’s version which should be this one:

esxi5.5_version

ESXi Image-Profile

You can skip this step, if your Image-Profile version has also been updated and look like this:

esxi5.5_image_profile

If not, let us update it from the esxcli again:

esxcli software profile update -d /vmfs/volumes/datastore1/update-from-esxi5.5-5.5_update02-2068190.zip -p ESXi-5.5.0-20140902001-standard

After a reboot you should see the new Image-Profile. If not run the next command to remove all old Image-Profile traces while installing the new one (you can safely run the following command multiple times):

Another reboot later, your main and Image-Profile versions should be up to date.

esxcli software profile install -d /vmfs/volumes/datastore1/update-from-esxi5.5-5.5_update02-2068190.zip -p ESXi-5.5.0-20140902001-standard –ok-to-remove
Finalizing the Update

You’re almost done!

The last thing you need to do is disabling the maintenance mode just by right-clicking the hypervisor in the folder list in the vSphere Client and select “Disable Maintenance mode”. Now restart or migrate your virtual machines and you’re done until the next update.

Source: http://www.sysorchestra.com

vSphere 5.5 SSO Integration with Active Directory

vSphere 5.5 SSO Integration with Active Directory

After getting ESXi installed on the Mac Minis and the vSphere vCenter Appliance deployed, my next step was to integrate my labs Active Directory with Single Sign On.  Based on the documentation provided on the vSphere 5.5 Documentation Center, the AD integration was a pretty simple procedure and relies on a handful of fundamental components to complete.

  1. Domain Membership
  2. SSO Service Account
  3. Identity Source
  4. Groups and Permissions
Domain Membership:

The vSphere vCenter Server must be added to the Active Directory domain if vSphere SSO Active Directory integration is going to configured.  If your vCenter is a Windows Server, it is a pretty standardized practice and a generally accepted prerequisite.

My lab is using the vCenter Server Appliance, so joining the domain is pretty simple.

  1. Connect to the vCenter Server Appliance Administration page located at https://%5BVCENTER_SERVER%5D:5480/ and login as root. 
  2. Navigate to the Authentication tab under the vCenter Server configuration
  3. Fill out the domain name with the proper credentials with the proper permissions that will allow the computer account for the VCSA to be created in AD
  4. Save Settings but don’t reboot the Appliance until the Identity Source has been set and the proper roles and permissions are configured.

Screen Shot 2013-11-03 at 4.50.55 PM.png

SSO Service Account:

One of the requirements (if you are not using a machine account) for vSphere SSO Active Directory integration is to have a Service Principal Name (SPN) in Active Directory.  To set the SPN, connect to the Domain Controller and create the Service Account for this purpose:

SSOServiceAccount01.png

SSOServiceAccount02.png

The SSO Service Account should be a dedicated account with the proper password expiry settings attributed to it.

Once the Service Account is created, open a command prompt as administrator on the Domain Controller and run the following command as depicted below:

setspn -S sts/[DOMAIN] [SERVICEACCOUNTNAME]

SSOServiceAccount03.png

Ensure that the last line of the command returns with ‘Updated object’ before moving on to the next step.

Identity Source:

Identity sources allow you to attach one or more domains to vCenter Single Sign-On. A domain is a repository for users and groups that the vCenter Single Sign-On server can use for user authentication.

To set the identity source, ensure that the domain membership and SSOServiceAccount SPN settings are completed, then:

Login to the Web Client (https://%5BVCENTER}:9443/vsphere-client/) and connect to the vCenter Server using the administrator@vsphere.local account.  The password for the account from freshly deployed VCSA will be ‘vmware’.  Do not use & not “admin@system-domain” like you did in vCenter 5.1 SSO.

SSOAdminLogin.png

Navigate to  Home > Administration > Single Sign-On > Configuration page

AddIdentitySource01.png

Use the + sign to add your domain as a new identity source. Select ‘Active Directory (integrated Windows Authentication)’ and complete the following fields as depicted below:

Domain name, Service Principle Name (SPN), User Principle Name (UPN) and the password that you set with your created the account in Users and Computers.

AddIdentitySource02.png

If all the fields are no longer outlined in red, you have completed the them successfully and can select OK. If the settings are correct the progress bar should complete in about 30-60 seconds and there will be an additional Identity Source listed in your configuration.

AddIdentitySource03.png

Once the Active Directory domain is added as an identity source for authentication, the proper group memberships and permissions must be setup in order to see the existing vCenter inventory components.

Groups and Permissions

Staying logged in with the administrator@vsphere.local account; navigate to the ‘Users and Groups’ configuration section on the left hand side, select the Groups Tab in the middle and highlight the Administrators Group as in the picture below.  Near the bottom of the page click the ‘Add Member’ button.

Groups&Permissions01.png

When the ‘Add Principals’ wizard pops up:

  1. User the domain drop-down list to select the Active Directory Domain.
  2. Select  and highlight the Group or User account that will be used to access  and administer the vCenter Server.  I would recommend using a group membership.
  3. Use the Add button to populate the Users: or Groups: field below
  4. Select OK to make the changes.

Groups&Permissions02.png

Now that the Groups (or Users) are added into the correct group memberships (that correspond to the correct roles), the permissions to the vCenter must be applied.

Navigate to Home > vCenter > vCenters and highlight the VCSA instance name on the right hand side of the screen.  Select the Manage tab > then select the Permissions tab and use the + [Add permission] button to add the same User or Group in the above example.

Groups&Permissions03.png

Using the Select Users/Groups wizard:

  1. User the domain drop-down list to select the Active Directory Domain.
  2. Select  and highlight the Group or User account that will require permissions to administer the vCenter Server. 
  3. Use the Add button to populate the Users: or Groups: field below
  4. Select OK to make the changes.

Groups&Permissions04.png

After about 30 seconds, the additional line(s) will show up with having the proper permissions to the vCenter inventory and components.  This is the same functionality as setting roles and permissions in the traditional C# client.

Before testing out the access and permissions, remember to reboot the vCenter Server Appliance and allow the domain membership changes to take place.

After the appliance comes back up and the Web Services have started again, login to the Web Client interface and validate that the authentication and permissions are correct and functional. 

SSOLogin.png

An easy way to tell is the inventory and permissions are correct is to validate on the vCenter Home whether the existing vCenters, Hosts and VMs are showing up  on the left hand side within the inventory as in the example below.

SSOLoginVerification.png

If you are running Windows, make sure to download and install the Client Integration Plug-in to enable the ability to use your currently logged in Active Directory credentials. 

Source: http://cloudcanuck.ca/blog/vsphere-55-sso-integration-with-active-directory

How to Install VMware vSphere Client on Domain Controller Machine

This post may be useful for the VMware Administrators who is running small lab environmnet. They may be running a small setup of one or two ESXi host with one windows VM which is acting as a Domain Controller. As VMware admin’s ,we are so much used to work with vSphere windows client against vSphere web Client. Have you tried to installing vSphere client on Domian controller machine. By default, that is not possible. When we try to install vSphere windows client on Domain Controller, We may end up with the error message” vSphere Client fails with a message saying the as a requirements the management station has to be running XP SP2 and not a domain controller”. For people running Lab environment, Will not prefer to install another windows VM just to install vSphere client. In that situation, You can make use of this OS SKIP command to install the vSphere client on Windows Domain controller as a workaround.

Below is the error message you will receive, when you try to install vSphere client on Windows Domain Controller machine.

Install vSphere Client on Domain Controller-1 You can use an advanced switch when installing VI client on Domain Controller . You can launch the installer from a command line and in this case there is a switch to use which skips the OS check. Here is the command to use:

VMware-viclient.exe /VSKIP_OS_CHECKS=”1″

Install vSphere Client on Domain Controller-2

Install vSphere Client on Domain Controller-3

That’s it. vSphere client installation will complete without any error. You cannot use the same switch to install Web client because Web Client cannot be installed on Domain Controller. I hope this is informative for you. Thanks for reading!!!. Be Social and share it in Social media, if you feel worth sharing it.

ESXi 5: Suppressing the local/remote shell warning

 

disable esxi shell warning

Now suppressing it is fairly simple. Go to your host, click the configuration tab, click “advanced settings”, go to UserVars” and scroll all the way down to “UserVars.SuppressShellWarning” change the value from 0 to 1. Simple huh!

disable esxi shell warning

Yes I know most of you probably don’t have access yet, but this is one of those little things that will come in handy at some point.

Be Sociable, Share!

Source: http://www.yellow-bricks.com/2011/07/21/esxi-5-suppressing-the-localremote-shell-warning/

Failed to connect to VMware lookup service

Failed to connect to the VMware lookup service

After deploying and configuring the vCenter Virtual Appliance, when I was trying to login to the vSphere web client, I kept receiving the error ” Failed to connect to VMware Lookup Service https://%5Bhostname%5D:7444/lookupservice/sdk – SSL certificate verification failed. ” and could not login.

Failed to connect to vmware lookup service

This issue occurs if you have changed the hostname or IP address of the vCenter Virtual Appliance.  The certificate that was created on initial configuration is no longer valid.  To resolve this issue, follow the steps below:

  1. Login into vCenter VA Configuration https://%5Bhostname%5D:5480
  2. Select the Admin tab
  3. Click Toggle certificate setting, you will see Certificate regeneration enabled change to Yes.
    Failed to connect to VMware lookup service
  4. Re-boot the Virtual Appliance

During the bootup procedure you will see

Hostname or IP has changed. Regenerating self signed certificate.

Managing Pools and Desktops

Introduction to Managing Pools and Desktops

Version: Horizon View 5.1

As we saw in earlier chapters, creating pools is a very simple process – and the main pool node will show you all the pools you have created. A simple Edit button allows you to modify some (but not all) of your settings generated by the Add pool wizard. The notable value that cannot be modified after the pool has been created is the pool ID parameter as this is a unique identifier for the pool in the database.

Pool Status

Every pool comes with a Status button with the options to both “Disable Pool…” and “Disable Provisioning…”.

Ch09-poolstatus.png

These menus do change, especially if a problem occurs during the provisioning process. They can also be used to re-trigger the provisioning process if those issues have been resolved – you will see the status option change from Disable Provisioning to Enable Provisioning.

Un-assign Users from Dedicated Pools

One of the management issues of dedicated pools is un-assigning users. As you might recall, with a Dedicated Pool, a user is randomly assigned to a desktop from the pool when they first connect. This desktop then becomes their own personal desktop that they constantly reuse. This introduces a management issue – what if the user leaves the organization, or is reassigned to a different segment of the business where they need an entirely different virtual desktop for their work? This would leave the desktop assigned to the original user, with no other user able to access that desktop. Essentially, the desktop becomes a wasted and orphaned resource in the pool. If you select the pool and navigate to the Inventory tab, the “More Commands” button exposes this option:

Ch09-unassignusers.png

Maintenance Mode – Taking a Desktop Offline

As you can see from the screen grab above it is also possible to manually, on a per-desktop basis, disallow access to a specific desktop owned by a user on a dedicated pool. This does not disconnect and log out the user if they are already connected, but if the user logs out and tries to log in again, the View client tells them that their desktop is unavailable:

Ch09-maintmode.png

Resetting a Desktop

Warning:

This is quite a dangerous option as no prompt is sent to the user that this is about to happen. If a virtual desktop for whatever reason becomes completely unresponsive, such that the user cannot interact with it, it is possible from the View management console to hard reboot the VM. This does NOT perform a graceful shutdown of the VM, and therefore any files the user has not saved will be lost. Remember, it’s not a default pool setting that users can reset their own desktops unless you grant it. If you don’t grant the permission, you will find the option to “Reset Desktop” in the View Client Toolbar will be dimmed.

Ch09-resetdesktopdimmed.png

Remember, to grant your users this privilege, you would edit the pool settings, navigate to the “Pool Settings” tab, and change “Allow users to reset their desktops:” to Yes.

Ch09-enableresetmode.png

If you do decide to use the reset option from the View administration tools, you will see this message when you click the option:

Ch09-resetvm.png

The actual user experience is actually quite unpleasant. Here’s what happens. When you perform a reset of the virtual desktop, the VM is hard rebooted. In Windows 7 this can be sometime detected as a fault, and cause Windows 7 to enter its repair mode. From the end-users perspective for a short period the session stays open. This is because the display protocol will complete a retry process that keeps the presentation on screen for a while in the hope that the connection will be re-established. If the user has any open and unsaved files, these applications will prompt the user to save their files. However, it will be too late. The user won’t be able to interact with their session because it isn’t there anymore. After a short period, the client session ends unceremoniously – leaving the user with this rather blunt message:

Ch09-resetmessage.png

With the PCoIP protocol no such message is generated and the user is bombed out of the session without notification.

Remove a Desktop

Right next door to the Reset button on a desktop is the Remove option. This can be used to delete a virtual desktop from the pool. It will cause the user to take a new desktop from the pool as their original desktop was destroyed. Additionally, because a desktop has been removed from the pool, it’s likely to trigger the creation of a new desktop based on the pool’s provisioning settings (max, spare and min). If you click the Remove button whilst a user is connected, View will display a dialog box like so:

Ch09-removedesktop.png

When you are removing a desktop you can choose between removing the VM’s from View Manager only this will ensure the virtual machines remain in the vCenter or to Delete VM’s from disk which. You are also able to choose if you wish to terminate any sessions as displayed above or you could decide to be less intrusive and let the session carry on – in this case the desktop would be deleted only when the user finished their session and logged out. With the option “Terminate” as with the reset, this is very intrusive to users, as their session is unceremoniously ended without any opportunity to save data, and the VM is then powered off and deleted. If there is spare capacity in the pool, the user will be able to reconnect to View and will simply be allocated a new desktop from the pool.

Remote Session Management

More options exist for managing user sessions from the aptly named Sessions tab that appears on the pool’s properties. The sessions are filtered by remote sessions (RDP/PCoIP), Local Sessions (Basic) and Local Sessions (Transfer). From the Session tab, it’s possible to Disconnect, Logoff, Reset and Send Messages to actively connected users. From the screen grab below, you can see all these options. Notice how the Duration column indicates that there may be a time problem with a VM if it comes up with the message “Clock Skewed”, and that my user has connected using PCoIP rather than RDP.

Ch09-sessionmgmt.png

Important: As you have probably gathered, the View administration pages do not automatically refresh. So it’s possible to try to disconnect, logoff, reset or send a message to a session that simply doesn’t exist anymore. So, click refresh if you have been in these pages for a while

  • Disconnect – Merely closes the user’s window on their virtual desktop. The user is not logged out of their VM, and files remain open in the virtual desktop. No prompt is sent to the uses that you are about to disconnect their session
  • Logoff – Logs the user out of their VM. No message is sent to the user that they are being logged off, however they are prompted briefly to save any data. If they don’t respond in a timely fashion, or are unable to, the session terminates the applications within the virtual desktop without saving their data
  • Reset Virtual Machine – Covered earlier
  • Send Message – This sends a popup message to the user that appears within the virtual desktop. The UI allows you to categorize your messages into three types (info, warning and error). As with all messaging systems it’s wise to engage your brain before sending messages to your management team. With great power, comes great responsibility!

Conclusion

In this chapter we have covered some of the tasks that you will need to be aware of when managing desktop pool in VMware View, one of the most important take always from this chapter is to be sure you know the consequences of each different pool action before running ahead and disrupting your users. In our next chapter we will be looking at VMware’s “Linked Clones” technology. This a much more efficient method of creating desktop pools that merely cloning of templates allows for. We have written two chapters on the subject – the first involves there initial setup and configuration – the second concerns their longer term management.

Source: http://www.mikelaverick.com/wiki/index.php?title=Managing_Pools_and_Desktops