IBM System Storage Ideas Portal
This portal is to open public enhancement requests against IBM System Storage products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
Shape the future of IBM!
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Search existing ideas
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,
Post your ideas
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Specific links you will want to bookmark for future use
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
There is an additional notion on this, adding onto the backup granularity challenge which is ultimately a backup cost issue. I'm adding this here as it is closely related rather than worth a different Idea.
Even if your OpenShift namespace only contains a single VM, Fusion B&R today backs up all PVCs belonging to the VM. Labels that request exemption like `velero.io/exclude-from-backup: "true"` are ignored for PVCs belonging to a VM.
So VM volumes that contain ephemeral data or are supposed to be backed up with a dedicated agent within the VM will always be added to the Fusion backup. This is unacceptable for clients with 1000s of VMs with 10s of volumes per VM that used to have volume exemption on their former backup and restore workflows to keep backup and restore storage footprint manageable.
I got some feedback that the above description is a bit confusing... More details:
The goal of this idea is to eliminate future (near term I think...) problems with how BU processing works for OCP VMs workloads in particular. Today, when you choose what to backup you have to select a project. Whatever is inside that project gets processed. This is true for both the Fusion BU service and DF+ACM DR.
The project boundary in OCP looks to be a very good way and convenient way for grouping multiple VMs together so that you can apply a consistent set of project level controls, labeling, NAD access etc to a group of VMs. ...Nice
However, this presents a processing & I/O scale problem if there are many VMs in the same project. Just like there would be for any project with 100s of large PVs, esp if you are generating large deltas between snaps. (VMs!). This is table stakes for Cohesity, VEAAM, Commvault, etc...
So my idea is to look at how we can provide a different (more selective...) type of selection criteria than project level, so we don't march OCPVirt envs toward a cliff when it comes to supporting large amounts of VMs that happen to be grouped within the same project. This suggestion is adding another way of controlling for "backup storms" if you will, in addition to the current development toward making more powerful and efficient snapshot delta processing available to OCPVirt.