Archive

Archive for December, 2011

PowerCLI Advanced Configuration Settings – Setting Host Syslog options

December 16th, 2011 2 comments

 

This is a PowerCLI script that will script setting up your ESXi host syslogging in two places: A Shared Datastore (that all ESXi hosts have visibility of) and to a remote Syslog host on the network. Alternatively, you could set it to change the Syslog directory to a different local path on each ESXi host (rather than the default). The two advanced configuration settings we’ll be working with are:

 

  • Syslog.global.logDir
  • Syslog.global.logHost

 

Why did I do this? Well, tonight I got a little sidetracked after looking into a small warning on a new scripted ESXi host I deployed – it had not automatically set up logging during installation, my guess, was because it’s local datastore had failed to initialise during installation – I couldn’t see a local datastore after deploying it via a script and had received a warning during installation. I went ahead just to see what happened. This was a new test host in my home lab. So afterwards, I decided I would set it up a remote Syslog location to clear the warning off. Naturally, I wanted to do this in PowerCLI.

 

The following script will take a few options you specify like Shared Datastore name, Syslogging Folder Name, and a remote Syslog host, and go ahead and configure all the ESXi hosts in your specified DataCenter object to use these options you specify. If you have only one datacenter object the script will see this and use that one by default. Otherwise it will ask you for the name of the specific DataCenter you want to work with. It will then create a “ESXi-Syslogging” folder on the shared datastore you specified (if it doesn’t already exist) and under this, create a sub-folder for each ESXi host. It will then configure each ESXi host to send it’s Syslog info to this datastore. As far as I can tell, certain Sysl0g files are linked from /scratch/log on each ESXi host to the datastore specified. For example:

 

usb.log becomes:

usb.log -> /vmfs/volumes/1bec1487-1189988a/ESXi-Syslogging/esxi-04.noobs.local/usb.log

 

Naturally, this wouldn’t be a good idea if the ESXi host could potentially lose access to this datastore, so the script will also specify a remote Syslog host to log to. If you don’t have one, check out the Free “Kiwi Syslog Server”. Here is the resulting script (download via URL below or just copy the script out the block):

Download Set-RemoteLogging PowerCLI script (836)

 

# Remote Syslogging setup for ESXi Hosts in a particular datacenter object
# By Sean Duffy (http://www.shogan.co.uk)
# Version 1.0
# Get-Date = 15/12/2011

#region Set variables up
$SyslogDatastore = "SharedDatastore2" # The name of the Shared Datastore to use for logging folder location - must be accessible to all ESXi hosts
$SyslogFolderName = "ESXi-Syslogging" # The name of the folder you want to use for logging - must NOT already exist
$RemoteSyslogHost = "udp://192.168.0.85:514" #specify your own Remote Syslog host here in this format
$DataCenters = Get-Datacenter
$FoundMatch = $false
$SyslogDatastoreLogDir = "[" + $SyslogDatastore + "]"
#endregion

#region Determine DataCenter to work with
if (($DataCenters).Count -gt 1) {
	Write-Host "Found more than one DataCenter in your environment, please specify the exact name of the DC you want to work with..."
	$DataCenter = Read-Host
	foreach ($DC in $DataCenters) {
		if ($DC.Name -eq $DataCenter) {
			Write-Host "Found Match ($DataCenter). Proceeding..."
			$FoundMatch = $true
			break
			}
		else {
			$FoundMatch = $false
			}
	}
	if ($FoundMatch -eq $false) {
		Write-Host "That input did not match any valid DataCenters found in your environment. Please run script again, and try again."
		exit		
		}
	}
else {
	$DataCenter = ($DataCenters).Name
	Write-Host "Only one DC found, so using this one. ($DataCenter)"
	}
#endregion

#Enough of the error checking, lets get to the script!

$VMHosts = Get-Datacenter $DataCenter | Get-VMHost | Where {$_.ConnectionState -eq "Connected"}

cd vmstore:
cd ./$DataCenter
cd ./$SyslogDatastore
if (Test-Path $SyslogFolderName) {
	Write-Host "Folder already exists. Configure script with another folder SyslogFolderName & try again."
	exit
}
else {
	mkdir $SyslogFolderName
	cd ./$SyslogFolderName
}

# Crux of the script in here:
foreach ($VMHost in $VMHosts) {
	if (Test-Path $VMHost.Name) {
		Write-Host "Path for ESXi host log directory already exists. Aborting script."
		exit
	}
	else {
		mkdir $VMHost.Name
		Write-Host "Created folder: $VMHost.Name"
		$FullLogPath = $SyslogDatastoreLogDir + "/" + $SyslogFolderName + "/" + $VMHost.Name
		Set-VMHostAdvancedConfiguration -VMHost $VMHost -Name "Syslog.global.logHost" -Value $RemoteSyslogHost
		Set-VMHostAdvancedConfiguration -VMHost $VMHost -Name "Syslog.global.logDir" -Value $FullLogPath
		Write-Host "Paths set: HostLogs = $RemoteSyslogHost LogDir = $FullLogPath"
	}
}

 

Some results of running the above in my lab:

 

Script output after running against 3 x ESXi hosts

 

Advanced settings are showing as expected

Tasks completed by the PowerCLI script

 

Here is the structure of the Logging in my Datastore after the script had run.

 

 

Lastly, I have found that these values won’t update if they are already populated with anything other than the defaults (especially the LogDir advanced setting). You’ll get an error along the lines of:

 

Set-VMHostAdvancedConfiguration : 2011/12/15 11:37:01 PM    Set-VMHostAdvancedConfigurati
on        A general system error occurred: Internal error

 

If this happens, you could either set the value to an empty string, i.e. “” or you could use Set-VMHostAdvancedConfiguration [[-NameValue] <Hashtable>] (using a hashtable of the advanced config setting as the NameValue) to set things back to the way they were originally. The default value for Syslog.global.logDir is = [] /scratch/log for example. It might be a good idea to grab this value and pipe it out into a file somewhere safe before you run the script in case you need to revert back to the default Syslog local location – you would then know what the value should be. You could use something like this to grab the value and put it into a text file:

 

Get-VMHostAdvancedConfiguration -VMHost $VMHost -Name "Syslog.global.logDir" | Out-File C:\default-sysloglocation.txt

 

Also, remember to think this out carefully before changing in your own environment – it may not suit you at all to set your Syslog location to anywhere else other than the local disk of each host. However, you may find it useful to automatically set the remote syslog host advanced setting for each of your ESXi hosts – in that case, simply modify the script above to only apply the one setting instead of both. I hope this helps, and as always, if you have any suggestions, improvements or notice any bugs, please feel free to add your comments.

 

 

Upgrading to vSphere 5.0 from vSphere 4.x – Part 3 – Using VUM to upgrade ESX(i) hosts

December 6th, 2011 No comments

 

Introduction

 

In Part 2 of this series, I covered the steps needed in order to manually upgrade your ESX(i) 4.x hosts to ESXi 5.0.0. This is useful for smaller deployments or lab set ups where you don’t have that many hosts to upgrade. However, with larger deployments, you’re going to want to look at a way of automating this process. VMware Update Manager (VUM) is one of these ways, and in this part, I’ll explain how to use it to upgrade your hosts to ESXi 5.0.0 by using baselines.

 

Using VMware Update Manager to upgrade ESX(i) 4.x hosts to 5.0

 

There is a little bit of ground work required to set up your ESXi 5.0.0 ISO image and create a VMware Update Manager baseline in this process, but once this is done, it is quite easy to attach your new baseline to your older hosts and remediate them against this (effectively upgrading them / bringing them up to date against this new baseline). To go through this process, you will of course need a VUM server. Update Manager comes with all editions of vSphere 4 and 5, so if you don’t already have it up and running, you should seriously think about deploying it, as it will save you a lot of time with otherwise routine, time consuming tasks when it comes to upgrading/updating Hosts, VMs, and Applications.

 

Start off by downloading the ESXi 5.0.0 ISO image to your vSphere Client machine if you don’t already have this. Once this is downloaded, you’ll then want to go to your vSphere client home screen and choose VMware Update Manager from the home screen.

 

 

This will load the VUM interface and provide you everything you need to work with Update Manager. Select the “ESXi Images” tab along the top, then click on the link called “Import ESXi Image…” In the wizard that appears, browse for your recently downloaded ESXi 5.0.0 ISO image and select it. Follow through the wizard to Upload the ISO to your VUM server. You may receive a security warning (SSL) which you will need to ignore/accept to continue. All going well, you should reach an “Upload Successful” point and see the details of your ISO, similar to the below screenshot.

 

 

Move to the next step, and we’ll now create a Baseline out of this Image. Tick the box for “Create a baseline using the ESXi image” and give it a meaningful name and an optional description. Finish the wizard when you have named the baseline, and you’ll now have a shiny new baseline with which you can use to remediate your hosts against.

 

 

Move along to the “Baselines and Groups” tab in the main VUM area, and verify that your new baseline is showing and that the details look correct. It should show up as a “Host Upgrade” under the Component column.

 

 

For the next step, we’ll be looking to attach this baseline to the older ESX(i) hosts that need to be upgraded. To attach to all your hosts in the same cluster all at once, go to your Hosts & Clusters Inventory view,  select your Cluster name, then go to the “Update Manager” tab near the end. From here, click on the “Attach” link as seen below:

 

 

Now, you’ll want to select the ESXi5 Upgrade Baseline we created in the previous steps to the selected Cluster. Simply tick the box next to your “Host Upgrade” Baseline name, then click “Attach”.

 

 

Now that your baseline has been attached, it will apply to all the ESX(i) hosts in the cluster. From the same Update Manager screen, click the “Scan” link to initiate a compliance scan. In other words, we’ll be looking to find out which hosts are not in compliance with our new ESXi 5.0.0 image, from which point we can move on to remediating (upgrading). Select the tickbox for “Upgrades“, then click “Scan” to continue. Once this is done, you should notice that all the hosts which have your baseline attached will show as Non-Compliant (unless you have manually upgraded any of these).

 

 

If you are ready to begin the upgrade process for your hosts, click on the yellow “Remediate” button on this screen.

 

 

 

You’ll now be taken to the Remediation Wizard / Selection screen. Tick (Select) which hosts you would like to remediate (upgrade) and ensure the correct Host Upgrade Baseline is selected, then continue on to the next step.

 

 

 

 

There are a few options that you will need to configure in this wizard based on your environment. Preferences such as Host and Cluster Remediation options can be set up, which control how your cluster and hosts should handle the remediation tasks. For example, Power State to put your VMs into, or Cluster features to keep enabled or disable. You can also define a schedule for remediation in this wizard if you wish.  Here is a quick rundown of the steps in this wizard that I went through, along with a couple of screenshots of the options I went with in my lab upgrade.

 

1. Selection screen

2. Read and Accept the EULA

3. Choose whether to remove third-party installed software that is incompatible with the upgrade or not.

4. Optionally, set up task name and description for the upgrade remediation task. Select Immediately, or specify a time to begin the task.

5. Choose how you would like to handle VMs for the remidiation. Note that these options also apply to hosts in clusters. I left mine at “Do not change VM Powerstate” as I have DRS set to fully-automated. Therefore VMs running on this host will be vMotioned off when the host enters maintenace mode, and I won’t need to worry about moving them myself.

6. Select how the cluster should be handled during remediation. For example you can disable DPM during remediation. It will be re-enabled after the task is complete.

7. Check summary and finish the wizard.

 

Host remediation options

 

 

Cluster remediation options

 

 

Checking through the summary and finishing off the wizard

 

 

Once you finish the wizard, your selected hosts will begin the upgrade (Remediation) process. Depending on the options you chose, your VMs should automatically be vMotioned off the current host being upgraded as it enters maintenance mode. If you’d like to follow along with one of the hosts, have a look at the server console to see how progress is made. Working with a cluster of hosts, you should be able to use this method to upgrade hosts systematically in an automated fashion. One of the benefits of this method is obviously along the lines of time saving, but also the fact that you can have zero downtime if it is done correctly. As each host is upgraded to ESXi 5.0.0, VMs can vMotion back to upgraded hosts, allowing you to shift the VM workload around hosts that need to go down for maintenance. Lastly, don’t forget to ensure your licensing is sorted out after the upgrades are complete.

 

In the next part, we’ll take a look at other tasks involved with an upgrade to vSphere 5.0.

 

More in this series:

 

Part 1 – Upgrading to vSphere 5.0 from vSphere 4.x – Part 1 – vCenter Server

Part 2 – Upgrading to vSphere 5.0 from vSphere 4.x – Part 2 – Manually upgrading ESX(i) hosts

 

Upgrading to vSphere 5.0 from vSphere 4.x – Part 2 – Manually upgrading ESX(i) hosts

December 4th, 2011 No comments

 

Introduction

 

In Part 1 of this series, I covered the steps needed to move your vCenter server over to vCenter 5.0, and outlined some points to consider or be aware of. For this post, I’ll be covering two different methods you can use to migrate your ESX(i) hosts over to ESXi 5.0. Which one you use really depends on how big your deployment is. For someone running a small deployment of just a few hosts, it may make more sense to manually upgrade each using an ISO. For others with larger environments, it would be prudent to use an automated method such as VMware Update Manager (VUM). I’ll be covering both methods over the next two posts (today and tomorrow), and will outline the process involved in each.

 

Manually upgrade ESX(i) 4.x to 5.0

 

This is a fairly straightforward process, and simply involves restarting each of your hosts in the cluster, one at a time and booting them off an ESXi 5.0 installer image. To start, you’ll want to prepare each ESXi host as you get to it, by entering it into Maintenance mode. This will migrate any VMs off and allow you to restart it safely with no VM downtime. Ensure all your VMs have vMotioned off before you begin. In my case, my ESXi hosts are virtual, so I simply mounted the VMware ESXi 5.0 installer ISO on each VM. For physical hosts, you’ll want to burn the installation ISO to CD/DVD and pop it into each host of course.

 

Boot off the ISO and select to start the standard installer

 

Once the Installer has loaded, choose the disk you would like to perform the upgrade on. All disks on the host that are VMFS should be marked with an asterisk for you to easily identify.

 

Choose the disk to upgrade

 

 

Press F1 to get the details of the disk you are going to upgrade during installation. The installer should detect your current version of ESX(i) as well as provide a bit of extra information in case you need to confirm you are upgrading the correct disk etc…

 

Viewing the Disk details

 

On the next step, you should get a few options relating to the type of action you want to take on the existing installation of ESX(i). For this type of upgrade, I’ll be choosing to Force Migrate my ESXi 4.1 host to ESXi 5 and preserve the existing local VMFS datastore.

 

 

After continuing, you may get a warning if there are any custom VIBs (VMware Installation Bundle) in your current ESX(i) installation that do not have substitutes on the install ISO. If there are, you should look into whether or not these will still be needed, or check that you have a contingency plan to re-install or reinstate the particular bit of software should you need to after the upgrade. I got a warning about some OEM VMware drivers, but I knew these were just related to the ESXi installation in a VM I am running, so I was happy to continue the upgrade process anyway.

 

Next up, you’ll just need to confirm you wish to Force Migrate to ESXi 5.0.0 on the specified disk you chose earlier.  The installer will also inform you as to whether you will be able to rollback the install or not. Press F11 to continue at this point if you are happy.

 

 

 

Once the migration / install is complete you’ll get the below message. Press Enter to reboot the host.

 

 

 

At this stage, once the host has booted up again, you’ll want to log into it using the vSphere client, or check on it through your vCenter connection in the vSphere client. Make sure everything is configured as you would expect and that it is running smoothly on ESXi 5.0.0. That is all there is to it really – provided all went well, you should have a newly upgraded host ready to run VMs again. The upgrade process is quite quick and straight forward. Test it out by vMotioning a test VM onto the new host and check that there are no issues. Tomorrow, we’ll look at performing more of an autonomous upgrade for your hosts to ESXi 5.0.0 using VUM (VMware Update Manager).

 

More in this series:

 

Part 1 – Upgrading to vSphere 5.0 from vSphere 4.x – Part 1 – vCenter Server
Part 3 – Upgrading to vSphere 5.0 from vSphere 4.x – Part 3 – Using VUM to upgrade ESX(i) hosts

 

Using dd to create and modify files (Windows or Linux)

December 4th, 2011 No comments

 

How do you create files filled with random data to a certain size specification, and then overwrite a specified portion of this data? I’ll show you how to do this in Windows or Linux. dd is traditionally a Unix program, however there is a Windows port available. I have used this in my testing, but the command line usage is pretty much identical for Linux or Windows. Grab the Windows port over here (I used the beta 0.6 version).

 

My requirement was to be able to create a large file, say 10GB in size, and then replace bits of that file with random data (for example change the first 5GB of data in that file with random data).

 

An example use case would be to test how Rsync works with data that has changed slightly. Another use case may be to simply just create large files on a virtual disk attached to a VM (VMDK) and to see how a Backup Solution would handle change block tracking to intelligently backup only the blocks of a VM that have changed. With dd, you can specify how big you want a file to be created as, as well as whether or not that should contain random data, zero filled data, or content from another file amongst other things. Of course there are many other uses for dd, including copying or cloning files, partitions and other data types of data. Just be careful when using dd at a lower level, as it has the ability to destroy data too of course! (This is probably where it earned one of it’s nicknames “Data Destroyer”)

 

So to get started, simply put the dd.exe file in the location you want to work with, or set up an environment variable for it. To create a 10GB file with random data, you would use the following from your cmd prompt:

 

dd if=/dev/random of=testfile.txt bs=1k count=10485760

 

“if” refers to your input, “of” is your output, “bs” is your Byte Size and “count” is how many of these you want in your output.

 

Now, the cool part – using dd to overwrite a certain amount of your existing file:

 

dd if=/dev/random of=testfile.txt bs=1k count=1024 conv=notrunc

 

The above command would overwrite the beginning of the 10GB file with just 1MB (1024 count multiplied by 1KB) of random data. Notice the conv=notrunc bit – this means “do not truncate the output file”, or in other words if the output file already exists, it should only replace the specified bytes and leave the rest of the output file alone. It goes without saying that if you are overwriting data, you should specify the output as being an existing file.

 

If you would like to create a 1MB zero-filled file, simply use:

 

dd if=/dev/zero of=testfile.tst bs=1k count=1024

 

To create a file with content based on another file, you would use something like this:

 

dd if=samplefile.txt of=newfile.txt

 

Lastly, a useful parameter that I found is the –progress parameter. This is especially useful for large operations, giving you a visual size/percentage progress indicator on the current operation. Example:

 

dd if=/dev/random of=testfile.tst bs=1k count=10485760 --progress

 

Here is the output after creating a random 10MB file with progress indicator in cmd prompt.

 

Categories: How-tos Tags: , , , , ,

How to move your VMware vCenter Server database (SQL)

December 2nd, 2011 No comments

 

My vSphere 5 lab at home had been feeling a little sluggish when it came to running the vSphere client and working with vCenter – I could see that the drive where my vCenter DB was running (SATA) was taking a bit of hit when I accessed Performance graphs and the like from vCenter. I had a little bit of free SSD storage on another drive (OCZ Vertex 2 SATA drive) that would be perfect for my vCenter DB size, so in the search of better performance in my lab, and a bit of a practise run at moving the vCenter SQL database, I set about moving just the SQL databases on the VM to a new, dedicated SSD-based VMDK. This also meant that I didn’t take up too much space moving the entire VM across to SSD storage, as this kind of storage comes at a premium!

 

This post will cover the process I followed for SQL Server 2005 Express. Most labs environments are likely to be running this edition, especially if you upgrade the lab from vSphere 4.1. The steps are quite similar for a SQL 2008 database, but there are differences, so just make sure you follow the correct KBs if you are on a different edition of SQL Server. Here is the high level overview of what was involved in the whole process.

 

High level overview: vCenter 5 steps on SQL Server 2005 Express

 

  • Shutdown lab and make a full clone of the vCenter VM. Power back up again afterwards – Always good to have a rollback plan!
  • Added a new disk to the VM, located on my SSD-based storage.
  • Backup all my SQL databases on the vCenter VM along with the System databases.
  • Noted down all credentials that vCenter uses to connect to the SQL database and checked I was familiar with all my ODBC settings just in case any of these needed changing or updating.
  • Stopped vCenter and VUM services
  • Performed database move steps carefully, verifying everything each step of the way.
  • Started vCenter and VUM services back up and check all was working as expected.
  • Note that there are some additional considerations if you are planning on moving a vSphere 4.x database. Refer to the VMware KB linked below for more info if you are on vSphere 4.x

 

VMware have a fairly high-level KB on moving your vCenter Server SQL database. You can take a look at it over here to see if you need anything else.

 

The Process

 

  • After making a clone of my vCenter VM, backing up all my SQL databases on the vCenter server, and stopping all my VMware specific services, I started with the Microsoft specific steps for moving a SQL 2005 database.

 

  • First off, you need to detach the VIM_VCDB database. Execute the following SQL query in SQL Server Management Studio:

 

use master
   go
   sp_detach_db 'VIM_VCDB'
   go

 

  • After this query completes successfully, move your VIM_VCDB.mdf and VIM_VCDB.ldf files to the new location (where you are moving the database to). Once moved, go back to Management Studio and execute the next query which will reattach the database. Of course you will need to specify the path your database is now going to be located in – the example below references the path I used.

 

use master
     go
     sp_attach_db 'VIM_VCDB','D:\VCDB_SQLDATA\VIM_VCDB.mdf','D:\VCDB_SQLDATA\VIM_VCDB.ldf'
  go

 

  • After this query is successful, you can run the next stored procedure, which should return the new location of your database, provided it has been moved and reattached correctly.

 

use VIM_VCDB
go
sp_helpfile
go

 

  • Now that the Database has been moved, you should be good to start your vCenter services back up again and do some testing to ensure everything is working as expected.

 

Extra steps

 

If you would also like to move your System databases, things get a little more complex. First off, you will need to make sure your management studio is set to only open up a SQL query window on startup. (Tools -> Options -> Environment -> General ->At Startup -> Open new query Window) this is so that when we enter single-user mode for the SQL Server service (part of moving the System DBs), we don’t get errors trying to run our scripts – as by default SQL Server Management Studio tries to make a SQL connection for it’s object explorer, as well as for your query when you execute it. This means you’ll get an error message as there would already be an active SQL connection using the Object Explorer before you can execute your queries to move the System DBs. The Microsoft KB does not explain this, and it took me a little while to realise that this was the problem, so don’t forget to change this before starting! The rest of the steps can be followed through in this MSDN Article on moving SQL Server System Databases. Just make sure the correct edition of SQL Server is highlighted at the top of the page before you begin.

 

The System Databases include:

 

  • Model
  • MSDB
  • Master
  • Resource
  • TempDB

 

Another tip when moving the System databases that was not mentioned in the Microsoft KB article, and will cause you to get stuck unless already configured, is to set the correct permissions on the new folder your SQL System databases are going to be sitting in. There is a local security group on your SQL server that needs to be assigned “Full Control” on your new System database location. If it doesn’t have this permission, then you will get errors when you try to start services up again. See screenshot below for the service name (the name of this security group depends on the name of your Server and SQL Service):

 

 

That should cover the whole process, as well as provide a few tips on the areas I initially got stuck on (that were not explained in the official Microsoft KBs). If you have a different edition of SQL Server, just switch the MSDN article to the relevant edition and take it from there. Good luck!