The caveats of running vCenter within a VM has been written about to death. So I will mention only what I never found in those posts that is relevant to the environment within which I work:

greater virtual performance over physical

Not every environment is large enough to dedicate a whole 8/12/40/96 GB of RAM Blade to a vCenter. Its simply a waste; the premise on which people dive into virtualisation is that green feeling, saving the environment or the saving the USD.
So businesses tend to ‘donate’ a physical box that will be the nucleus of their virtual offering. Yet this tends to be an underpowered, not-far from decommission door stopper.
As a Virtual Machine, you’re able to utilize the benefit of prompt resizing of the hardware, and at the ability to easily place it on higher-powered machines.

That’s the benefit, although what REALLY happens when you decide to move your vCenter around?

vMotion Mission Statement:

… Storage VMotion lets you relocate virtual machine disk files between and across shared storage locations while maintaining continuous service availability and complete transaction integrity.

To me, that reads – “stuff will happen while we move your data”.

Unfortunately that isn’t always the case. Here’s the scenario.

Host
- DS1
- DS2
- DS3

vCenter was living on DS1 (slow-LUN), and I wanted to put it across to DS2. Since vCenter is very important, it’s continuous service availability is crucial. Read: {perfect candidate for svMotion}.

The message that never went away

What happened next is counterintuitive to the credo. The vSphere client freezes, and no new connections can be made to vCenter. If you start monitoring the datastores (kudos to VMware) the VM is actually being transferred.

Once the migration completed, the first time I had to reconnect the vSphere Client; I wasn’t happy with this outcome. So I attempted a DS2->DS3 (both fast-LUNs). Not only did my connection to vCenter not drop this time, but the whole process was seamless and worked as advertised.

vCenter Migration

I ended up moving the VM in which I house SQL Server (vCenterDB) in the same fashion to the faster LUNS, and everything proceeded to operate as designed.

Lesson learnt: get decent storage.

… go with me here.

You are going to have black caviar (highly recommended). You were provided with 50 grams; you figure you can fit at most 45 grams onto the piece of that delicious dark-rye. So what do you do? Do you disregard and thus throwout the 5 grams? … Well it’s not important what YOU would do, its important what VMware does!

Mr. ESX tends to look at the excruciatingly expensive, sustenance-providing caviar, and throws out the majority that it can’t handle, and opts for the remains in the hard-to-reach crevices of the jar.

What does this all mean for the geek?

There’s a decrepit limit of 2TB minus 512 bytes for each LUN that you can present to ESX. Anything larger, it has no love for. So if you were to present it with a 4TB LUN, you would naïvely assume that you would get the bastardised version of 2TB and the rest would be lost in the ether. I guess that would be somewhat logical.

Lets try it:

Capacity vs. Available Space

There you have it. Instead of actually using up as much as ESX’ly possible (~2TB) from a LUN that has been allocated, VMware chose to only pick up the left-overs (~500GB).

If you’re ever in a situation where you’ve moved the vCenter database, and have actually changed the login details for the database that the DSN points to, and you’re using SQL Server. Then upon re-installing vCenter, you will be greeted with:

“Database job [Past day stats rollupvcenter] was created by another user. Please use the same user to setup your DSN or remove the job. ODBC Error: [Microsoft][SQL Native Client][SQL Server]The specified @job_name (‘Past Day stats rollupvcenter’) does not exist.

When vCenter is first installed, it schedules jobs with the help of the system DB – MSDB. What’s left to do, is just remove the jobs created by the previous dbo of your vCenter data. You achieve this by first listing what jobs are created on the SQL Server.


SELECT [job_id],
[originating_server_id],
[name],
[enabled],
[description],
[start_step_id],
[category_id],
[owner_sid],
[notify_level_eventlog],
[notify_level_email],
[notify_level_netsend],
[notify_level_page],
[notify_email_operator_id],
[notify_netsend_operator_id],
[notify_page_operator_id],
[delete_level],
[date_created],
[date_modified],
[version_number]
FROM [msdb].[dbo].[sysjobs]


As you can see, four scheduled operations exist. Thankfully you don’t have to worry about just clearing this table, as there’s a stored procedure that comes within MSDB -> sp_delete_job

Run it for each of the jobs, and you’ll be ready to continue installing vCenter.

LabManager is a great product for when you have to deal with provisioning of images in a hands-off fashion from the IT team. If you’re already a vSphere shop, users don’t need access to a vSphere client and can manage the lifecycle of their machines through the browser (Windows only though for the console).

For what I’m building, I needed access to the API provided by VMware, and unfortunately, it is only provided as a SOAP interface. The documentation is a given, although it is of quite a poor standard. Since case-sensitivity is a must, not to mention correct parameters.

So how do we go about creating an easy to use PHP page which would consume the .NET WebService?

<?php

print_r($result);

?>

After using some of the methods, I decided to write a wrapper for the LabManager’s API, so I could use it within other applications we develop inhouse. You can then call this directly from the command line, and integrate it with your bash/perl – and not have to re-invent the wheel.

As such – I present to you phLabManager – “Simple, lightweight wrapper for LabManager 4.0 SOAP API” written in PHP.

Once you’ve grabbed the labmanager.php, you can write quite succinct calls directly to the methods, without worrying about the implementation. There’s an example on usage available.

I haven’t finished implementing all the methods, and in the coming days will endeavour to do so, alternatively – you can do it, and commit into the tree. It would be great to get some help in optimizing my rough implementation.

In the unfortunate scenario that the machine you use to run your vSphere client ever crashes (unfortunately VMware doesn’t make an OSX Client), you may wish to start up the client, and click the performance tab. You may be greeted with the following when selecting the “Performance” tab:

Unexpected end of file has occurred. The following elements are not closed

This is due to a file which hosts all the chart settings (an XML-based key value pair collection) becomes corrupt, and is actually cut off.

Its quite easily found at : c:\Documents and Settings\user_name\Application Data\VMware\server_name-charts.xml

From here, you have several choices:

• revert to a backup
• delete it
• clear it (just place <ChartSettings /> inside of it)

That’s all there is to it. Happy vSphere’ing

“FAILED: The object or item referred to could not be found” is the extremely helpful message that VMWare converter displays when it fails.

Digging deeper, within the logs we can see that there are multiple instances of

“Warning: failed to create directory” and “Warning: failed to clone directory tree”.

The simple work-around is to convert the vmdk disk to a monolithic-sparse.

You can do this by issuing:

$ vmware-vdiskmanager -r original.vmdk -t 0 destination.vmdk

This will clone the disk image as well as modify it from being composed of 2GB files for the entirety of your VM to a single vmdk referred to as a ‘monolithic-sparse’ (merely referring to the fact that it will increase in size automatically to encompass the the VM partition).

After completing the cloning process, you should have no problems in restarting the conversion process, and it should complete as advertised.