Search results

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 i'm not super sure what you mean? on pve you can create multiple accounts for ACME? i can create multiple acme accounts without a problem?

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 first and then migrate it with 'delete-source'

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...

Hi, can you post the vm config? qm config ID ? is there any setting regarding color depth or similar (i'm not very familiar with netware ;) )?

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 per se, but if you think that, a bug report to...

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 look where there might be a regression

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) know that you have a subscription no worries, we try...

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 the `sensors` binary from the `lm-sensors` package...

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 why it's working on pve 8 vs pve 9 It might be that...

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'

ok thanks for testing, then i'll continue looking for the culprit

ah ok, if that version is the culprit, then I think the cause of the bug(s) should already be fixed in git by this commit: https://git.proxmox.com/?p=pve-manager.git;a=commitdiff;h=c2e2559d2176062c44aab9fc934f67f047ac585b it's not yet bumped/packaged yet for the 8.4 branch but if some of you...

from the exceprt of the log, i guess that you're german speaking ("Herunterfahrtyp") so i guess you're currently in GMT+2 timezone? then that would somehow fit because the timestamp: is in UTC time, which would correspond to around 03:00 in GMT+2 yes, i'd assume that the shutdown would be...

could it be possible that somebody pressed on shutdown from the pve ui ? (or via the pve api/cli) ? if the guest-agent is configured and installed, it will be used when shutting down a vm from the PVE side EDIT: ah sorry, saw just now that you already looked in the task list maybe look...