Posts Tagged ‘settings’

Limiting the number of concurrent storage vMotions

June 6, 2013

vmw-dgrm-vsphr-087b-diagram1VMware vCenter allows several concurrent storage vMotions on a datastore. But it can negatively impact your production environment, by hammering your underlying storage. If you want to migrate several virtual machines to another datastore, it’s much safer to do that one by one. But it’s too much manual work.

There is a simple way to limit the number of concurrent storage vMotions by configuring vCenter advanced settings. There are a group of resource management parameters for network, host and datastore limits which apply to vMotion and Storage vMotion. They are called limits and costs. For ESXi 4.1 default datastore limit for migration with Storage vMotion is 128. And datastore resource cost for Storage vMotion is 16 (defaults for other versions of ESXi can be found here: Limits on Simultaneous Migrations). It basically means that 8 concurrent storage vMotions is allowed for each datastore. So to allow only one storage vMotion at a time you can either change the limit to 16 or cost to 128.

Lets say we choose to change the cost to 128. There are two ways of doing it. The first one is to edit vCenter vpxd.cfg file and add the following stanza between <vpxd></vpxd> tags:


The second simpler one way is to edit vCenter -> Administration -> vCenter Server Settings -> Advanced Settings and add config.vpxd.ResourceManager.CostPerEsx41SVmotion key with value equal to 128. You will probably need to reboot vCenter after that.

There is one moment, however. If you migrate VMs from say 3 source datastores to 1 destination, then 3 concurrent storage vMotion will kick off. I do not know what is the reason for that, but that’s what I found from the practice.


Solaris NIC settings

September 20, 2011

Today I faced a problem with network configuration on an ancient Solaris 7 RISC. Symptoms: output network speed 2.5MB/s, input speed 100KB/s.

netstat -in (-i for interfaces, -n for numbers) showed lots of Ierrs. The reason for that was mismatch in advertised capabilities even though effectively it was 100 FDX at each end. I had following parameters set in /etc/system left from previous admin:

set hme:hme_adv_autoneg_cap=0
set hme:hme_adv_100fdx_cap=1
set hme:hme_adv_100hdx_cap=0
set hme:hme_adv_10hdx_cap=0
set hme:hme_adv_10fdx_cap=0

And for switch it was:

# ndd -get /dev/hme lp_autoneg_cap

# ndd -get /dev/hme lp_100fdx_cap

# ndd -get /dev/hme lp_100hdx_cap

# ndd -get /dev/hme lp_10hdx_cap

# ndd -get /dev/hme lp_10fdx_cap

So the lesson is: always keep network settings equal on both ends even if they don’t contradict with each other at first sight.