As you can see below, the Core dumps is full. It shows 100%.
To empty it, simply login to the appliance via SSH.
It’s a matter of deleting them. The result is a clean directory
And the core dump now shows a healthy usage.
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.
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.
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:
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:
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:
You can skip this step, if your Image-Profile version has also been updated and look like this:
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
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.
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.
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.
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:
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]
Ensure that the last line of the command returns with ‘Updated object’ before moving on to the next step.
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 firstname.lastname@example.org 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.
Navigate to Home > Administration > Single Sign-On > Configuration page
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.
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.
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.
Staying logged in with the email@example.com 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.
When the ‘Add Principals’ wizard pops up:
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.
Using the Select Users/Groups wizard:
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.
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.
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.
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.
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:
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.
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!
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!
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.
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:
During the bootup procedure you will see
Hostname or IP has changed. Regenerating self signed certificate.
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.
Every pool comes with a Status button with the options to both “Disable Pool…” and “Disable Provisioning…”.
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.
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:
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:
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.
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.
If you do decide to use the reset option from the View administration tools, you will see this message when you click the option:
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:
With the PCoIP protocol no such message is generated and the user is bombed out of the session without notification.
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:
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.
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.
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
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.