ah ok, so that too is missing..
don't worry, there is still a way that should work ;)
you can directly use the api or use the cli helper tool 'pvesh' (which exposes the whole api on the cli)
pvesh create /cluster/acme/account --contact...
hi, i answered a bit more detailed in your other thread: https://forum.proxmox.com/threads/pve9-in-place-upgrade-failed-due-to-mellanox-nvidia-networking.173385/#post-806883
please let's continue this discussion there
hi,
just for your information, the nvidia driver does not have to directly support debian 13, but actually the kernel version is more the reason here. Since we base our kernel on ubuntus and not on debians this is different from debian 13.
This...
see the help output on the cli:
# pvenode help acme account register
USAGE: pvenode acme account register [<name>] {<contact>} [OPTIONS]
Register a new ACME account with a compatible CA.
<name> <name> (default=default)...
ah ok i get what you mean now.
yes this seems this was overlooked in the datacenter view
you can however register as many custom accounts you want on the cli with
pvenode acme account register
hi,
this is currently by design so that the source can't be started accidentally (since the guest would run twice in that scenario), see also: https://bugzilla.proxmox.com/show_bug.cgi?id=6017
one possible workaround would be to clone the vm...
i think this only relevant to pve not the datacenter manager? (if yes, i'll move the thread to the correct forum)
could you please provide a bit more info?
how is the host & guest network configured? what tests did you run? (ping, traceroute, etc.)
could you try to set the vga type to 'cirrus' ?
you can do this with
qm set 128 -vga cirrus
NOTE: this is one of the recommended vga types, and should only be used for old operating systems (such as this i guess), see also...
as i already wrote on the beginning of the thread, this is (at least it seems so) a tighter restriction that is requested by the hardware (in this case the mainboard) the linux kernel just enforces it now. I don't think it's a bug in the kernel...
hi,
did you try to verify the corresponding snapshot once? maybe there are reused chunks that are corrupt/broken?
indicates a problem with the underlying storage, so i'd check the journal/syslog/dmesg on the pbs host
hi,
you probably already checked, but is there a firewall active (e.g. on the PVE host?) that would prevent this traffic?
if not, wha'ts the output of
traceroute google.com
?
i'd like at least the output of
journalctl -b
dmesg
lspci -nnk
and the start task log
as well as any relevant logs from the guest (also journalctl, dmesg, lspci)
no problem, just update the thread when you have the information
well the most interesting things would be the host logs in a not working state, else i cannot even start to search where the problem might be.
As i said, a start would be to try the 6.14 kernel on the host, if that fails, we have a candidate to...
thanks for the feedback! always nice to hear that users/customers are happy :)
just fyi: if you have a subscription, you can enter it in your forum account under 'account details' and then you get a 'subscriber' badge here, so we (and others)...
sadly SMART data is not really standardized and some vendors use offsets or different units or formats for the temperature. Better monitoring for the temperature can be done by loading the 'drivetemp' module with `modprobe drivetemp` and using...
Usually there are other monitoring solutions in place, either installed on the host directly or some don't need anything special installed, e.g. checkmk (these can often connect via ssh and check the system with standard tools or via the api)
i just want to point out that I'd like to help, but as I already said with the information at hand I cannot.
You did not provide any of the information I asked for (journalctl, dmesg, lspci, etc.) from a clean state, so it's impossible to say...
as i wrote, the journal from the host would be interesting. you can get that with 'journalctl' e.g. all the logs since the last boot would be 'journalctl -b' or if you want to specify a date you can do something like 'journalctl --since 2025-09-15'