Storage DRS, affinity, datastore clusters... new multi-disk VM has no space

[lanwench]

Hello ... I'm new to datastore clusters and am confused about affinity.  We're on 6.5.

Using PowerCLI, I clone a template into a datastore cluster that has enough free GB to accommodate the VM, plus the extra disks I want to add to it after cloning (and I allow for a buffer)

The VM gets created, and then I use New-Harddisk to add the additional drives. It seems that if the datastore on which the cloned VM resides, does not itself have enough space, everything barfs, even though the datastore cluster contains other datastores that *do* have enough space.. if the disks got allocated around.

I guess I assumed that when I picked a cluster, it would be smart enough to figure out which datastores to use for each of the disks. But it appears I don't get it.

How do other people do this? Is there anything I can set at the VM level instead of changing stuff on the cluster, or should that be configured differently?

Thanks!

Paula

LucD​ ... if you happen to see this, I will be most grateful!

[LucD]

Do you have SDRS active for that datastorecluster?

Is Keep VMDKs together active?

Anything mentioned in the SDRS Faults page?

Is there any more info in Task and Events?

Or in the vpxd log?

[lanwench]

Hi Luc ...

Yes, Storage DRS is enabled for all ds clusters

I just checked and 'keep VMDKs together by default' is enabled.

It's set for 8h imbalance checks and i/o threshold is aggressive.

Minimum space utilization difference is 5%.

Also, Storage DRS automation is set to 'no automation,manual mode' , if that makes any difference.

I'm not the one who set this up so I'm not sure whether there was some specific reason to do it this way. Is this best practice and if so is there something else I can/should do during a build to set it differently for a specific VM? I haven't spoken with the team who manages esxi yet as I wanted to figure out what all of this meant

--Paula

[golddiggie]

When you perform the deploy from template task, why not add the additional virtual drives at that time?? Since you're using a template, I'll assume you also have a customization specification set that you're using for part of the process.

For the datastore cluster, I usually set that to 'partially automatic'. Plus set it to less than 8 hour check intervals. You can always run the storage DRS task when you want and see what it shows. Again, with the PA setting, it will show you where it wants to move things, but wait for you to approve them before it executes. Depending on your environment, you could set it to fully automatic, if you trust things to be OK with that.

Check to see how much space is actually available inside the datastores that make up the cluster. If they're too tight to the threshold, that could be at least part of the issue. Even though it could appear you have enough space in the cluster as a whole, you might not have enough (at that time) on a single datastore.

You could, also, manually move some VMs to different datastores (you'll have to disable the DRS feature on those VMs to allow you to move within the same datastore cluster) and then try another deploy. If you can shift the VMs (at least for the short term) to a different DS cluster, then I would do that.

I really would change the setting off of 'manual' to at least some kind of automatic setting.

[lanwench]

Hey Luc -

Heh. I'm not using OSC specs now as the build process was sooooooo sloooooow when I did that, and waiting for it to complete & detect when it was done, sucked. With the current method, total build time from clone to domain join is about 5m. With OSC specs, it was about 15m.

My script sends a full report after the build as a markdown table in jira & an HTML table via email, but it has to know the guest is totally ready. Setting a loop to constantly interrogate the vievents to see when the VM was fully baked, was clumsy. Plus, with OSCspec you can't specify the OU to join the computer in, which is also :poop: I was disappointed as I'd had high hopes for using those...

So I'm MacGyvering it by cloning, and while still powered off, configuring RAM/CPI, and adding additional paravirtual scsi controllers & disks, -- then booting up & formatting the partitions. Also set the static IP via VMscript if we aren't using DHCP. I do the domain join by invoke-command with a remote scriptblock so it joins in the OU I want and renames the guest. I then restart the VM and it comes up fine. 

I'll talk to the folks who own the storage side of the fence and see about the settings you recommend. I don't know if there's a specific reason they're set this way.  There is *definitely* enough room in the individual datastores within the clusters, to accommodate all the disks, plus 'wiggle room'.

We do have storage DRS working (I see VMs being moved around a lot) but maybe that's set somewhere else?

Given all this, is there something I can include in the script to disable the 'keep vmdk's together' at the guest level?

Thanks