Search results

@fabian i might be wrong. correct me if im wrong DLM is using the cluster service from Proxmox ? so actually if i configure a Qdevice it may rely on it as it will maintain the corum from corosync ( pvecm ) ?

@Glowsome questions for you per your experiment , Can we have to link enable in proxmox that will not cause issue to DLM / GFS2 Services ? i think i had read something in the past that corosync didnt supported 2 network simultanously other question if it cant , do you think the option for...

Instead of running a VM in or a CT on another cluster or a stand alone device Can we use Both at the same time ? example a Secondary Cabinet with a Secondary Cluster have multiple host that can act as a Qdevice for the other cluster do you see any issue that it can cause ?

@fabian do you think i can enable a secondary link to the Proxmox cluster ? from my memory i think i had read that corosync or dlm or i dont know what service was having issue handling 2 link to maintain GFS2 active. if you have any advice before i do so. otherwise i can configure a Qdevice...

In scenario where 3 PVE host have CEPH running and each of them have Direct attached disks , trough SAS for example , will the PVE Node benefit from been able to access the DATA localy from the HBA controller and not passing trough the network to loopback ? we try to figure if we can Avoid...

hi what kind of shared storage do you refer to ? over Network or it was SAS shared storage ?

hi Fabian the error is mine. We had a NAMESPACE with the identical same name as the DATASTORE NAME from PBS server and had another NAMESPACE ( the one i use ) inside of it. good to know i didnt tough we can have multiple NAMESPACE after the root

propagate is set to yes. and another 2.3.1 PBS is sucessfuly syncing a DATASTORE from another PBS to this problematic one with the same user configured. the only thing i see is that the bakcup files written on the original datastore are not using the same USER than the user we use on the SYNC...

root@CL1-MTL1-BL2:~# pvesm list CL1-MTL1-PBS-RP1 error listing snapshots - 400 Bad Request

root@CL1-MTL1-BL2:~# proxmox-backup-client snapshot list --ns BACKUPS-1 Error: unable to get (default) repository

hi is there a way to see the Actual Backup usage a specific is consuming on a PBS datastore.. ? we only see the Qcow2 original backup size so far. Really not usefull to see how much a Specific VM is consuming on a HOST too

@dcsapak https://forum.proxmox.com/threads/error-listing-snapshots-400-bad-request-500.121591/

That is good to know then. we have HA enable on each VM and disabled the Failback as we need to mount GFS2 Shared on each Host manually per our policy to pint point why a node as actually Failed prior to bringing it back in service. 3 years ago we faced a similar issue and i tough my team had...

I posted another thread just over this one that is marked as solve. The details are there. Even if we successfully add the datastore we can't retrieve the vm disks. We see the database usage we can't retrieve any vm when we search them in the gui

yest its correctly spelled in the file. i have another target on another PBS with the same name but a different user , and i can reach it . maybe i cannot have 2 namespace with the same name but i dont think its that as i have this issue only with this namespace

do you plan to add this managable trough the GUI ? a failed node can occur anytime and it would be more effective to handle this automaticaly / or been able to switch the configuratoin trough the GUI in case of a failed node, intseas of doing CLI to move the configuration file..

Hi we Added a Namespace under a existing Datastore and cannot Reach it trough any of our Nodes. the Namespace is working well and PBS is retrieving a Daily Sync from another . i see all the Content VMs in PBS viewer tab We first disconnected ( removed from the cluster the storage that was...

Yes Sadly this is what we did and are facing the same issue. the difference is we want to reach a Namespace instead of the root. we have no problem Adding it but we cant reach it . we get the same error

@kocifi @dcsapak we have a similar issue when trying to retrieve a Namespace inside the root Datastore , running 7.2.11

@itNGO we have the same issue but when you mention delete the storage in all PVE nodes, you mean trough the clusters all at once or you can do it manually one by one ?