Pages

2010-08-31

VMware vCloud SDK for Java allows you to get started quickly interfacing using vCloud API. It brings the REST based vCloud API in the world of Java developers by providing easy to use client side representation of vCloud resources and hiding the details of REST and HTTP.

The VMware vCenter Converter SDK is a programmatic interface to manage the conversion operations. The API is exposed as a Web service running on vCenter Converter server systems. The SDK includes comprehensive documentations as well as Java and C# samples that demonstrate common use cases for programmatically managing VMware VCenter Converter. Support Information: vCenter Converter SDK is a forum supported only SDK.

The Converter Standalone SDK includes the Converter Standalone API and Java and C# samples that demonstrate features of Converter Standalone server. The Converter Standalone SDK enables developers to evolve their applications to support new server features while maintaining compatibility with older server versions.

Wireless Access

Complimentary wireless access is available to all conference attendees in specific areas. Look for “VMworld2010” in your list of available wireless networks. The wireless network supports 802.11 a/b/g protocols and there is no WEP key. Once you connect to the network, just launch your Internet browser to gain access. If you need help connecting, please see the conference staff at the information desks located throughout the conference.

Email stations, where you can check email, print your schedule, and fill out overall conference surveys, are located in the Moscone South Lobby, Concourse Level and at Moscone West.

Information Desks

Visit one of many information desks located throughout the VMworld conference venue. Conference staff members are on hand to answer general questions about the conference and conference activities. VMworld information desks are located in the following areas: North Lobby, South Lobby, Concourse Level and Moscone West-Level Two.

Surveys

Help us make it a better VMware and VMworld! VMware is proud to have a long history of listening to our customers and partners, and making changes and investments according to your needs and wishes.

On all email stations at the Moscone Center, you will see two shortcuts on the desktop which take you to our online surveys:

VMworld Overall Conference Survey- Be entered into a drawing for one of 10 complimentary VMworld 2011 conference passes

VMware Customer Relationship Survey- Be entered into a drawing to win one of 20 $50 gift certificates to the VMware Company Store onsite at VMworld

Each survey takes approximately 10 minutes to complete. You do not have to take both surveys at the same time. We thank you in advance for your feedback.

Shuttle Transportation

Shuttle transportation will be provided daily for Conference registrants to/from VMworld 2010 Conference Hotels and the Moscone Center. To reduce the impact on the environment, shuttle service will not be provided to hotels within walking distance of the Convention Center. Please consult the onsite schedules for further details and route information. Transportation for those with special physical needs will be provided.

During the upgrade of a vCenter 4.0 Server to 4.1 - which included installing a new 64 bit Windows 2008 R2 Machine and moving the Database from one server to another, I encountered an error during the process of the upgrade of the SQL database which stopped the installation.

The installation log (which is usually located under C:\Users\<username>\AppData\Local\Temp\<digit>\vminst.log gave me an error

Which in-turn sent me to Prof. Google and KB 1024449 which in essence says that you will have to make a change to the database server configuration due to some SQL options not being set. Which struck me as strange because this was a default installation - the same as many before.

Which brought me to this thread which suggested an issue with the compatibility mode of the database itself, which was spot on.

A quick change of the compatibility level from 2000 to 2005 and the installation went on without a hitch.

Yep it is that small box on the top right hand side of your vSphere client

So on my 4.0 vCenter, I tried to find a VM. I entered the VM Name (MAMA) and what I got was this

and no results. and this was really strange. It was working before, so I tried to do the same on the 4.1 vCenter, looking for a VM (Maish)

VOILA, worked!! Now this was strange

So I decided to try this out on the vCenter 4.0 Server itself – where only one version of the client was installed, and also it worked

I tried this again on the vCenter 4.1 server. I tried to connect to the4.0 vCenter and was presented with the option of downloading the old client

And when connecting to the 4.0 vCenter – the same issue occurred.

I actually had a SR open with VMware on this issue on 07/19/2010 – but did not really get a solution.

Hello Maish, We have opened a bug with our development engineering group for this issue. I will keep you updated as to the progress of this issue, however, I do not know when a solution will be available.

Workaround at the moment – and it is not optimal

Do not connect to multiple versions of vCenter from the same machine. If you need to use 4.0 then make sure you have only the 4.0 Client installed.

Take the plunge and upgrade to 4.1 - (something I am not 100% ready for yet)

This does not affect searching a 4.1 vCenter when you have both 4.0 and 4.1 clients installed.

I have also heard of issue regarding problems with Storage Views, and a memory leak in the vpxclient when left running for long periods of time – if both clients are running simultaneously

*** Update 05/10/2010 ***

I would like to thank Michael for his comment that pointed me to a KB that VMware released regarding a workaround for this issue. It does not exactly describe the issue I encountered but maybe could solve the problem

Symptoms

vCenter Server search results appear blank, as if the search never completed

This issue occurs when vSphere Client 4.1 is used to access vCenter Server 4.0

Resolution

This issue can occur if you try to connect to a mix of vCenter Server 4.0 and 4.1 from one machine but do not have both vSphere Client versions installed on the machine. However, simply installing each Client version in different folders does not work. When you install the first Client you are asked where you want to install it. When you install the second Client, you are not asked for a location. Instead, the installer sees that you have already installed a Client and automatically tries and install the second client in the same directory. To install vSphere Client 4.0 and 4.1 in separate directories:

2010-08-10

What troubleshooting tools are you familiar with for monitoring your ESX host? I am sure that one of the first things that pop into your mind is of course ESXTOP.

ESXTOP will provide a great deal of information about the performance of your Host, be it network, your storage, VM's you name it.

The next thing that pops into my head is logs.

There are numerous amount of logs on an ESX host be it the hostd, vmkernel, vmkwarning, aam and I am sure that I am leaving out a number of others as well. In order to find out what is going wrong you will have go through the logs - and troubleshoot the issue.

It is a bit like going through a needle in the haystack. Troubleshooting is an art. Sometimes it is luck - sometimes it just knowing where to look for the right things, and they will pop up at you.

Let me give an example. I was asked the other to check why some computers running some continuous integration tests were freezing periodically, so badly that they would freeze after a few days. So looking at the Task Manager there was no problem of RAM/CPU/Disk/Network on the OS. Now I have seen more than once, a Windows OS lock up because a huge amount of open handles from a process clogging up the system. Lo and behold the process they were using had approximately 300 times more handles than it should have been using. but how did I find this? Using Task manager which gave me enough information as to what was happening.

Lets get back on track. Back to vCenter. What troubleshooting tools are there for vCenter?

Tasks and Events - which can give you great deal of information of what is happening on your vCenter server.

Logs again. Under \ProgramData\VMware\VMware VirtualCenter\Logs

But then again. Do we really know what is happening under the covers?

"I'm looking for a script to kill a hung vCenter task."

"stuck Task in Virtual Center"

"Cancelled task stuck in "Recent Tasks" area"

There are many many more like this - and what usually is the answer to all of these problems?

Yep you guessed it - Restart the vCenter Service.

Ok I do have to admit - we are talking about a Windows Application here, and this usually solves the problem.

But there are so many other things that I would like to see.

Why did an alarm not get triggered?

Why did it change state when it should not have?

Why was my VM migrated to this host and not that host?

What configuration Changes were made to which VM?

Why is Linked mode not working?

Is my vCenter so swamped with requests that it cannot keep up?

Where are these request coming from?

These are all things that not really available today.

Of the questions that should be asked is why do you need additional tools to give this info - I mean most of these issues are sorted by a restart of the service. The answer to that is actually very simple.

More and more components are hooking into vCenter.

Your storage Plug-ins

Backup (SMVI for example)

Linked Mode

SRM

Appspeed

CapacityIQ

Orchestrator

Application Discovery Manager

Change Insight

Future VMsafe products

Heartbeat

Cloud services that are coming.

If you have not realized by now - vCenter is a critical component of your Virtual environment - almost everything hooks into it and the more components that interact with it the more you will need the insight into vCenter to see how it is performing.

I booted the server and started the process. And BAM! it failed - complaining that is could not find the disks. I was intrigued to say the least because this is a proven working process - which never, ever fails!

As always - I use Google as part of my right-brain - and this brought me to the following post that shed some light on the issue.

During the kickstart operation you define where you are going to install your partitions. Historically this was /dev/cciss/c0d0as you can see from part of the kickstart configuration below

2010-08-05

I have been entrusted with converting a large number of Virtual machines that are currently hosted on Xen Server into the VMware Infrastructure.

There are all sorts of ways of migrating these a virtual machine exporting to VMDK's, Xen can export to a VMDK, convert to an OVF, other tools etc. I have found that the easiest way for the conversion is to treat the XEN VM as a live machine.

Besides all the different other lessons I am learning regarding the ins-and-outs of Xen Server and their virtual machines, and all kinds of gotchas that you need to prepare for (look out for them in the upcoming blog posts). During the testing of the process, I noticed something quite interesting.

So in order to simplify the process and not have to use two different tools and procedures, I went with the vCenter Converter Standalone 4.0.1 for both flavors.

I will not put you through the steps on how to convert the live machine - you can actually refer to this post from a quite a while back.

Once the conversion starts - a new VM is created - as per your input, but this is where it differs.

A Linux conversion. The VM is powered on, connected to the network, booted with the helper ISO and the conversion begins. Creation of the partitions and copying them over one by one. Here are the screen shots of the converter and the details of the process in the vCenter as well.

And now a windows conversion. The VM is created but not powered on. The copy of the data actually takes place directly into the VM without having to use the Helper VM. Look at the screenshot below.

I find this quite interesting because I it seems that the conversion is occurring somehow in the background without having to use the helper VM. And even more so - if this can be done for a windows VM - why can this not be done also with a Linux VM?

I would be very interested in hearing if you have any more insight as to what happens in the background during the Windows Conversion.