I want to prevent Linstor from creating a diskless disk.
I used the --replicas-on-same and --replicas-on-different, which works when creating a VM from Proxmox-8, but not when migrating to a node that is not supposed to be a peer.
The goal is to prevent Proxmox from migrating a VM to a node that is not allowed/not a peer.
It will always create a diskless disk.
Thanks.
Bob
Welcome Bob 
I’m wondering if the “auto-diskful” feature in LINSTOR would be useful in this situation?
This wouldn’t prevent an admin from migrating a VM to a node that doesn’t already have a fully populated local replica of that VMs LINSTOR resource, but it would cause the diskless assignment that gets created to become diskful after a configured amount of time.
As I reread your question I’m wondering if maintaining data locality isn’t the problem you’re trying to solve. Are you instead stating that Proxmox itself will choose hosts as migration targets that break the --replicas-on-same and --replicas-on-different rules you have in place?
Hey Kermat,
thanks for responding that quickly!
I think this option just makes a diskless after a certain time into a diskful.
DrbdOptions/auto-diskful’: Makes a resource diskful if it was continuously diskless primary for X minutes
It feels like there must be a simple solution. Can’t imagine I’m the only one who has different datacenter and preferred nodes for their VMs. xD
Thanks!
Bob
Hello Bob,
The reason auto-diskful would be useful here is that LINSTOR cannot make Proxmox do anything, it is external to LINSTOR and outside of its control. LINSTOR creates a Diskless assignment so that the data can be reachable in reaction to the resource being requested from a node that does not have that data present there. So auto-Diskful will then start replicating the data to that node that does not have it present there in the case the data is being InUse there, versus accessing that data non-locally via the tcp connection, as that is generally more desirable.
Per the documentation Matt linked earlier,
On some platforms that you integrate LINSTOR with, you might not have a way to influence where in your cluster a storage volume will be used.
Hope that helps in understanding where the suggestion came from, it is a feature aimed to assist in cases where you would not be able to control where the VM is migrated to.
However, per the Proxmox documentation linked (here),
There are settings to control the behavior of such migrations. This can be done via the configuration file datacenter.cfg or for a specific migration via API or command-line parameters.
So it sounds like in this case, you’d be able to define your migration behavior parameters within Proxmox itself.
Hi linaic,
thanks for your reply.
I think this concept is quite useful in a homgene cluster but unfortunately we have different kind of nodes and some VMs are not allowed to run on the slower nodes.
But I’m wondering what is the best practicise solution for a streched cluster across two sites.
I think this use case should not be that out of the world.
I look forward to hearing your opinions on this.
Thanks!
Bob
Proxmox uses a cluster resource scheduler to decide where to move nodes in the event of a migration. I’ve linked the relevant section here:
https://pve.proxmox.com/pve-docs/chapter-ha-manager.html#ha_manager_crs
It sounds like you may want to use the Static-Load Scheduler option that is currently in tech preview per the Proxmox documentation.
In the case of LINSTOR, it is not able to control where your resources are moved, only Proxmox is. Because of this, there would not be a way to use LINSTOR to control where VMs are migrated. I would suggest following up with Proxmox support to see what options there would be and the steps you could take to prevent the scheduler from migrating to those nodes but that would be out of the scope of LINSTOR.