P2V of big Oracle machines and heap size

In VMware infrastructure we have still seen pushing on the limits. One of the limit which we have to take into account is heap size. Particulary if you are in the middle of project of migration of all oracle database to virtual infastructure with couple of TB disks. Default value for vSphere 5.0 for  VMFS3.MaxHeapSizeMB is 80MB what in summary gets us up to 8TB of vmdks per esxi host. If you hit this limit you will not able to power on VMs. You can change this value to max. 256MB but it required esxi host to reboot. Imagine situation where you finished migration you have enough CPU and memory but you are not able power on DB because you forget increase heap size, and all previously migrated VMs are in production. If you lucky emogh you can shuffle VMs between hosts to bypass and fit to 8TB limit.

Here is VMware kb article:
http://kb.vmware.com/kb/1004424

How VMware vSphere 5.x VAAI XCOPY is handled by EMC VNX platform.

It is not so obvious and hard to find how VAAI XCOPY is handled if we clone Virtual Machines between datastores which are not shared across esxi host or esxi clusters. Here is the answer:

In order for VAAI to work

The source and destination LUNs (Datastores) must be accessible by the host performing the clone task, and they must be on the same VNX storage system

You need to make sure that your host has source and destination datastores mounted or it will fall back to a host copy.

Here is link to excellent document of Jeff Purcel from EMC Engineering [h8229-vnx-vmware-tb]:

http://tinyurl.com/mggkf7o

Enjoy!

iLO/RDAC/CIMC Managment IP from vCenter in vSphere 5.x

'Ziggy' has showed me nice feature recently in vSphere 5.x. How to check IP of iLO/RDAC/CIMC in vCenter.

1. For esx host choose Hardware Status tab
2. Expand 'Baseboard Management Controller'
3. Expnad 'Management Controller IP Interface'
4. Here you are IP address of Management Interface [iLO/RDAC/CIMC]

What does 'Uptime' column in vCenter referes to?

Whuu... big customer all red flags raised. All VMs reboot during vMotion and svMotion, migration project stopped...

Virtual Machine which interest us is dc2 with uptime 10 minutes.

We choose dc2 and vMotion to second esxi host.

1..2..3 vmotion me..

After vmotion we see uptime 21 seconds !!! OMG my VM crash, rebooted ? NO ;-) Everything Okay...

The 'Uptime' column referes to the uptime of a given VM process on ESXi and it is unfortunate that it's often interpreted as guest OS uptime. The behaviour is expected since a new vmx process and associateed world ID is created for a VM on migration so logic dictates the 'Uptime' is reset during vMotion/svMotion. Let's say sometimes 'less is more' ;-)

vCenter allows to create VMs with the same names.

It was quiet day when all of the sudden I got message that vCenter allows to create the virtual machines with the same names. At first I thought; okay probably they create VMs in diffrent Datacenters object but it was not the case.So it is bug or future ;-). And yes you can create VMs with the same names on one esx host but in different catalog (folder if you are windows guy ;-)). Please find the story below:

Create new VM

1.) Choose esx host to create VM
2.) Create New Virtual Machine with name '1'

Create second VM with name '1'

1.) We put the name '1' into Name box
2.) We choose datacenter object Lab
3.) Click Next and ...

1.) We get error message as expected. NO VMs with the same name in the same datacenter object.

What happens if we choose 'Discovered virtual machine' catalog

Yes, we can create VM with name '1' in default folder/catalog. In next step we create more catalogs and create more VMs with name '1' yeah babe !!!

1.) Name of VM '1'
2.) Repeat step and add VM object '1' to dev catalog
3.) to 'Discovered virtual machine' we already added and second VM with the same object cannot exist
4.) add VM object '1' to test catalog

What we see in 'Host and Cluster' view ?

Holy cow 4 VMs with the same names on one ESX host !!!

But let me think what we will see in 'VMs and Templates' view

Here we can recognize that all '1' VMs are owned by different parents objects datacenter Lab, folders test, dev and Discovered virtual machine.

VMware has created mechanism to prevent creating vms with the same name on the same datastore:

As you can see even if you create the next '1' VMs on the same datastore [iSCSI] vCenter take care about this and change the name in background. The same mechanism is triggered when you svMotion VM to datastore where VM with the same name exist.

Take away from this story:
1.) Catalogs/folders in 'Host and Cluster' and 'VMs and Templates' are different !!! It is a bit counter intuitive.
2.) Double check your name conventions particularly if you run 1000 of VMs.
3.) Check if you run VMs with the same name using PowerCLI scripts or Orchestrator workflow or simple in 'Virtula Machines' tab on datacenter object.

the end...

Hello World !!!

This blog is mainly for my personal use. I believe that blogging is the best way to sort out all my thoughts around technologies.  By education I am Electronic Engineer I started my adventure with computers from Boolean algebra and TTL gates ;-) Now I am involved in IT and big transformation into cloud. I hope that someone can find this information helpful and drop comments. Enjoy and share !!!