Lostdomain.org » vmware

vCloud Integration Manager

Martijn — Wed, 08 Feb 2012 00:19:13 +0000

VMware just announced a new addition to their vCloud product family; vCloud Integration Manager.

vCloud Integration Manager was developed to provide a simple and standardized way for service providers to provision vCloud Director, vShield and vSphere in order to more quickly get new customers up and running on a cloud service. Until now, service providers either had to do these tasks manually, or redirect valuable software development resources to writing undifferentiated “glue code” and/or automation scripts.

Integration Manager reduces operational costs by automatically stepping through the configuration process for vCloud Director to set up Virtual Data Centers, virtual networks, administrator accounts and other cloud resources that the customer has ordered. By completing this in a matter of minutes, it decreases time to revenue (the time between receiving an order for service and fulfilling it, and therefore being able to bill for service).

Integration Manager includes a full set of REST APIs and a web GUI. The GUI provides an administrator interface to define the service building blocks that make up a full cloud service for a customer. Administrators can also configure reseller accounts, and provision and de-provision customers.

Read the full press release here.

vCenter plugin URLs

Martijn — Fri, 28 Oct 2011 21:33:33 +0000

When installing various VMware products that link into vCenter (vShield, vCloud Connector, vChargeback, I could go on..), you often have minimal control over what URL is actually used to browse to the plugin and you usually can’t change it later on. This can screw up your SSL certificate plans.

After a little digging, I found these tables in the SQL database:

- VPX_EXT_CLIENT
- VPX_EXT_SERVER

Both have a field called ‘URL’ which has the URL (doh) to the plugin.

Two things; this is not supported by VMware and could break something. I hasn’t on my setup, but it might on yours. Backups are your friend.

You need to stop the vCenter service before you edit the value and start it back up after you’re done.

Removing vCloud Agent from ESX(i) host

Martijn — Sun, 04 Sep 2011 16:16:30 +0000

When you’re like me, you just go ahead and install stuff without taking the time to read if the software you’re installing can be upgraded later. Dive head first.

Often with beta software, an upgrade path to a release build is lacking or problematic. Same goes for vCloud Director 1.5 beta to the release build of 1.5. When I upgraded to the release build, I did so without ‘Unpreparing’ the ESXi hosts that were being used by vCloud Director. That causes some problems when you want to link a new vCloud Director to these ESXi hosts, as the vCloud Agent is still on the hosts. You have to remove that agent manually before you can link them with the new vCloud Director again. Here’s how:

ESXi 5.0

esxcli software vib remove -n vcloud-agent

ESXi/ESX 4.x

/opt/vmware/uninstallers/vslad-uninstall.sh

VMware vCloud Director SSL certificates

Martijn — Wed, 24 Aug 2011 20:00:48 +0000

vCloud Director uses a java keystore to read its SSL certificates from. This makes it a bit more complicated to use an existing certificate and private key set. Took me a while to figure out, so I’m sharing. In this example I created /opt/vmware/keystore for the certificate files. The ssl-key.pem and ssl-cert.pem are the existing certificate files. Furthermore, I used ‘passed’ as the keystore and alias password. (needed for the vCD configuration) Firstly, we need to convert the key and certificate to a DER format:

[root@vcd.lostdomain.org keystore]# export PATH=$PATH:/opt/vmware/vcloud-director/jre/bin
[root@vcd.lostdomain.org keystore]# openssl pkcs8 -topk8 -nocrypt -in ssl-key.pem -inform PEM -out ssl-key.der -outform DER
[root@vcd.lostdomain.org keystore]# openssl x509 -in ssl-cert.pem -inform PEM -out ssl-cert.der -outform DER

Credits go out to http://www.agentbob.info/agentbob/79-AB.html for the next part, the following combines the key and certificate into a new keystore:

[root@vcd.lostdomain.org keystore]# wget http://lostdomain.org/etc/ImportKey.class
[root@vcd.lostdomain.org keystore]# java ImportKey proserve-key.der proserve-cert.der
Using keystore-file : /root/keystore.ImportKey
One certificate, no chain.
Key and certificate stored.
Alias:importkey  Password:importkey

We’ve now created a new keystore with an existing private key and certificate. Check to verify!

[root@vcd.lostdomain.org ~]# keytool -storetype JCEKS -storepass importkey -keystore keystore.ImportKey -list

Keystore type: JCEKS
Keystore provider: SunJCE

Your keystore contains 1 entry

importkey, Aug 24, 2011, PrivateKeyEntry,
Certificate fingerprint (MD5): C0:5E:7B:B8:AB:30:89:5B:4A:7D:5F:2F:F4:00:CD:F4

Ok, now we copy the importkey alias to the required aliases for vCD:

[root@vcd.lostdomain.org ~]# keytool -keyclone -storetype JCEKS -storepass importkey -alias importkey -dest consoleproxy -keystore keystore.ImportKey
Enter key password for
(RETURN if same as for )
Re-enter new password:
[root@vcd.lostdomain.org ~]# keytool -keyclone -storetype JCEKS -storepass importkey -alias importkey -dest http -keystore keystore.ImportKey
Enter key password for
(RETURN if same as for )
Re-enter new password:

Get rid of the ‘importkey’ alias and change the keystore password:

[root@vcd.lostdomain.org ~]# keytool -delete -storetype JCEKS -storepass importkey -alias importkey -keystore keystore.ImportKey
[root@vcd.lostdomain.org ~]# keytool -storepasswd -new passwd -keystore keystore.ImportKey

Now check to verify the aliases inside the keystore:

[root@vcd.lostdomain.org ~]# keytool -storetype JCEKS -storepass importkey -keystore keystore.ImportKey -list   

Keystore type: JCEKS
Keystore provider: SunJCE

Your keystore contains 2 entries

consoleproxy, Aug 24, 2011, PrivateKeyEntry,
Certificate fingerprint (MD5): C0:5E:7B:B8:AB:30:89:5B:4A:7D:5F:2F:F4:00:CD:F4
http, Aug 24, 2011, PrivateKeyEntry,
Certificate fingerprint (MD5): C0:5E:7B:B8:AB:30:89:5B:4A:7D:5F:2F:F4:00:CD:F4

Ok, so now we have a keystore file with our key and certificate in it. Now to update vCD:

[root@vcd.lostdomain.org ~]# /etc/init.d/vmware-vcd stop
Stopping vmware-vcd-watchdog:                              [  OK  ]
Stopping vmware-vcd-cell:                             [  OK  ]
[root@vcd.lostdomain.org ~]# mv keystore.ImportKey certificates.ks
[root@vcd.lostdomain.org ~]# /opt/vmware/vcloud-director/bin/configure
Welcome to the vCloud Director configuration utility.

..snip..

Please enter the path to the Java keystore containing your SSL certificates and
private keys: /opt/vmware/keystore/certificates.ks
Please enter the password for the keystore:

..snap..

Would you like to start the vCloud Director service now? If you choose not
to start it now, you can manually start it at any time using this command:
service vmware-vcd start

Start it now? [y/n] y

Starting vmware-vcd-watchdog:                              [  OK  ]
Starting vmware-vcd-cell                                   [  OK  ]

The vCD service will be started automatically on boot.  To disable this,
use the following command: chkconfig --del vmware-vcd

[root@vcd.lostdomain.org ~]#

And peaches.

Snapshot hell: Recover a locked vmdk

Martijn — Thu, 14 May 2009 18:50:15 +0000

I’ve had my share of battles with corrupt vmdk files, after the process of removing a snapshot crashed. Finally, I found a way to recover them through a VCB utility. Here’s the log that usually presents itself:

May 12 01:43:13.593: vmx| DISKLIB-DSCPTR: Failed to open extents for descriptor file in normal mode May 12 01:43:13.593: vmx| DISKLIB-LINK : “/vmfs/volumes/49dc603e-af139aaa-7131-002219b6f201/VM1/VM1.vmdk” : failed to open (Device or resource busy). May 12 01:43:13.593: vmx| DISKLIB-CHAIN : “/vmfs/volumes/49dc603e-af139aaa-7131-002219b6f201/VM1/VM1.vmdk” : failed to open (Device or resource busy). May 12 01:43:13.594: vmx| DISKLIB-LIB : Failed to open ‘/vmfs/volumes/49dc603e-af139aaa-7131-002219b6f201/VM1/VM1.vmdk’ with flags 0xa (Device or resource busy). May 12 01:43:13.594: vmx| DISK: Cannot open disk “/vmfs/volumes/49dc603e-af139aaa-7131-002219b6f201/VM1/VM1.vmdk”: Device or resource busy (1048585). May 12 01:43:13.594: vmx| Msg_Post: Error May 12 01:43:13.594: vmx| [msg.disk.noBackEnd] Cannot open the disk ‘/vmfs/volumes/49dc603e-af139aaa-7131-002219b6f201/VM1/VM1.vmdk’ or one of the snapshot disks i t depends on. May 12 01:43:13.594: vmx| [msg.disk.configureDiskError] Reason: Device or resource busy.

We will use the vcbExport utility to read the data from the old vmdk and create a new one. First, unregister the VM from your ESX host (if not done already):

# cd /vmfs/volumes/49dc603e-af139aaa-7131-002219b6f201/ # vmware-cmd -s unregister `pwd`/VM1/VM1.vmx unregister(/vmfs/volumes/49dc603e-af139aaa-7131-002219b6f201/VM1/VM1.vmx) = 1

Then move the old VM directory and create a new one:

# mv VM1 VM1.old # mkdir VM1 # cd VM1

Then, convert the old vmdk to a new one:

# vcbExport -M 1 -F 1 -d VM1.vmdk -s ../VM1.old/VM1.vmdk

This will take a while, depending on the size of your disks. After all, it is copying the entire data file. Do the same for the other vmdk’s, if you have more than one disk. After you finish with vcbExport, we need to alter a few things to the .vmdk file(s); open it in your favorite editor. Change:

createType=”monolithicFlat”

To:

createType=”vmfs”

Change:

RW 56124534 FLAT “VM1-flat.vmdk” 0

To:

RW 56124534 VMFS “VM1-flat.vmdk”

Copy .vmx and .vmxf file

# cp ../VM1.old/VM1.vmx* .

After that, you can register and start the VM again:

# vmware-cmd -s register VM1.vmx register(/vmfs/volumes/49dc603e-af139aaa-7131-002219b6f201/VM1/VM1.vmx) = 1 # vmware-cmd VM1.vmx start start() = 1

The VM will require an answer on the UUID matter (choose ‘Keep’) before it actually boots:

# vmware-cmd VM1.vmx answer