WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Hardware Options
    • Hardware Reviews
    • Lab Deployment Scripts
    • Nested Virtualization
    • Homelab Podcasts
  • VMware Nostalgia
  • Apple

Leveraging vCD + vCO + Wavemaker Part 1

12.05.2011 by William Lam // 4 Comments

A few weeks back I had a discussion with Maish Saidel-Keesing and Jason Boche on twitter about whether or not a user can be part of multiple vCloud organizations, and the answer is yes. Maish followed up with the question of whether it was possible to have users access a single URL and be forwarded to their correct organization URL. The answer of course is yes and I suggested one could build a simple intranet/webapp utilizing the vCloud API to query for a given user and to dynamically generate the organization URLs for that user.

I thought that was the end of that conversation until a little later in the day when I noticed an interesting blog post vCO - wavemaker, your cloud webservice (part I) by Christian Johannsen showing how to create a simple web application using VMware's recent acquisition of Wavemaker and vCenter Orchestrator. A little light bulb went off and my curiosity got the best of me giving me an idea. I wanted to see if it was possible to leverage vCenter Orchestrator, the new vCloud Director plugin for vCO and Wavemaker to create a simple web application that would solve the above use case.

In this first of two part post, I will first demonstrate how to create a vCO workflow using the new vCloud Director plugin. If you can not wait, go to the bottom of this post to check out video of the final results.

Here is an example of my vCloud Director lab setup in which there are multiple organizations with multiple users in each organization.

As you can see, we show that "coke-admin" user is part of multiple organizations "Coke" and "MysterDrink".

Next let's take a look at our vCO server and configuration (I'm using the vCO virtual appliance). I will assume you have installed and configured the new vCloud Director plugin for vCO. If not, take a look at here for the documentation.

Now let's launch the vCO Client, you can access this by just pointing your browser to your vCO Server if you are using the vCO virtual appliance and clicking on "Start Orchestrator Client".

You will now login to your vCO Server using either the default credentials or an account you created within your director services (AD,LDAP).

To verify that the vCloud Director plugin for vCO was configured correctly, click on the "Inventory" tab on the left and you should be able to expand out your vCloud Director inventory. 

Now you are ready to create your workflow, click on the "Workflows" tab on the left.

Create a new directory to help organize your custom workflows. Right click on Library to create a new director. In this example I am calling it "vCloud Director Custom".

Next, right click on the director that was just created and create a new workflow. In this example I am calling it "getUserOrgUrls".

Right click on the new workflow that was just created and click on "Edit" which will allow us to start creating our workflow.

Let's define our input parameter which will be the name of the user inquiring about the organizations he/she is part of. Click on the orange button to create a new input variable, the type will be "string" and in this example I named the variable "userName" which will be used a little bit later in the workflow creation.

Let's define our output parameter which will be a list of organizations URLs the user is part of. Click on the green button to create a new output variable, the type will be "array/string" and in this example I named the variable "OrgUrls" which will also be used later in the workflow.

Next click on "Schema" tab and add a "Scriptable Task" and "End workflow" element to the workflow.

Then click on the Connector Tool next to the Validate button and connect the starting element to "Scriptable task" and to "End workflow" element.

Now we will create a simple vCO script to actually perform the query of the "userName" and return a list of "orgUrls". Click on the "Scriptable task" element and you should see a new screen load at the bottom like the following.

Next we will bind our input variable, click on the on the icon next to the X and select "userName" variable which we created earlier.

Next will bind our output variable, click on the on the icon next to the X and select "orgUrls" variable which we created earlier.

To verify that both your input and output variables were binded, correct, you can click on the "Visual Binding" tab and it should look like the following.

Lastly, we will insert our vCO script. Click on "Scripting" tab and insert the following snippet.

I would like to thank both Christian Johannsen and Christophe Decanini for their assistance on the vCO script. These guys are rock stars when it comes to vCO and you should definitely follow them on twitter if you are not already.

Next we will validate the script to ensure all input/output parameters were used correctly and we do not have any known syntax errors in the script. Click on the "Validate" button at the top and you should get no warnings/errors.

Okay, we are all done now! Let's go ahead and give our new workflow a test run. Here is a quick video on executing our getUserOrgUrl workflow:

Leveraging vCD + vCO + Wavemaker Part 1 from lamw on Vimeo.

As you can see, we can easily leverage vCO and the new vCloud Director plugin to perform a variety of tasks not only limited to orchestrated-based operations but even simple queries as well. In my next post, I will show you how to integrate this with Wavemaker to present a simple web application for end users to consume. Stay tuned!

Categories // Uncategorized Tags // orchestrator, vcd, vcloud director, vCO, wavemaker

ghettoVCB + ghettoVCB-restore Updates

11.28.2011 by William Lam // 6 Comments

I finally got a chance to finish up the documentation on some of the new feature enhancements and bug fixes for both ghettoVCB and ghettoVCB-restore this weekend. One of the biggest change is both ghettoVCB and ghettoVCB-restore are now bundled together and ghettoVCB-restore is now being version controlled on github just like ghettoVCB. This has been on the backlog for awhile and I am sorry it took this long to get implemented.

Here are the release notes for the enhancement/fixes for both ghettoVCB + ghettoVCB-restore. Hope you enjoy these updates and if you have any issues, please report them on the ghettoVCB VMTN group.

ghettoVCB 

Enhancements:

  • ghettoVCB & ghettoVCB-restore is now packaged together and both scripts are versioned on github
  • ESXi 5 firewall check for email port (Check FAQ #33 for more details)
  • New EMAIL_DELAY_INTERVAL netcat variable to control slow SMTP servers
  • ADAPTER_TYPE (buslogic,lsilogic,ide) no longer need to manually specified, script will auto-detect based on VMDK descriptor file
  • Using symlink -f parameter for quicker unlink/re-link for RSYNC use case
  • Updated documentation, including NFS issues (Check FAQ #19 for more details including new VMware KB 1035332 article)

Fixes:

  • vSphere 4.1 Update 2 introduced new vim-cmd snapshot.remove param, this has now been updated in script to detect this new param change
ghettoVCB-restore

Enhancements:

  • Support for ESX(i) 5.0
  • Combined ghettoVCB + ghettoVCB-restore scripts
  • ghettoVCB-restore is now versioned on github

Categories // Uncategorized Tags // ESXi 4.1, ESXi 5.0, ghettoVCB, ghettovcb-restore

When Do vSphere MoRef's Change?

11.26.2011 by William Lam // 20 Comments

I received a few follow-up questions from my earlier article vSphere MoRef (Managed Object Reference) ID Finder Script regarding when the MoRef (Managed Object Reference) ID changes. As mentioned in my previous article, a MoRef ID is guaranteed to be unique within a vCenter instance to track all entities such as virtual machines, hosts, datacenters, resource pools, etc. and this is stored within the vCenter Database. One thing that I did not mention in the other article, is there is also a MoRef ID for objects that reside directly on an ESX(i) host. The scope of a MoRef ID on an ESX(i) host is only within the host itself, this is another reason why it is a best practice to use vCenter to not only manage your inventory but also keeping track of a single consistent global MoRef ID.

An entities MoRef ID will remain the same throughout it's lifespan unless it is destroyed or unregistered from vCenter Server (e.g. virtual machine or host). With a MoRef ID on an ESX(i) host, this will slightly change with vSphere operations such as vMotion and/or Storage vMotion of a virtual machine in which the VM will be unregistered and re-registered on a completely different host.

Here are a few examples demonstrating some vSphere operations and what happens to MoRef ID:

1. vMotion of a VM from HostA to HostB

As you can see, the vCenter MoRef ID stays the same during the vMotion, but the MoRef ID on the hosts will change as the VM changes hosts.

2. Storage vMotion of a VM's disk while residing on the same host (HostB)

With Storage vMotion, the vCenter MoRef ID stays the same as one would expect, but the MoRef ID on the hosts still changes because start with vSphere 4.x, a Storage vMotion starts off just like a vMotion and hence a new VM entity is registered on the same host.

3. Clone of VM1 to VM2

Since vCenter is creating a new VM entity, a new MoRef ID will be generated as expected.

4. FT of VM

Just like with a clone, an FT'ed VM will contain two unique entities on each local ESX(i) host and hence a different MoRef ID will be found, but still only a single MoRef ID in vCenter.

5. Deleting VM1 and creating a new VM with same name as VM1

Again, since the entity was destroyed and re-created with the same name, it is treated as a new object and hence a new MoRef ID will be assigned to the entity, even if it has the same name. This is true if you remove an ESX(i) host from vCenter and re-add it, all information including the MoRef will be re-generated. 

Lastly, you might ask if one could modify or set a MoRef ID for an entity in vCenter since it is stored in the vCenter Database? The answer is no. The MoRef ID is stored in the vCenter Database but there are many internal pointers that uses the MoRef ID, especially when it comes to VM MoRef IDs. Just updating the ID in one location will not suffice and can cause integrity issues with your vCenter Database, not to mention it is not supported by VMware.

However, there is one way you could influence the algorithm on how the MoRef ID's are generated. Within vCenter, there is a instance ID property that is generated during the installation of vCenter Server which ranges from 0 to 63. This value can manually be adjusted as it is also used to uniquely generate VM Mac Addresses and UUID's as described in this VMware KB.

Here are some additional scenarios in which MoRef ID's will change:

  • Performing a full image restore of a VM when the original VM reference was removed from vCenter (the restored VM will have a new MOR after being registered with vCenter)
  • Restoring a datastore from a snapshot. Although the snapshot is the same datastore, technically it's a new LUN with a unique signature.
  • VMs restored at a DR site, especially when using 3rd party replication tools.
  • Hosts that have been removed from inventory and re-registered with the same vCenter server.
  • restoring a vCenter DB Backup with new VM's after backup taken

Categories // Uncategorized Tags // managed object reference, moref, vSphere

  • « Previous Page
  • 1
  • …
  • 506
  • 507
  • 508
  • 509
  • 510
  • …
  • 565
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • PowerCLI remediation script for running NSX Edge on AMD Ryzen for VCF 9.0 06/20/2025
  • Failed to locate kickstart on Nested ESXi VM CD-ROM in VCF 9.0 06/20/2025
  • NVMe Tiering with Nested Virtualization in VCF 9.0 06/20/2025
  • VCF 9.0 Installer workaround for ESXi hosts with different vendor 06/19/2025
  • NVMe Tiering with AMD Ryzen CPU workaround for VCF 9.0 06/19/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025