Description / Background info

At the December 2024 vF2F, VM management and organization was one of the main topics discussed. 

The group agreed that both single cluster and multicluster use cases must be consistently considered when designing workflows. While the level of detail and presentation of the flow or feature may vary, multicluster use cases should remain a priority throughout the design process.

Here are some examples of the type of actions we discussed:

Single:

Creating, updating, and deleting VMs

Managing VM snapshots for rollback and recovery

Cloning VMs or templates for rapid provisioning

Creating VM templates

Configuring networking

Configuring storage

Multi: 

Have a single point of access to view and control VMs across many clusters

Manage at scale, monitor the health, performance, and resource usage of VMs across many clusters from a single location to identify any issues

Move VMs between clusters based on needs, such as different regions for better performance or for backup and disaster recovery

Goals for the work 
Optimize VM management and organization, which includes finding and troubleshooting VMs across single-cluster and multi-cluster environments

Customer input

"I would love to have this kind of I mean the more features and the more flexibility we give the customers to utilize our console to do such a bulk life cycle management for the virtual machines it's definitely desirable by multiple customers but the way I do it with my customers is that again think of it as a Kubernetes resource

If we want to do such a thing with bulk, we have selectors, we have labels, we have scripting and automations and API calls that we can do it. But for the specific case of virtual machines because most of the customers are coming with the mindset and experience from platform that give them these kind of features because I can easily do it from here for example then I would say yes it would be something that the customers will be desiring to have."

• Quote source: Technical account manager

"...highlights up the problem with multi cluster management, when you, when you get to the point of doing, you know, if I have dozens of OpenShift clusters that are running virtualization, which one do I log into? Right? Where's, where's my single pane of glass? I mean, I know we've solved that in some sense for the OpenShift side of the house with the observability dashboards and in ACM, and those are useful, but it's not been enough for Swift, for example, they've been building their own dashboards. They've asked us multiple times to try to try to define a way to..."

• Quote source, Solution architect

Tracking success 

What analytics or verbatims will we track, or how will we know this change was successful? By specifying this now we will know what pieces of information need to be tracked in the code.

Definition of done - Targeted for [estimate a timeframe once known/In Progress]

• A solution has been agreed upon and reviewed by stakeholders for navigating to and from ACM to CNV for a user to find and fix VMs. 
• A solution has been agreed upon and reviewed by stakeholders for bulk actions.

Design artifacts