In order to monitor some load behavior I needed to increase the logging level of the vCenter server. The logging level still is included in the vCenter Server Settings, however it takes a few more clicks to get the Statistics option compared to the old vSphere client.
1. In the home screen click on vCenter.
2. click on the vCenter Servers link in the Inventory list.
3. Select the vCenter (probably Localhost).
4. Select the Manage tab in the right-pane.
5. Select Setting.
6. Click on the Edit button located on the far end right side of the screen.
7. Change the appropriate Statistic setting.
Get notification of these blogs postings and more DRS and Storage DRS information by following me on Twitter: @frankdenneman
Technical paper: “VMware vCloud Director Resource Allocation Models” available for download
Today the technical paper “VMware vCloud Director Resource Allocation Models” has been made available for download on VMware.com.
This whitepaper covers the allocation models used by vCloud Director 1.5 and how they interact with the vSphere layer. This paper helps you correlate the vCloud allocation model settings with the vSphere resource allocation settings. For example what happens on the vSphere layer when I set a guarantee on an Org VDC configured with the Allocation Pool Model. It provides insight on the distribution of resources on both the vCloud layer and vSphere layer and illustrates the impact of various allocation model settings on vSphere admission control. The paper contains a full chapter about allocation model in practice and demonstrates the effect of using various combinations of allocation models within a single provider vDC.
Please note that this paper is based on vCloud Director 1.5
http://www.vmware.com/resources/techresources/10325
VMworld Europe Sessions
At VMworld Europe I will participate in Meet the Expert sessions, Group discussions and three breakout sessions. Here’s an overview of my public schedule.
I hope to see you all in my sessions or participate in the group discussions. Or schedule a time slot in Meet the Expert if you have a question about Storage DRS or DRS that you want to ask me.
Tuesday 9 October:
11:00 – 12:00: Group Discussion 28 Resource Management
12:30 – 13:30: INF-VSP1168 Architecting a Cloud Infrastructure
14:00 – 15:00: INF-VSP1683 Resource Pool Best Practices
Wednesday 10 October:
11:00 – 12:00: Meet the Experts 05
12:30 – 13:30: Group Discussion 28 Resource Management
15:30 – 16:30: INF-STO1545 Architecting and designing (SDRS) Datastore Clusters
Thursday 11 October:
10:30 – 11:30: Meet the Experts 11
Where is my new vMotion functionality?
Just a reminder as I received a lot of questions and comments about this:
The new vMotion functionality – migrating virtual machines between host without shared storage – is only available via the web client.
Please note that in the vSphere 5.1 release all new features are only visible via the web client and not in the old vSphere client.
For more information about the vMotion functionality: vSphere 5.1 vMotion deepdive
Get notification of these blogs postings and more DRS and Storage DRS information by following me on Twitter: @frankdenneman
vSphere 5.1 storage vMotion parallel disk migrations
Where previous versions of vSphere copied disks serially, vSphere 5.1 allows up to 4 parallel disk copies per Storage vMotion operation When you migrate a virtual machine with five VMDK files, Storage vMotion copies of the first four disks in parallel, then starts the next disk copy as soon as one of the first four finishes.
To reduce performance impact on other virtual machines sharing the datastores, parallel disk copies only apply to disk copies between distinct datastores. This means that if a virtual machine has multiple VMDK files on Datastore1 and Datastore2, parallel disk copies will only happen if destination datastores are Datastore3 and Datastore4.
Let’s use an example to clarify the process. Virtual machine VM1 has four vmdk files. VMDK1 and VMDK2 are on Datastore1, VMDK3 and VMDK4 are on Datastore2. The VMDK files are moved from Datastore1 to Datastore4 and from Datastore2 to Datastore3. VMDK1 and VMDK3 are migrated in parallel, while VMDK2 and VMDK4 are queued. The migration process of VMDK2 is started the moment the migration of VMDK1 is complete, similar for VMDK4 as it will be started when the migration of VMDK3 is complete.
A fan out disk copy, in other words copying two VMDK files on datastore A to datastores B and C, will not have parallel disk copies. The common use case of parallel disk copies is the migration of a virtual machine configured with an anti-affinity rule inside a datastore cluster.