2009-01-27

I was entrusted with the task to try and migrate a VM from Xen 3.2 to ESX. Well you would think that is a trivial task - it should be. But let us not forget that we are talking here about version 3.2, which is two generations back from the current Citrix Xensource which is in use today.
After successfully migrating it I would like to share with you the procedure.
This was done on a Xen Guest VM runnning Red Hat Enterprise Linux ES release 3 (Taroon Update 7)
Disk Layout was two disks, hda and hdb. The second disk was configured as part of a an Logical Volume as you can see below

Fired Up VMware Converter version 4.0 Beta and started the import as if the machine was a powered on physical machine
Source info
Destination info
And when we get to the options you as you can see below the Data to copy is missing a drive
We continue with process of the import. The way the new converter works with a live Linux machine - it uses a helper VM. What it does is, it creates a VM on your ESX, powers it up and loads a Linux ISO (don't know which one) to act as a mediator for the cloning process.
This VM has to be able to receive an IP from a DHCP server otherwise the process will not work.
This is a picture of what is hapenning inside the console of the helper VM:
Time for conversion - Load on Host - Completed
The configuration of the new VM on ESX as you can see only had one drive.
Powered on the VM and this is what I got. The OS would not come up because it was missing the second part of the volume.
Entered the Root Password

2009-01-23

A potential client (hopefully will be a major client in the future) came to me with a requirement to consider ESX3i as their next platform for a stand-alone lab (x30). The major setback at the moment was the ability to easily export VM's from one Lab to another. They needed to exprt the image off of host relatively often. Now why they were not using ESX in the first place and why they are continuing not to do so, and why they would not go for an enterprise solution, that is a whole different story, which I will not get into. And neither why ESX does not really compare to Xensource.

They are using Citrix Xensource 3.2 - which is a quick Right-click -> Export ... Choose your location -> Save.

Since each VM is something like 40gb in size, this can be a very time consuming process.

So they started out by trying with thick disks (40GB) and to transfer that kind of a disk over the network can take mmmmm.... quite a while..

Not acceptable!

They went for Thin-disks (yes - I know that it sucks performance-wise..). Well when we created the disks it showed the size of 40GB on the VM's settings, when ls -la on the Console (yeah yeah not supported - I know..) but when looking at it through the Datastore Browser - lo and behold - 8GB in size, exactly what we were expecting.

So we tried to move the VM off of the Host, with the Virtual Infrastructure Client GUI, with WinSCP, with ssh, with FastSCP, we all go the same results (as was expected), as soon as the files was exported off, it grew to 40GB in size, and therefore took too long to export the VM.

Again Not acceptable!

So what was left, and I have Edward again here to thank for reminding me, the export feature.

Aha!!

In the VIC, when the machine is powered off, when you select your VM and then from the top Menu, File -> Virtual Appliance -> Export, you have the option to Export the VM out to any location accessible from your computer. Me be the skeptic I am, I thought that it would not make much of a difference in size and time, but I was wrong.

So not only do they have their export feature, not only are the VM image sizes manageable, not only is the timeframe more than acceptable, the disks will stay Thick by default which I am sure will improve the performance, and also make Edward happy.

So, perhaps I have convinced the client that ESX3i is more than a suitable and worthy candidate that will match and even improve on that feature from Xensource any day (not to mention almost any other feature as well). And if all goes as I hope, we will have another happy client that will benefit from using ESX, and in the future they will go with the product they are supposed to be using the first place - VMware Lab Manager.

Total for the Whitebox $900 (But in all honesty, since I work as part of the IT group, the only thing that was actually purchased was the Desktop, all other hardware was provided through our department)

I have already put up 3 machines on it, two that I work with daily (1 Ubuntu, 1 Windows 2003 Server) and the 3rd one is a test for Windows server 2008 R2 Beta which I am trying out.

Thanks to Eric Sloof for the inspiration for the post. (did not come out as cheap as his though..)

2009-01-12

Vmware have lots of community forums, and while trying to make some order in the alerts I receive from the forums, I noticed that there are two communities that deal with the same thing, but are in different places, with different content.

and this one

Now I asked the group of Virtual folks on Twitter and the answers I have received so far is:

One is vCenter and the other is vCenter Server

Different Levels in the VMware Communities

But seriously folks.. Why have two different forums with almost the same content, we actually talked about this topic on the Communities Roundtable Podcast #27, so until then I am going to have to continue receiving alerts from both locations till VMware gets their act sorted out.

Edit:

the answer I got from John Troyer:

@maishsk First URL is vCenter (Server), 2nd has no threads, is *parent* category for management tools (look at upper right for children)

2009-01-06

That was actually meant to be highly sarcastic, it seems that the folks in Microsoft thought this would be a good idea (acutally it would be very good - if it would work properly..)

So you can control vCenter with SCVMM but it seems that when you want to remove it, typically like microsoft does, it leaves a lot of "leftovers" behind. So I personally would like to have my environment back the way it was before Microsoft started to play with and Eric Grey posted on his blog what is left over when you remove SCVMM. He even went as far as to provide a Powershell script that will remove all the muck for you.