DailyHypervisor Forums are online.

We have just launched our DailyHypervisor Forum located at http://www.dailyhypervisor.com/forum. Stop by, contribute and be a part of our community. The DH Forum is intended to be for all things cloud. Currently we have forums created for vCAC, vCD, vCO, Cloud General, and Openstack. More forum categories will be coming based on demand. If you have a category you would like to see shoot us a note and let us know.

Our goal is to create a common place where anyone can come to learn, get help, share ideas, or just about anything that will help foster knowledge regarding cloud computing. Considering this very blog is the announcement of our forum you could image there isn’t a whole lot happening yet so what are you waiting for, be the first. Go ask a question, post an issue, share a thought and let’s get things rolling.

vCloud Automation Center – vCAC 5.1 – Using Custom Properties

In this example we are going to configure a few different types of custom properties. The properties we are going to configure are:

  • VMware.VirtualCenter.Folder – This property allows you to define the folder in vCenter that a virtual machine will be placed in. If the folder does no exists it will be created when a machine is crated to be placed in the folder.
  • Cost.Center – This is not a reserved custom property, it’s one we are going to make up to attach a cost center to the machine request.
  • Project.ID – This is not a reserved custom property, it’s one we are going to make up to attach a Project ID to the machine request. We are going to prompt the user to input this value as part of the request.
  • Plugin.ADMachine.Cleanup.X – There are actually a few properties associated with this. The AD Cleanup wizard is a set of properties that allows you to configure what action to take in AD when a machine is destroyed. In my example I’m going to remove the machine record, however you can also configure it to move the machine to a specific OU and not delete it’s record.

[Read more…]

VMware SDK and Visual Studio 2008

I went to install the VMware SDK for vSphere 4.0 on to my desktop running Windows 7 64-bit, Visual Studio 2008, and .Net 3.5 SP1 and discovered the SDK setup is not friendly with these versions.  According to VMware you need Visual Studio 2005 and .Net 2.0 if you want to run the SDK.

So like most of you reading this I turned to my trusted adviser…google to find the answer I was looking for.  Much to my disappointment after 5 minutes of searching around I didn’t find any instant gratification for my problem so I decided to just go ahead and figure it out on my own.

It turned out to be a relatively easy task once I discovered what was causing my issues.  There are two windows cmd scripts that need to be edited to point to the proper locations of your installations.  I have included the modified cmd files in our downloads section for those of you that would like them.  These files are built to support my specific configuration but they are very easily edited to support your configuration.

[Read more…]

Citrix Xen Desktop (DDC) / Provisioning Server (PVS) & vSphere SDK

I’m sure many of you have run into an issue with setting up Citrix Xen Desktop (DDC). As i was setting up a new “Desktop Group” I ran into a problem when trying to configure the vCenter SDK address. The configuration wizard show you an example that looks say ‘For example, https://VirtualCetner.example.com/sdk” which is what you would expect to use and you would also expect it to work. Think again. When you try to setup your vCenter SDK address you will be presented with and error “The hosting infrastructure could not be reached at the specified address.” Citrix takes security serious so unless you plan on replacing the default SSL certificate on your vCenter server you will need to hack out a work around. Now I would agree that in production you should replace the default SSL but if your just trying to spin up a demo or test environment it can be a hassle.

So I searched the web over and over and found a number of threads with many of ways to resolve the issue only none of them seemed to work for me. However a combination of a number of things that I found did. So I’m here to save you the trouble of finding all of various pages with partial solutions. Below you will find exactly what you need to do to make this work.

[Read more…]

Keep it simple stupid – registering unregistered vm's

Last week my boss came to me and asked if I could write a script for a customer to register VM’s after being replicated from once VI environment to another.  I agreed to take on the project and go for it.

Like everything I do these days I decided to use powershell to write the script.  I have taken a liking to it and the fact that I can run the scripts on both ESX and ESXi hosts saves me from having to re-create scripts all the time.  So I plugged away to 3am wrote the script, tested it inside out and sideways in my lab.  I was confident in the scripts ability to register all vm’s form all datastores I went ahead and sent it off to the customer.

A few days later I was on a conference call with the customer.  They were having problems with the script.  It wasn’t registering all the vm’s.  After a few hours of troubleshooting I realized that I needed to go back and try to recreate the problem’s in my lab to fix the script, but the customer didn’t have that kind of time.

A short while after getting off the meeting with the customer I received an email from them stating not to worry they had gotten a shell script that worked.  Then I started to think…….  I went in to my lab and created a shell script that would do the job.  The shell script was 5 lines long as oppose to powershell script that is about 40 lines.

The shell script if anyone needs it looks like this:

for v in ‘find /vmfs/volumes/ -name “*.vmx” `
do
echo “Registering $v” >> /log/registeredvms.log
vmware-cmd -s register $v
done

So the short of the story is sometimes it is best to keep it simple stupid.  Utilizing powershell for this problem was just too much overkill and in the end there were issues that were overlooked that I still can’t reproduce in my lab.  A simple shell script is all that was required and what I should have originally decided on.

So in the end this is a lesson learned and hopefully it will prevent someone else from making the same mistake.