VMWorld 2007

Well, it's been a while since I've posted here - I bet most of you thought I wasn't coming back! Truth is I've been busy with non-virtualization related stuff quite a bit, and when I do get to play with my VMware fixing stuff at work takes priority. Having an ESX license at home and some hardware that'll run it would help - I'm working on that.

So anyways - I'm typing this while sitting on the floor in a corner of the Moscone convention center (hope thats right, going from memory), near the end of the first full day of VMWorld - I have about another 1/2 an hour till they open the welcome reception. Thoughts so far... the content of the show has been great, but the organization around it has room for improvement - the lineups are INSANE. The big points I've heard about so far are the releases of ESX 3i and their disaster-recovery product that I've gone and forgotten the proper name of - but whatever, the releases are well covered elsewhere so I'm not going into any more detail.

One point I did pick up that wasn't in any of the big announcements is that ESX 3i apparently will NOT have the full functionality of current ESX 3 - specifically relating to the addon components that aren't in ESX3 standard. He specifically mentioned DRS and HA - though I have a feeling DRS will work. I've heard from a person who was in the beta and he was vmotion'ing from ESX3.0.1 to 3i, and DRS is not much more than VirtualCenter doing a vmotion for you (nothing special required on the host), so I think DRS + 3i will be ok. HA on the other hand functions without VirtualCenter - even if the VC server is dead HA will work. HA actually uses some Legato clustering technology installed in the service console to work - so it wouldn't surprise me if they had to take that out to get 3i into that 32MB footprint. When I'm back in the office (and have free time) I'll look into testing some of this with the 3i copies they handed out to everyone who attended - we all got bootable USB thumb-drives with 3i pre-installed.

Other than that - not much of interest to report that won't be better-covered elsewhere. I'm here to learn as much as I can, and will use that to help develop the VIClient DLL, answer your questions, etc. - not to pretend to be a journalist. And for anyone else who was able to make it here - feel free to mail my blackberry at robbaum at nait dot ca and we can try and meet up and have a chat.

The VIClient

After rebuilding the stub DLLs, I realized that anyone who was using my VIClient DLL would start having problems - since it was built to use the old DLLs. So I took the opportunity to split it out into its own project, cleaned it up a little, and now I have not only a new binary version for you all - but the complete source code as well. For now I'm just releasing it under the good ol' GPL, mostly because I'm really not familiar with the range of various open-source licenses out there. In the future I may consider moving it to the LGPL, or maybe something completely different if someone can come up with a good argument as to why I should.

And so - the links you're all waiting for.

• Compiled version of VIClient.DLL here.
  
• VS-2005 solution for VIClient with full source here.

The compiled version was built using the stub DLLs linked in my previous post. I'm really not sure if it will work with any version of those DLLs, or if it requires those specific copies - I think any version should be ok. Obviously if you're using the source almost any version of the DLLs should be fine - you just might need to fix the project references to point at them. Any projects using the VIClient will also need references to VimService2005.

And like the readme with the source code says - there is no warrantee of any kind on any of this stuff I release. It works for me in production - but it might not for you. You can't blame me if it kills your dog. And I'm afraid right now there's no documentation either, except the code itself.

Building the VI3 SDK .NET DLLs

So I've decided to start right at the very beginning. If you're going to build an app in .NET using the VI3 SDK, you need the DLL files with all the stub classes. And since the DLLs distributed with my MAC tool were from the VirtualCenter 2.0.0 version of the SDK, I've decided to rebuild them using the 2.0.1 version.

I should note at this point, that building these DLLs has gotten much easier since the original release. When you extract the SDK components you are supplied with a script that would build this DLL for you; however when you use the DLL generated from it you get stuck with a bug that makes it incredibly slow to create a VimService instance. This is all documented in a VMWare knowledge base article, along with how to work around it. If you go and read that article, you can see the instructions I had to follow to make the MAC-tool DLLs - all that stuff that's now listed as "Alternative 2: Step-by-Stem Instructions". But with the 2.0.1 release, that KB article has been updated with a patch that makes this procedure very easy.

So - to actually build these DLLs, you will need a few things.

1. Visual Studio 2005. I have a license for the Professional edition, however the free Express editions will work just as well.
2. The VI3 SDK. I recommend grabbing the documentation while you're there.
   
3. The patch to automate building DLLs without performance problems. Scroll to the very bottom of that article to find the patch attached.

Install Visual Studio if you haven't already, and extract both the SDK and the patch. From this point on I'm going to assume that you've extracted the SDK to C:\Temp\SDK\ and the patch to C:\Temp\patch\. To make really sure that we're talking the same directories, in the C:\Temp\SDK\ folder you should find 2 more folders and 2 .wsdl files, and in the C:\Temp\patch\ folder there should be 8 files - mostly .txt and .cmd.

Next step is to open up a Visual Studio command prompt. Make sure it's a Visual Studio one and not just regular cmd.exe as the VS one has a lot more environment variables defined. You can find the shortcut somewhere in the Visual Studio program group. You'll know you got the right one if at the top when it starts it says "Setting environment for using Microsoft Visual Studio 2005 x86 tools." Then it's just a matter of typing a few commands.

CD \Temp\patch
patch201.cmd C:\Temp\SDK
CD \Temp\SDK\samples_2_0\DotNet
Build2005.cmd

When that last command finishes, you'll find a couple of brand new DLLs for you in the C:\Temp\SDK\samples_2_0\DotNet\ folder. You can copy them to wherever you like, and if you don't want the sample code it is safe at this point to delete both the SDK folder and the patch folder. The only things you need are VimService2005.dll and VimService2005.XmlSerializers.dll.

Or if you're lazy, I've put compiled versions up in a place where you can snag them from. If you have problems extracting that, go and get 7-Zip.

Now besides being a slightly newer version than my older DLLs, there is another significant difference with this version (besides file names). All of the objects in this version are in the VimApi namespace. So an object from my DLL named say VimService, in this new DLL will be called VimApi.VimService. The really easy way to make code written for the old DLL work is to just add this line to the top of every file.

Imports VimApi

After thats done, you can reference all the objects without having to type 'VimApi.' in front of everything. To port my VIClient.DLL to this new VimService2005, all I had to do was remove the old DLL reference, add a reference to VimService2005, and add the Imports line at the top.

Using the VI3 SDK from VB.NET

And yet another post in the first hour of this blog's existence. And once again it's really just an excuse to link to some of my stuff thats already out on the 'net.

So it turns out that a lot of people out there want to use the VI3 SDK from VB, but are having issues since there is no sample code at all. Well I taught myself from the C# example code, and the MAC tool was the result. And since I've also been working on some other tools (not released) I moved a bunch of my code into a DLL so I could re-use it. Well now Eric Sloof over at NTPRO.NL has published an article on using the SDK from VB, and he's recommending using the DLL's distributed with my MAC tool as the easy way to do it.

Now I've got no problem at all with that, in fact I've already talked with Eric to help him make better use of those DLLs. But I wanted a place where I could publish my own thoughts and ramblings on using the SDK from VB, as well as on my DLL. Though I'm unsure whether I'll ever release the full source of the MAC tool, I do want to at least get that DLL source out. Maybe my little DLL will eventually develop into a .NET API similar to the VI3-Perl-toolkit.

So - you can expect to start seeing some code on here in the near future. I do need to go through and do some cleanup before I post it up, but hopefully it won't take too long. I'd also like to do some short code samples of how to make use of both my DLL as well as the SDK in general. So if there's something you'd like to know how to do from VB using the SDK please let me know - it might be the first example. But until then, the article at ntpro has some very limited instructions on it that I e-mailed to Eric.

MAC Address Management under VI3

So this is the motivation that got me to create this blog. I built this tool quite a while back, and have published it to the internet a couple times now. The original version never made it out of a post at the VMWare community forums. When I finished an updated version of the tool, I wanted something better for it and after a brief e-mail discussion I got Richard Garsthagen over at Run-Virtual to host it for me. What I'd really like to do is host it myself, because I like watching the statistics on how many people download it. But thats something I don't plan to get into until/unless I release yet another updated version.

Whats the point of this post then? Well to make it easier for me to make and receive comments about my tool. And the one comment I've gotten by far the most, are requests to release the source code. I'm still sitting on the fence on that decision though, mostly because a lot of the code in there is a serious mess. Besides being written in a rather short amount of time, it was also my first ever project using the VI3 SDK and so it was a learning experience for me. But fear not, I will be posting code up on here - it just might not be the complete source to the MAC tool.

Hello

So I've decided to start one of these blog things. If you're lucky I'll even update it reasonably frequently. The topic around here I hope to keep mostly related to virtualization technologies, specifically VMWare Virtual Infrastructure 3, though I dabble in other things as well.

As for me - I'm your standard geek. Located in western Canada, I work at the Northern Alberta Institute of Technology, where I deal with the infrastructure that keeps the place running. Physical servers, virtual servers, SAN/storage stuff, even the occasional MS-SQL DBA-type problem - you never know what I'll be working on, or possibly commenting on here.