svmotion said NO!

Today we were needing to a do a full restore of one of our servers; however, we did not have enough space on the LUN to take a snapshot of the system disk of the VM and perform a full restore.  So I decided I would svmotion the VM system disk to another LUN.

svmotion said NO!

It seems, if a VM has independent-persistent disks, svmotion will not move any virtual disks, even if the independent-persistent disks are remaining on their original LUN.  I currently do not have my vSphere 4.0 RC hosts connected to a SAN, so I can not test if this is still the case in vSphere 4.0.

Advertisement

So you say to use Update Manager

Update Manager 1.0 is great.  Automatic update downloads.  Compliance baselines.  Support for VM and ESX host patches.

Sure there are some issues, such as downloading updates for ESX 3.0.3 and ESXi even though none of these versions exist in my Datacenter (I hear this is fixed in vSphere 4.0, though I can’t confirm as the Update Manager RC crashes when trying to run with domain credentials).

Now to what I’m hear to talk about.  Using Update Manager to update hosts across a WAN.  When you have a few patches to push, it works great.  Slow, but it works.  So what do you do when you have 2GBs+ of patches to install on 24 hosts located across 7 different states?

PATCH DEPOTS!!!

Here is what I did to update my 24 remote hosts.  I copied all the patches that were downloaded since my last update back in June of 2008 to a folder on a VMFS volumes at each location.  I also copied the contents.xml.sig and contents.xml files to this directory as well.  I then logged on to each host using ssh and ran esxupdate to patch the hosts.  Now, you have to run esxupdate from the patch depot, or you have to specify the location when executing esxupdate.

So from the patch depot, you would execute esxupdate -b ESX350-Update04 –test update to first test the installs.  Then run esxupdate -b ESX350-Update04 update to update the servers.  And I have to say, this patched the servers a lot quicker than through Update Manager.  Reading on the VMware Communities, it seems any patch that restarts hostd, Update Manager waits 10 minutes before installing the next patch.  This is not an issue with esxupdate on the host itself.

In vSphere 4.0 Update Manager, it seems like Update Manager has the ability to utilize patch depots at different locations, but I believe the patch depots reside on a host, not on a SAN LUN.  Again, I can’t confirm this just yet as the Update Manager RC isn’t running for me right now.  If the patch depot does not reside on a SAN LUN, I think I’ll be submitting a feature request for this to happen.  Sure residing on a host is at least on a step in the right direction, but why push patches over the network when each host has access to the same LUNs on the SAN?

Fixing my Update Manager issue

I recently upgraded vCenter to 2.5 Update 3, and this was my first time using Update Manager to update the hosts at one of my sites to ESX 3.5 Update 3 since the vCenter upgrade.  I migrated all the VMs off my “test” system, and ran an Update Manager scan to see which updates needed to be applied.  And this is when I saw this error message:

VMware Update Manager had a failure.

So I preceded to try again.  Same error.  Restart the service on the vCenter server.  Same error.  I stopped the service to look at the logs, and I see a SQL error regarding a foreign key constraint.  Searching for the error on Google, VMware, etc., I came across KB1007512.  This is the exact issue I had seen.  So following the KB, I had to let all the ESX/ESXi updates re-download.

Fast forward a couple of hours to the completion of the re-download of 5.70GB of updates.  I restart the Update Manager service and rescan my host.  I receive the same error:

VMware Update Manager had a failure.

Stop the Update Manager service once again.  Upon inspection of the log files, I see a different SQL error, this time about duplicate primary keys.  Search Google, VMware, etc.  Nothing.

I really wanted to push this off till the morning, but with the hectic schedule I had the next day, I decided to use my trusty VMware Support.  Gave them a call, and after uploading various log files to the support team, they had a fix for my issue.  In the Update Manager database, there are two tables: VCI_SCANHISTORY and VCI_SCANRESULTS.  The identity value for VCI_SCANHISTORY must be larger than the identity value for VCI_SCANRESULTS.  Running SELECT MAX(ID) FROM for VCI_SCANHISTORY and VCI_SCANRESULTS showed the identity values to be 20 and 134, respectively.  The fix was to issue the following command:

DBCC CHECKIDENT (“VCI_SCANHISTORY”, RESEED, 135)

This command reset the identity value of VCI_SCANHISTORY to 135.  With the identity value reset, I restarted the Update Manager server and successfully scanned my host to begin updating.  Thanks to VMware Support, I was able to go to bed at a reasonable hour.

My beef with Update Manager

First, I’ll start off with what caused me to make this post.

KB Article 1007512 – Scan of host fails after upgrade to Virtual Center 2.5 Update 3.

The resolution to this KB article is to rename the hostupdate folder and let Update Manager download all the ESX patches again.  5.60 GB worth!!!  So, without further ado, here are my beefs with Update Manager:

1. Update Manager is not smart enough to know I do not have any ESX 3.0.3 hosts in my cluster.  Furthermore, there is no option to disable downloading ESX 3.0.3 updates.
2. Unlike with Windows hosts where Update Manager only downloads the updates that are needed as per the baselines, Update Manager downloads every ESX update available, even if it’s not needed.
3. Resolution to KB 1007512
4. No ability to schedule reboots when patching a Windows host.  You can schedule when a patch will be pushed to a Windows host, but you can not push patches and then schedule a reboot for a maintenance window at a later time.
5. Unable to have more than one patch repository (would be very useful in networks with one VC server, but multiple clusters located across a WAN).

Now, Update Manager is a really good product for a 1.0 version.  I hope to see some of these changes in future releases of this software.

Another blog….so what…

Another blog is created.  Will anyone notice?

So what is this all about?  I’m looking to share my ideas and thoughts on virtual datacenter design and networking layouts.  Every now and then, other non-related information may be posted.  If anyone finds a use for my ideas, I’ll be more than happy to accept a beer as payment.  I’m a VMware VCP living in South Louisiana working towards the VMware VCDX.  I’m currently waiting for my Enterprise Exam to be scheduled.