DoubleCloud.org

Having answered many questions about IP addresses of virtual machines at different occasions, I still see more are coming. I think it’s time to write a blog about it. Hopefully people would search the Internet before raising the question.

First of all, there is a big confusion on the relationship of IP addresses and virtual machines. Many people tend to associate IP addresses with virtual machines, and want to retrieve/change the IP address of a virtual machine.

In fact, a virtual machine is very much like its physical counterpart. It does not have an IP address by itself. In other words, an IP address is NOT an intrinsic attribute of a machine, either virtual or physical. It might have one or more only after an OS is installed. In most cases, it does have one or more IP addresses, which gives the impression that every machine has an IP address.

A virtual machine does have intrinsic attributes such as MAC addresses if NIC cards are configured. Unlike its physical counterpart, a virtual machine’s MAC address can be re-configured. Some software vendors rely on MAC addresses to lock down their licensed software on particular machines. This mechanism can be, therefore, compromised in virtual environments.  Read more... (543 words, estimated 2:10 mins reading time)

While searching Twitter on “vSphere Java”, I found my presentation available today online at InfoQ (many thanks to @arm1433 and @toya256ForRSS). It has both video and slides for more than one hour. The voice was not quite clear in the first one or two minutes. After that it’s pretty good.

This presenation is a complete overview of the open source vSphere Java API. Because the audience then was new to virtualization, the first several minutes covered a little virtualization basics. You can scroll over if you know virtualization already.  Read more... (200 words, estimated 48 secs reading time)

With today’s global market, a software vendor has to consider the internationalization (I18N) issue to better serve users in different areas and maximize the return on the product investment. This article introduces the I18N basics of vSphere. Much of the content is based on my book VMware VI and vSphere SDK by Prentice Hall.

There are two basic meanings. First, you have to design your software so that it is localizable. In other words, you have to use the right APIs that can handle double byte characters. Sometimes people call this globalization (G11N).

Second, you should provide localized versions of your software so that users can read and use their native languages. Sometimes people call this localization.

In most cases, you externalize all the text strings that are visible to end users from the code to the resource files and translate them into different languages. Then localizing the software is as easy as combining the code and localized resource files. This is the way VirtualCenter server is localized. Depending on the programming language and platform, the resource files can be organized differently and might have another format. For example, Java uses properties files, yet C++ on Windows uses resource dlls.

That said, I18N is a broad topic that does much more than what is briefly covered here. Further discussion is beyond the scope of this book, but you can find more detailed information online.

As discussed, the VI SDK is essentially a set of Web Services interfaces. The WS-I18N summarizes four internationalization patterns that can be applied with Web Services when deployed.  Read more... (979 words, estimated 3:55 mins reading time)

The winners of the VMware Script-O-Mania contest was announced today by Pablo Roesch at VMware Developer Blog. Congratulations to Alan, William and Arnim who won the first three awards!

I just took some time to read these scripts even though PowerShell and Perl are not for me. Here I give you a brief introduction of the scripts, what vSphere APIs they used directly or indirectly, and why they topped the contest. Because vSphere API is based on Web Services, you can port the scripts to other languages like Java, .Net, whatever you feel comfortable with. If you want to port any of them using vSphere Java API, I am more than happy to include your contribution.

Note that the following comments are strictly my own opinions.

1. Who Created that VM ? – by Alan Renouf using PowerCLI

A script to add information back into the vSphere client, this script which is designed to run once a day (or more) as a scheduled task, will add a custom attribute to each VM with the creator and date created of that VM. A script to add information back into the vSphere client, this script which is designed to run once a day (or more) as a scheduled task, will add a custom attribute to each VM with the creator and date created of that VM.

Steve’s Comments:

Nice integration with the vSphere Client, making you almost doubt why it wasn’t there in the first place. Additional one liner scripts provide nice answers to the questions like who created the most VMs, how many VMs were created each month.  Read more... (671 words, estimated 2:41 mins reading time)

This article introduces you the basic model and terminologies in vSphere security management, for example, privileges, permissions, roles, and how they are related to each other to secure vSphere. It helps you to better manage the vSphere and program the vSphere API. Much of the content is based on my book VMware VI and vSphere SDK by Prentice Hall.

In vSphere, the security model consists of three types of components: privileges, roles, and permissions.

Privileges

A privilege is the basic individual right required to perform an operation. It is statically defined and never changes in a single version of a product. Given the many operations in VI, there are many privileges (for example, the privilege to “power on a virtual machine”). These privileges are represented as strings separated by dots, such as VirtualMachine.Interact.PowerOn.

The operations and privileges are not one-to-one mapping. Many operations do share common privileges like System.View. Therefore, there are many fewer privileges defined than methods. In some exceptional cases, a method requires different privileges depending on the target it operates on and the nature of the operation. The CloneVM_Task() method, for example, requires VirtualMachine.Provisioning.Clone for cloning from one virtual machine to another, VirtualMachine.Provisioning.DeployTemplate for cloning from a template to a virtual machine, and so on.

Roles

The role groups privileges from a user’s perspective. A role is normally named and defined for a group of people who have common responsibilities in the system (for example, administrators). Each role can include zero to multiple privileges. The extreme cases are the predefined “Admin” roles, which by default, includes all the privileges and the NoAccess role, which includes no privileges.  Read more... (758 words, 1 image, estimated 3:02 mins reading time)

If you have ever used vSphere Web Service API, you must have known that there is no managed object but ManagedObjectReference object. Understanding it helps deepen your understanding of the vSphere API.

Honestly, the ManagedObjectReference is a little confusing by itself. It is in fact a data object but represents a managed object. You can think of a MOR as a pointer in some sense because it’s used to uniquely identify a managed object. Even better, you can think of the “type” and “value” defined in the MOR in the SQL way. The type is like a table name, and the value like the primary key which can uniquely identify a managed object in its type.

MOR is really intended to be used by program and should be carefully limited to the scope of where it comes from. That is why it’s hidden from application developers in vSphere Java API.

Anyway, let’s see how to get hold of MOR objects:  Read more... (583 words, estimated 2:20 mins reading time)

This blog digs into the vSphere inventory structure, and changes in vSphere 4 from VI. It explains the difference between ESX and vCenter inventory tree, why the inventory path you see from vSphere Client doesn’t work with API. Much of the content is adapted from my book VMware VI and vSphere SDK by Prentice Hall.

Inventory vs. Inheritance hierarchy

My previous blog introduced the object model of the vSphere API. The UML diagram there shows how different managed object types are structured in the inheritance hierarchy.

The inventory hierarchy is quite different. It shows how different managed object instances are associated. With this understood, you can easily navigate among different managed objects in inventory tree of both ESX and vCenter. It’s critical for programming vSphere API because navigating the inventory is the primary way to get hold of managed objects.  Read more... (1245 words, 2 images, estimated 4:59 mins reading time)

After I blogged the top 5 myths of vSphere API, William Lam suggested me to write a bit more on the views in his comments. If you haven’t followed him (@lamw) at Twitter yet, you may want to. His vGhetto Perl repository is one of the best resources for people who use VI Perl.

For sure, VMware loves the term “view”. As far as I know, there are 3 different ”views.” Two of them are for APIs; the last one is for the desktop product family. We are not going to talk about the product View in this blog. You can find more information at VMware web site.

Let’s instead focus on the two “Views” for developers: one is in VI Perl and .NET/PowerCLI; the other is part of the core vSphere API.  Read more... (1276 words, 1 image, estimated 5:06 mins reading time)

If you have trouble to understand vSphere API when you first use it, you are definitely not alone. I had the same trouble when I first used it a while back.

Some of the troubles come from the disconnect between conventional programming model and that of vSphere API. In this blog, I summarize the top 5 myths about vSphere API based on my experience and the questions I see in the VMware community forum and vSphere Java API forum:

1. Non-existing Managed Objects
2. Pervasive PropertyCollector
3. Short-Lived Task Object
4. “Weak” HostSystem
5. “Un-documented” View

Let’s examine each of them one by one.  Read more... (734 words, 1 image, estimated 2:56 mins reading time)

Inspired by the book Made to Stick – Why do some ideas thrive while others die? by Heath brothers, I would like to give it a try on software platforms rather than the ideas covered in the book. Although the computer industry is still relatively young compared with other industries, it’s quite dynamic and we’ve seen some platforms came and died while others came and thrive. So, what are the general characteristics for such sticky platforms?

The authors of the book summarized the 6 principals to make ideas stick, meaning the ideas change either the thoughts or/and behaviors of the receivers. These principals are Simplicity, Unexpectedness, Credibility, Concreteness, Emotions, and Stories. They are shortened to SUCCESs for easy memory.

Most of these principals don’t apply on software platforms. Unexpectedness, for example, may be the last thing you would like to see of a software platform. For software platform, we definitely need predictability, among other qualities.

After thinking the problem over, I summarized 4 basic principles for a software platform to stick: Simplicity, Extensibility, Ecosystem, and Developers, in short SEED.  Read more... (700 words, 1 image, estimated 2:48 mins reading time)