local storage/datastore

[rasmusan]

Have been testing a bit on 9.1, and happy to see that we not can do "shared-nothing" live migration of VMs between hosts with only local storage...

However it seems that the calculation of "free space" on the local datastore i still treated as a cluster-wide datastore, instead of individual datastore pr. host, when the hosts are in the same cluster - is that correct or am i missing something?

It seems that if the "local" datastore is is having fx. 20 GB free space on host 1, and 60 GB free space on host 2, it is reported in Morpheus as 20GB commonly, and thus migrating a VM of 25GB from host 1 to host 2 cannot be initiated as Morpheus reports that there is insufficient free space on the datastore....

Could the local datastore be named differently on each host in order to have the free space calculated individually for the hosts, or what are your thoughts?

[rasmusan]

Anyone from HPE with any comments on this?

[CalvinZito]

Hi @rasmusan - I have Copilot Notebook based on the v9.1.0 documentation that I have in another post that is pinned the to of this board. Here's what it says:

Yes, 9.1 adds support for this type of migration. For a VM using local storage, each local volume must be mapped to a target datastore as part of the live migration. If a local volume isn't mapped to destination storage, it isn't eligible for live migration.  Source: Infrastructure › Clusters › HVM Clusters › VM Migration & Failover

On the capacity question, though, the 9.1 documentation doesn't say that local datastore capacity across hosts should be combined, nor does it document using the lowest free-space value among hosts as the capacity check. It also doesn't document using different datastore names on each host as a requirement or workaround.

So if Host 1 has 20 GB free, Host 2 has 60 GB free, and a 25 GB VM can't be migrated to Host 2 because Morpheus is using the 20 GB figure, I wouldn't describe that as expected behavior based on the documentation.

My inference ***: for a shared-nothing migration, I would expect the relevant capacity check to be against the selected target datastore on the destination host. The behavior you're seeing may therefore be a capacity/discovery issue rather than an intended limitation. I'd avoid renaming the local datastores as a workaround until we confirm how those datastore objects are expected to be represented in 9.1. 

*** Note the inference is not based on the documentation!

My colleague might have some direct experience to add. @DiegoDelgado