Search results

you can of course open a feature request for this, but no promises that it'll be done (or when) one of the problems in implementing this is that the task logs are saved on the local filesystem on each node, so not easily accessible from the other nodes. And we usually don't do api calls that...

sent a patch now: https://lore.proxmox.com/pve-devel/20251119092634.763388-1-d.csapak@proxmox.com/T/#u

hi, i guess this is an ECC key? in that case the minimum size we check against is 224 not 2048, but the log line has the 2048 bit hardcoded ;) i'll send a patch as it's confusing

i think you misunderstood me: the list is still sorted by name, but the individual entries are wrongly rendered (vmid before name) anyway, thanks for reporting, i sent a patch that should fix it: https://lore.proxmox.com/pve-devel/20251117131945.2148025-1-d.csapak@proxmox.com/T/#u

it's still sorted by name: 108 Arch-Budgie comes before 102 Arch-Cinnamon but the rendering is wrong (vmid before name). I'll look into it

no currently migrations (be it intra or cross cluster) will not use the network to the pdm, but either * the normal cluster migration network (intra cluster migration) * the path the source cluster would take to the ip/name the pdm knows of the target cluster (so the source will resolve the...

You can also opt to only given the Datacenter Manager a token with limited access rights, e.g. audit only. PDM will not be able to *do* anything, but you can still monitor it and get quick access with a link.

the PVEAuthCookie has to be a regular pve ticket for users, not the vncticket. the vncticket has to be a parameter to the vncwebsocket api call (AFAIR)

currently, the websocket connection to the pve api also requires a valid user cookie to be set, and not a token (not sure how exactly you handle authentication in your client/proxy) but this will change soon (since we also need token access for consoles on pdm) see...

proxmox ve (and all current proxmox products) are 100% open source and free, you only ever pay for support, so listing xcp-ng as 'free' (where you have to compile stuff yourself, which is not the case for our products) and not our's is misleading. so adding a '1) free' as a cost would only be...

do you have any sdn configured? can you post the output of pvesh get /nodes/<nodename>/network --type any_bridge --output-format json-pretty of the affected pve remote ? (replace <nodename> with the actual one please ;) )

hi, how does your network setup/config on the pve side look like?

yes, it's not really random, but how exactly it's chosen is currently just an implementation detail, so not guaranteed in your case though, after 4 weeks, there is only one tape left to choose, and from that point on, always the oldest media-set will be outside the retention period

hmm with a 5 week rotation it's probably not possible since the calendar events are calendar based, and things like 'every x weeks' is not really possible maybe there is another way: * have an allocation policy of e.g. everyday at monday 09:00 * have retention policy of 27days (4 weeks minus...

this is, in fact, the right way to do it. PBS just uses any tape that is available (no order here is guaranteed) but decides before checking the drive see the examples in the docs: https://pbs.proxmox.com/docs/tape-backup.html#example-setups

hi, the issue in the first post looks like a bug, would you mind opening one on https://bugzilla.proxmox.com with the logs and relevant info to reproduce (configs, storages, etc.) the error in your second post is not really a bug, even if you use root@pam for pdm, it will create a token to...

just fyi: you can define pools as 'child' pools by using a slash in the name, so you can create the pool 'foo' and the pool 'foo/bar' in the gui they won't be shown nested, but i think for the purposes of permissions this should work.

please don't double post your questions, see my answer here: https://forum.proxmox.com/threads/nvidia-vgpu-software-18-support-for-proxmox-ve.163153/page-2#post-811872

this is not really a vgpu question, as that only works with virtual machines. please open a separate thread for that question

i generaly layering cow filesystems should not break anything, but it will slow down (since each layer has to do cow) Personally, i'd use only one cow layer, be it in the vm or at the hardware storage level. In any case, you could run tests in the vm if the performance is acceptable if you...