Jase's Place

We'll, I hadn't blogged about it yet, but I recently had the opportunity to be a Co-Author on a new book about VMware ESX.

The title is VMware ESX Essentials in the Virtual Data Center. It details VMware ESX, VirtualCenter, and how they interact with each other and a network infrastructure. There are some tips and tricks, as well as some in depth content about their architecture, as well as how to use them, with some best practices mixed in.

I was very fortunate to be a part of the book, and I truly appreciate the opportunity that Steve Beaver and David Marshall gave me by bringing me into the project. Also, I want to extend thanks to the publisher, as they were very gracious in the process of publishing this book.

We're going through the finalization process, and we hope to have the book on shelves as soon as possible. I understand it will be available before VMworld 2008.

I hope that everyone who gets a copy, will find the content useful, and enjoyable to read.

Thanks,
Jase

Labels: VMware

Well, I've confirmed on my test system, that a Go Daddy wildcard certificate will work on a VI3 (VirtualCenter 2.5 & ESX 3.5) system.

Let's say you already have a wildcard certificate in place on an IIS web server, and you'd like to use it in your VI3 environment.

First you'll need to export the cert from your IIS box, using the Certificates snap in.

Right click, then All Tasks, then Export, and Next on the first screen

Select "Yes, export the private key

"Personal Information Exchange - PKCS #12 (.PFX)" should be selected
And "Include all certificates in the certification path if possible" should be checked.

Enter your password here

Enter a filename for the exported cert. I called it wildcard.pfx

Click finish.

Now you'll need to use OpenSSL to convert the file you just generated.

I ran the openssl.exe from the path on my test system (C:\openssl\bin)

C:\openssl\bin\openssl.exe pkcs12 -in wildcard.pfx -out wildcard.txt -nodes. You will be asked for the password you entered when you were exporting the pfx.

Now open the wildcard.txt with Wordpad (notepad won't work). I use Win32Pad instead.

Grab the portion with the following:
-----BEGIN RSA PRIVATE KEY-----
(Block of Random Text)
-----END RSA PRIVATE KEY-----
And save this (notepad is fine for this) as rui.key

Grab the portion with the following:
-----BEGIN CERTIFICATE-----
(Block of Random Text)
-----END CERTIFICATE-----

And save this (notepad is fine for this) as rui.crt

Make sure you make a backup of the existing keys, in the case that something goes wrong with this process. They are located in the c:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL folder.

Now, rename the wildcard.pfx to rui.pfx. Copy rui.pfx, rui.crt, and rui.key files, to the above folder.

You'll then need to reinitialize the vpxd password. Run "vpxd.exe -p" again from a Dos box in the following folder:
c:\Program Files\VMware\Infrastructure\VirtualCenter Server

Then restart your VirtualCenter service.

You should then be able to log into your VirtualCenter server using a wildcard certificate.

Additionally, you can upload the rui.crt and rui.key files to your ESX host (using WinSCP) to the /etc/vmware/ssl/ path. Make sure you back these up too.

I then restarted my ESX 3.5 system, and it started to use the wildcard certificate as well.


As always, If you wish to use this method that I have seen success with, feel free to.
By using the methods I have described, you agree that I will not be held liable for any issues in your environment.

Enjoy.

Labels: VMware

Well, it may not be supported, but ESX 3.5 does install on an IBM x440.

This isn't the first time VMware ESX has not been certified on an IBM x440.

When ESX 3.0.0 came out, there was a small outcry on the VMTN forums (by those of us that have them) about these boxes being supported, as they were close to End-Of-Life, but still represented significant investments.

I spoke with my VMware SE many times about it needing to be supported. He said that it "Should" run on it, despite the fact that it wasn't officially supported.

Several months after the initial uproar, VMware certified ESX 3.0.0 to run on an IBM x440.

Well here we are again, 3.5 just came out on 12/10/07, and yet again, the x440 was left off the hardware compatibility list.

A coworker bought a quad proc (1.4GHz Xeon) x440, for personal use, and we fired it up.

Low and behold, ESX 3.5 does install, and the VMkernel loads.

Even though the HCL recommends a minimum 1.5GHz cpu speed, the installation didn't seem to care that this box was a wee 100MHz shy of the minimum recommended cpu requirements.

He hasn't loaded any VM's on it yet, as it was late in the day, and we didn't get around to it. From initial indications, it looks like ESX 3.5 may just run on an IBM x440.

I'll post more when I get more info, as to how well this runs...

Labels: VMware

Looking for an alternative (free) Connection Broker solution I stumbled across Crossroads.

It is a little application that will run on pretty much any current Linux/OSX build, and will load balance specific IP’s, ports.

Just because I wanted something quick and easy to test this on, I downloaded Ubuntu Desktop 6.0.6 LTS to try it out on.

Download Crossroads here. I chose the 1.48 build, as it is the latest stable (at the time of this writing).

So, download it, to your Linux system, and unpack it, and install it.
I downloaded/copied it to /tmp, and installed it as follows:

Unpacking the archive
root@ubuntu:/tmp# gunzip crossroads-stable.tar.gz
root@ubuntu:/tmp# tar –xvf crossroads-stable.tar
root@ubuntu:/tmp# cd crossroads-1.48

Compiling/Installing Crossroads
(make sure you have a C compiler like gcc installed)
root@ubuntu:/tmp/crossroads-1.48# make install
root@ubuntu:/tmp/crossroads-1.48# touch /etc/crossroads.conf

Basic Configuring of Crossroads
edit /etc/crossroads.conf (with the below configuration)

service rdp {

port 3389;

revivinginterval 15;

backend one {

        server 10.1.1.100:3389;

        maxconnections 1;

        setserverheader "X-Real-IP: %r";

        trafficlog /tmp/backend.1.log;

       }

backend two {

        server 10.1.1.101:3389;

        maxconnections 1;

        setserverheader "X-Real-IP: %r";

        trafficlog /tmp/backend.2.log;

        }

}

I set the "maxconnections" to 1, because if I have XP/Vista desktops on the backend, I don't want someone attempting to connect to one that already has an active connection.

Starting Crossroads
/usr/local/bin/crossroads start

Checking the status of Crossroads
/usr/local/bin/crossroads status

Stopping Crossroads
/usr/local/bin/crossroads stop

Keep in mind, this is just a rudimentary implementation of Crossroads in a Connection Broker capacity.

The Crossroads documentation gives more parameters and information to have it start automatically at different run levels, allowed from/denied from, etc.

Additionally, the default Makedef.def is setup for a maximum of 20 connections. So, before you compile it, adjust the number accordingly.

The config file (/etc/crossroads.conf) also has many additional settings, that can customize the connections, including things such as allowed/denied addresses, etc.

The Web Interface
There is also a web gui that will display connections/etc.
To start it up, run /usr/local/bin/crossroads-mgr start PORT

So if you run /usr/local/bin/crossroads-mgr start 80, you should see something like this:



Now, in a production environment, I'd recommend creating a hardened Linux VM, and really tweaking /etc/crossroads.conf to get the best performance and security.

This could be a really viable solution in a small environment where costs play a significant factor.

As can be seen it really isn't hard to do, doesn't take long, and (by reading the docs) can be locked down enough to be a cheap (free) solution.

Labels: VMware

****************************************
Disclaimer: Keep in mind, this is the process that worked for me, and I don’t recommend that anyone perform this on live data, but rather to test data.

I am not responsible for any changes to your database as a result of this process.

If you choose to use this method, please backup your database beforehand.

All VC 2.0.x database references are called VirtualCenter and all VC 1.x references are called VirtualCenterOLD.

Also, this properly works with dbo as the owner of all tables. If you have an alternate owner (as I do) you will have to modify the below scripts to match.

****************************************

After performing a VC 1.x to VC 2.0.x upgrade, custom attributes are lost.

This is because the VC 1.x and VC 2.0.x databases handle custom attributes a little different. VC 1.x has a custom attributes table called VPX_FIELDDEF, and VMs and HOSTs have separate tables (VPX_VM_FIELDS and VPX_HOST_FIELDS respectively.

In VC 2.0 there are only 2 tables, VPX_FIELD_DEF and VPX_FIELD_VAL.

The VC 1.0 table VPX_FIELDDEF is replaced by VPX_FIELD_DEF in VC 2.0.x.

The VC 1.0 tables, VPX_VM_FIELDS and VPX_HOST_FIELDS are replaced by VPX_FIELD_VAL in VC 2.0.

To import the old values into the new database, a couple steps will have to be taken.

Let’s say I have a SQL 2000 database with my VC 2.0.x database named VirtualCenter.

I need to get to the tables from my old VC 1.x installation. So I need to restore the old VC 1.x database where I can get to the data I need. So I restore the VC 1.x database to a database (on the same server), with the name VirtualCenterOLD.

Now run the following script from Query Analyzer, while attached to the new VirtualCenter database:

USE VirtualCenter

GO

INSERT INTO dbo.VPX_FIELD_DEF

SELECT FIELD_ID AS ID, NAME

FROM VirtualCenterOLD.dbo.VPX_FIELDDEF

GO

This will pull all values from the old VirtualCenterOLD table named VPX_FIELDDEF into the new VirtualCenter database table named VPX_FIELD_DEF, thus defining our custom attribute fields.

Now, We need to add the data from the Hosts and VMs.

Now run the following script from Query Analyzer, while attached to the new VirtualCenter database:

USE VirtualCenter

GO

INSERT INTO dbo.VPX_FIELD_VAL

SELECT VirtualCenterOLD.dbo.VPX_HOST_FIELDS.FIELD_ID AS FIELD_ID, dbo.VPXV_HOSTS.HOSTID AS ENTITY_ID, VirtualCenterOLD.dbo.VPX_HOST_FIELDS.FIELD_VALUE AS [VALUE]

FROM VirtualCenterOLD.dbo.VPX_HOST LEFT OUTER JOIN

dbo.VPXV_HOSTS ON VirtualCenterOLD.dbo.VPX_HOST.HOSTNAME = dbo.VPXV_HOSTS.NAME LEFT OUTER JOIN

VirtualCenterOLD.dbo.VPX_HOST_FIELDS ON VirtualCenterOLD.dbo.VPX_HOST.HOST_ID = VirtualCenterOLD.dbo.VPX_HOST_FIELDS.HOST_ID

WHERE (NOT (VirtualCenterOLD.dbo.VPX_HOST_FIELDS.FIELD_VALUE IS NULL)) AND (NOT (VirtualCenterOLD.dbo.VPX_HOST_FIELDS.FIELD_ID IS NULL))

GO

This will insert HOST attributes into the VPX_FIELD_VAL, where the FIELD_ID and VALUE come from the old data, and the ENTITY_ID comes from the new Entity value for the ESX Hosts in the new database, making sure that there are no nulls.

Now run the following script from Query Analyzer, while attached to the new VirtualCenter database:

USE VirtualCenter

GO

INSERT INTO dbo.VPX_FIELD_VAL

SELECT VirtualCenterOLD.dbo.VPX_VM_FIELDS.FIELD_ID AS FIELD_ID, dbo.VPXV_VMS.VMID AS ENTITY_ID,

VirtualCenterOLD.dbo.VPX_VM_FIELDS.FIELD_VALUE AS [VALUE]

FROM VirtualCenterOLD.dbo.VPX_VM LEFT OUTER JOIN

dbo.VPXV_VMS ON VirtualCenterOLD.dbo.VPX_VM.NAME = dbo.VPXV_VMS.NAME LEFT OUTER JOIN

VirtualCenterOLD.dbo.VPX_VM_FIELDS ON VirtualCenterOLD.dbo.VPX_VM.VM_ID = VirtualCenterOLD.dbo.VPX_VM_FIELDS.VM_ID

WHERE (NOT (VirtualCenterOLD.dbo.VPX_VM_FIELDS.FIELD_VALUE IS NULL)) AND (NOT (VirtualCenterOLD.dbo.VPX_VM_FIELDS.FIELD_ID IS NULL))

GO

This will insert VM attributes into the VPX_FIELD_VAL, where the FIELD_ID and VALUE come from the old data, and the ENTITY_ID comes from the new Entity value for the VM’s in the new database, making sure that there are no nulls.

This worked well for me, and I didn't lose any custom attributes for my 300+ VM's or my ESX Hosts.

Labels: VMware

Well, it looks like someone else looked into customizing the VirtualCenter customization process for Windows hosts.

Vincent Vlieghe, has a post, on his site, that details how to correct the customization process issue of always reverting to English-US.

Check out the article here.

Labels: VMware

Challenged with a MOM 2005 project, I have been trying to figure out how to get VirtualCenter alerts into MOM.

I didn't want to address using forwarded SNMP traps, as not everyone seems to compile the VMware MIBs too well.

VirtualCenter 1.x had the ability to run scripts, but it didn't pass any information. VirtualCenter 2.0.x still runs scripts, but also includes additional information. According to the VirtualCenter help, the following variables can be passed to a script:

{eventDescription} full formatted message for alarm triggering event

{entityName} name of the entity name where the alarm is triggered

{alarmName} name of the alarm that is triggered

{triggeringSummary} summary info of the alarm with triggering values

{declaringSummary} summary info of the alarm declaration

{oldStatus} alarm status before it is triggered

{newStatus} alarm status after it is triggered

{entityObject} inventory object as triggering alarm

Unfortunately, {entityName} and {entityObject} don't seem to work right now, but you can parse the {eventDescription} to get the object's name.

So with a little help from a .NET guy here at work, I was off, on my first VB.NET application. To be honest, it looks more like .vbs to me, but put it in VB.NET, and I guess it is VB.NET.

First, well need to compile the application. You can find a copy of it here. You'll need WinZip, or some other zip application to unzip it.

I've included the .exe in the zip, but feel free to delete it and recompile it. (I don't always trust everyone else's code).

Here's the basic contents of the VB application, a file called MakeEventCall.vb, and it includes the following code:

Imports System.Diagnostics

Module MakeEventCall

'******************************************************
'* MomApp.exe - 12/12/06
'* Jase McCarty
'* My first VB.NET application for the purpose of
'* sending VMware VirtualCenter alerts to the
'* Application Event Log of a VirtualCenter system
'* that has a Microsoft Operations Manager Agent
'* installed on it.
'*
'* This code may be redistributed, but must have
'* this disclaimer included. Agreement to use
'* this code, absolves me from any liability.
'******************************************************

Sub Main()

'Variables for doing our work
Dim separators As String = "-"
Dim strIncoming As String = Microsoft.VisualBasic.Command()
Dim argCount As Integer
Dim args() As String = strIncoming.Split(separators.ToCharArray)
Dim MessageOutStart As Integer
Dim strMessageOut As String
Dim strFullMessage As String = strIncoming
Dim strApplicationName As String = "VMware VirtualCenter"
Dim objName As String

'Variables for our potential input parameters
Dim eventDescription As String
Dim entityName As String
Dim alarmName As String
Dim triggeringSummary As String
Dim declaringSummary As String
Dim oldStatus As String
Dim newStatus As String
Dim entityObject As String


'Don't do anything, unless we get at least one argument
If UBound(args) > 0 Then

'Blank our Output Message
strMessageOut = ""

'Loop through all our arguments, and process them
'Each argument should read something like this in
'the VirtualCenter Alert settings:
'
'momapp.exe -ed:{eventdescription} -ns:{newstatus} -an:{alarmname}
'
'Where the 2 letter argument prefix matches up with
'the appropriate event item.

For argCount = 0 To UBound(args)

Select Case Left(args(argCount), 2)
Case "ed"
eventDescription = Right(args(argCount), Len(args(argCount)) - 3)
Case "en"
entityName = Right(args(argCount), Len(args(argCount)) - 3)
Case "an"
alarmName = Right(args(argCount), Len(args(argCount)) - 3)
Case "ts"
triggeringSummary = Right(args(argCount), Len(args(argCount)) - 3)
Case "ds"
declaringSummary = Right(args(argCount), Len(args(argCount)) - 3)
Case "os"
oldStatus = Right(args(argCount), Len(args(argCount)) - 3)
Case "ns"
newStatus = Right(args(argCount), Len(args(argCount)) - 3)
Case "eo"
entityObject = Right(args(argCount), Len(args(argCount)) - 3)
End Select
Next

Dim objEventLog As New EventLog

Try
'Register the App as an Event Source
If Not objEventLog.SourceExists(strApplicationName) Then
objEventLog.CreateEventSource(strApplicationName, "Application")
End If

objEventLog.Source = strApplicationName

'This could be modified to include other information from above
strMessageOut = "Alarm: " & alarmName & vbCrLf & _
"Event: " & eventDescription & vbCrLf

'Include the appropriate warning level. If the -ns:{newstatus}
'parameter is omitted, an Informational entry will be written to
'the application log
Select Case Trim(Trim(newStatus))
Case "Green"
objEventLog.WriteEntry(strMessageOut, EventLogEntryType.Information)
Case "Yellow"
objEventLog.WriteEntry(strMessageOut, EventLogEntryType.Warning)
Case "Red"
objEventLog.WriteEntry(strMessageOut, EventLogEntryType.Error)
Case Else
objEventLog.WriteEntry(strMessageOut, EventLogEntryType.Information)
End Select

Catch Ex As Exception

End Try

End If

End Sub

End Module

Once you have compiled the app, drop it off somewhere on your VirtualCenter server that is in the path. This will make it easier to run it, and will help with an issue with the "Run A Script" alert function in VC 2.0.x.

When you set it up in VC, it should look something like this:

When an event happens, it will look something like this:

And the individual item will look something like this:

Keep in mind, this is not a complete solution, but more of a starting point to get VC events into MOM 2005.

Additionally, because this application simply writes to the event log, any monitoring software that reads the Application Event Log, will be able to pick up this information.

Enjoy.

Labels: VMware

A new book, Scripting VMware Power Tools: Automating Virtual Infrastructure Administration, was released just before VMWorld 2006, and is making big waves here.

I have a special place in my heart for this book. I actually got to contribute to Chapter 8.

Many thanks to Steve Beaver.

You da Man!

Labels: VMware

We'll, I'm off to VMWorld 2006, this year should be a blast!

Labels: VMware

In the dynamic environment we have at work any day of the week, we could need some test VM's with any number of different disk sizes.

I would clone a "Golden Master" and then resize the disk, going through many different tools to be able to resize the C:\ drive to the full size of the .vmdk.

So, I wondered if there was any way to automate this. Well, there partially is.

If you add the "ExtendOEMPartition = 1" entry to the sysprep.inf file that VMware "drops off" on the vmdk before the customization process, it will resize to the full size (within the limits of the Windows OS you are cloning).

Keep in mind, this doesn't work for shrinking, but it certainly does for extending.

So my task was to deploy a VM, resize the disk, and have the customization process extend to the new (bigger) .vmdk size.

Well, after some deductive reasoning, I figured out which file generated the sysprep.inf. I wasn't so concerned with the "dropping off" process, as I was the generation process.

If this file is modified, to include the "ExtendOEMPartition = 1" entry in the [Unattended] section, the magic will happen. That is if you extend the .vmdk before the VM powers on for the first time.

Now, the modifications aren't difficult by any means. I will mention however, that the files to be modified are encoded, and they will have to be decoded. I will not go through the process of decoding them. But once decoded, you should be good to go.

And as everyone else who posts tweaks/ enhancements/ mods/ etc., I cannot be held responsible (or liable) for any changes you make to your configuration or your environment.

Click here to download the paper I put together. (Apparently my provider is having some web issues, possibly compression or something, so I've changed the .pdf to a .zip link. I'll post the whole article as a web page to help with this issue.)

I've tested this in VC 1.4 with ESX 2.5.x and VC 2.0 with ESX 3.0.0 and it works successfully with Windows 2000 and Windows 2003 guests. Updated: VC 2.0.1 and ESX 3.0.1 also perform flawlessly.

Another note: The mentioned files only have to be modified once. They will not affect the normal cloning/template deployment process if you do not resize the .vmdk's. I would recommend that if you upgrade your VC install, you check these files, and potentially update them if they have been replaced.

Labels: VMware

Labels: VMware

Labels: VMware

Posted by Jase to Computer Stuff at 3/16/2006 02:19:11 PM

Labels: VMware