Definitively related to QEMU... Installing version 7 allows booting without any trouble, sorry, I did not check this...
QEMU emulator version 7.2.5 (Debian 1:7.2+dfsg-7+deb12u2)
It took time to answer, sorry, yes the iso was not corrupt, re-downloaded
Tried on a host server at a cloud provider while in rescue mode, as usual, I used qemu-system-x86_64 (unsure about the version) with ovmf bios. This was reproducible on a second server, but maybe qemu was not up to date...
Unfortunately diskIO stat is NOT present in container even if it is unprivileged, just checked on 7.2 (zfs system selected during installation).
Any ideas ?
Here are the last details. Upgrade seems to be completed but as I cannot shutdown the CT I prefered to reboot the host.
Now, when I start the CT I got the status 'running', but I cannot log in using the console, CPU takes 40% but only 15 MB memory, not good at all...
The host syslog only says...
mmmmh.... this is strange, as the CT only uses 130 Mb for many months. During upgrade it eats all available memory (500MB was set). I never saw this behavior...
But yes, I just increased memory to 2GB and 2GB swap and I get a slight difference : there is no hangs up anymore, the upgrade process...
Hello,
Running PVE 7.0, I'm trying to upgrade several CTs from Debian 10 to 11, but I'm stuck as it drops the connection during the upgrade process, then the CT stops.
After restarting it, I cannot connect via ssh or even using the console (amazing... it justs indicates connected, the screen is...
It seems people are able to run PVE7 on OVH/SYS/KS with some network adjustments...
Should'nt you add hwaddress in /etc/network/interfaces ?? You have to specifically use the provided MAC
I'm interested about this topic as I will do the same stuff in the coming days. As I did not fight yet, I can only *think*...
You should notice bridge configuration has changed, as stated in the documentation.
Even for a new PVE7 installation, before rebooting you need to edit...
The ss output keeps growing of pveproxy processes every few minutes as long as /etc/default/pveproxy contains at least one IP restriction.
It reverts back to normal behavior when this file is removed, as a workaround, I don't think you need this output isn't it ?
Yes, these are just IPv4 public...
So it keeps only 4 tasks after removing /etc/default/pveproxy
Loaded: loaded (/lib/systemd/system/pveproxy.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2020-11-27 10:54:56 CET; 5h 0min ago
Process: 21535 ExecStartPre=/usr/bin/pvecm updatecerts --silent...
There is only a direct connection to the host. So I removed completely /etc/default/pveproxy and restarted, and it provides instant improvement ! Sounds good... Let's see after a few hours.
What do you recommend next ?
Tasks: 4 (limit: 4915)
Memory: 158.4M
CGroup...
It works fine, great ! One last word... Here I need to use egrep without -i because of the following output matching "UNAVAIL".
status: Some supported features are not enabled on the pool. The pool can still be used, but some features are unavailable.
action: Enable all features using 'zpool...
Yes, what the hell are they doing ? Here is the (partial) output, all other lines are similar
=========
pid: 26716
-bash: avertissement :substitution de commande: octet nul ignoré en entrée
cmdline: pveproxy worker
stack:
[<0>] poll_schedule_timeout.constprop.14+0x46/0x70
[<0>]...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.