ESX 4.1 Memory Compression

Hi there, probably most of you are just thinking about the holidays, right ?
Well, since I’m still working, I’m also thinking about the holidays, but also on a new post.

This time I will write about VMWARE memory compression…it’s a new feature on ESX 4.1

We can think of it as a new layer of memory management.
At memory overcommit technology hierarchy it’s now placed between balloning and swapping.

1 – Trasnparent page sharing
2 – Balloning
3 – Memory Compression
4 – Disk swapping

So what happens is when ballooning is not capable of managing the workload instead of swapping the memory to disk ESX attempts first to compress the guest’s memory.
So the pages can be compressed and stored at the main memory.
The next access to that memory would require a memory decompression.

But why is that better/faster ?
Because the compressed memory still in main memory and a compress/decompress process is a lot faster than swapping in disk.

See the performance bellow:



Also If you want to read more Memory Resource Management in ESX 4.1 , check this out.

Happy New Year !!!!

Database and ODBC for vSphere Virtual Center 4.1

Hi guys,

This week I started creating the infrastructure for my vSphere environment.

I assume must of you read the hundreds of pages of Installation guide and Administrator guide, each time there’s a new release, right ? ; )

Well, I don’t. (my bad) . So, sometimes I learn the hard way.

Today I will share what I figured out when installing Virtual Center on a 64bits system.

If you are using a SQL 2008 database don’t forget to first install SQL Server 2008 Native Client on your Virtual Center Server.

I’m also installing my Virtual center on top of a Windows 2008 64bits

Virtual Center is now 64bits application, so you can use the 64bits ODBC to create it’s DSN connection to the database.
But, Update Manager still a 32bits application, so you have to use a 32bits ODBC
To launch 32bits ODBC run: [WindowsDir]\SysWOW64\odbcad32.exe

OK, my ODBC connections have been created I went through the installation without any problem or issue, but after a few days I started facing a few problems , then, suddenly virtual center service was not starting up anymore…. After some troubleshooting with my ODBC and database I decided to re-install it…. This time I got errors and installation did not proceed.

Error 25003. Setup Failed to create the VCenter Server repository



VMWARE has also a good KB about it, but none of the solutions worked to me.

After a few hours troubleshooting and making tests I figured out that DBAs have installed SQL 2008 Enterprise R2….. despite the fact SQL 2008 is an supported version R2 is not.

So, reinstalling the SQL with the right version fixed my issue.

Moral history….. READ THE DOCUMENTATION.

Merry Christmas…..

sVmotion fails with (vim.fault.InvalidDeviceBacking)

Wow, it has been crazy over here these last weeks…
I’m working on the upgrade of my environment from ESX 3.5 to vSphere 4.1, including some scripted installation of ESX, new templates, etc…
probably the new posts will be about migration ; )

For this one I selected an issue that was really bothering me for some time.
When I tried to perform a storage v-motion (sVmotion) a few guest hang with “A general system error occurred: failed to copy VM config to VMotion dest (vim.fault.InvalidDeviceBacking)”

First I wanted to make sure the problem was not with my environment, so I tried another sV-motion for another guest, on the same host with the same source LUN and going to the same LUN. This time it worked fine.

Another curious fact is when I try to see the disk information on the guest’s properties page the disk size is unavailable and the virtual disk become high-lighted, just like if I did some change.



So my conclusion was that the issue was with the guest !!

After several troubleshoots and attempts I figured out that the vmdk files were configured with full path on the vmx instead of the relative one.

Something just like that:

scsi0:0.name = "/vmfs/volumes/45d0b927-82211d90-ba07-000e0c830b29/guestA.vmdk"
scsi0:0.fileName = "/vmfs/volumes/45d0b927-82211d90-ba07-000e0c830b29/guestA.vmdk"

So I decide to remove the disk a re-attach them back.

After I removed the disks from the guest I took a look at my vmx file and realized that entries were not updated to reflect there’s no more disks on the guest.
So, I manually delete those lines.

Then I add re-attached the disk back through the VC, and the vmx reflected the change with the relative path instead the full path,

scsi0:0.fileName = "guestA.vmdk"

If you realize the entry scsi0:0.Name was not created anymore.

Since the guest is running fine and sV-motion back to work again I was wondering how it went in there ?!?

My though is that it’s an old vmx entry for older version of ESX…. Since I have an old environment, backing to ESX 2.0, that has been upgrading since them… some guest can be that old and have had several upgrades and in some cases inherited some old setting.

Some of those cases I saw a header in the vmx like:

### Created by VMware ESX Server 2.0.0 Config Wizard (05/08/07)

That’s all , hope it helps you..