View 4.6 and Storage Load Balancing

[Peter_Grant]

I'm running View 4.6 in our lab and when I tired to provision 100 desktops across 3 datastores it's putting most on datastore0. Some are on datastore1 and none so far are on datastore2.

The replica is not on a different datastore and the capacity is as follows:

DS0:

Capacity 1.91TB

Free 1.27 TB

DS1:

Capacity 1.91TB

Free 1.28 TB

DS2:

Capacity 1.91TB

Free 1.24 TB

Now if View 4.6 looks at datastore free space and decides that there is enough hence it doesn't need to load balance then this is a problem as capacity is the least of our concerns. Just wondering if this is something funny in our lab or if others are seeing this as well?

The datastores are also being use for other lab workloads (most are idle)

Anyone else seeing this?

Peter

Xtravirt.com

[mpryor]

There were some tweaks in 4.6 to improve balancing, specifically fixing a problem where unassociated vmdk files were missed from the space calculations. The decision has always been based on available space on the datastore, including existing clones and their overcommit factor, it won't simply fill one and then the other. The data used to make the decision should be in the debug log files (c:\programdata\vmware\vdm\logs), search for "SVI Datastore Details for datastore".

[Linjo]

Hi Peter.

Simon wrote a blog about this not to long ago, have a look here:

http://www.simonlong.co.uk/blog/2011/02/09/vmware-view-4-5-rebalance/

As mentioned above this have changed slightly in View 4.6 to something like this:

weighted_population_density = virtual_usage / (datastore_capacity*overcommit_factor)

// Linjo

[Peter_Grant]

Hey Joel,

Thanks for the update. Damm..Simon will tell me off for not reading his blog!

I need to get my head around this and do more testing so am I right to assume that if I had 3 datastores of the same size / free space and nothing else on them then the VMs should be distributed evenly? So what was throwing off my testing was that some datastores had existing VMs? (although the space free was almost the same).

I was surprised to see that the first 50 VMs all went to datastore 0. Made me concerned that if I increased the pool size to 300 across all datastores that one datastore may have say 200 VMs?

Let me test and think about this a little more and get back to you.

By the way...loving the PCoIP through the security server...works a treat.

[Peter_Grant]

Ok, I get it. Very simple, based purely on space...something I think I knew but didn't consider some of the implications.

Even through the datastores were identical in size with one having a little more available space about 70 of the linked clones went on one, 20 on another and 10 on the other. Mine was probably an extreme example as the datastores were very large (1.9 TB) so a small space different in percentage terms was enough to throw out the load balancing based on space.

As a View Administrator I'm not as bothered about the space being perfectly balanced if it means I have a large mismatch of the number of VMs. I'm more worried about SCSI locking and other contention issues. Would be nice if the logic had a bit more to it so that it also took into consideration the number of VMs as well as space rather than just looking at one metric. Maybe like DRS considers Memory and CPU??

Actually, thinking out loud here, I'd like to be able to specify maximum number of VMs per datastore. I've just been involved in troubleshooting a 3rd party View environment where they had 400 VMs on one datastore. Sounds silly but without really understanding the background of Replicas, splitting them or the considerations around SCSI reservations etc it's easy to do if your new to View. Would be good to have some protection mechanisms in there.

Regards

Pete

[mittim12]

Pete,

While I agree that 400 desktops on a single datastore is a bit extreme I must admit I haven't given SCSI reversation locks a great deal of though here of late.   In my opinion the inception of opportunistic locking and VAAI has greatly reduced the rick of those types of locks.   Do you have a standard amount of desktops you typically deploy to a datastore. 

[Peter_Grant]

My storage knowledge is a little rusty so maybe it's not locking that's the main concern but certainly having a large number of VMs on one datastore was causing a big issue.

I did a View 4.5 design last year for 8000 desktops in which I used a conservative 64 VMs per datastore. Even though 128 seems to have been proven to work fine I try and use a bit less just to be safe.

400 or so was extreme and it's complicated to explain how they got their but once I understood their logic for the customer getting into that position it wasn't that silly especially if they didn't understand the storage implications. And let's face it a lot of customers that 'design' View deployments are not experts in the field and often it's their first one.

Regardless, I think it would be nice if View took numbers of VMs into account when balancing the storage.

Cheers

Pete

[mittim12]

Thanks for sharing your experiences.   I tend to stay around the 100 VM mark myself and so far that has worked out well.   I also agree that the rebalance option should have a little more flexibilty and allow maximums to be set.   You are right as that would avoid bigger issues down the road in some cases.

It would also be great if VMware would put out some updated information on VDI per lun recommendations.   I remember awhile back that the 64 per LUN was referenced in one of the whitepapers but I haven't seen anything since.