Recent content by Corwin

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

Hi, Just tried to boot the last PVE iso 8.1.1, but it gets stuck directly, displaying: grub error file /EFI/ not found iso 8.0.2 boots fine...

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 ?

Old thread but still useful, thank you !

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

Ohoh the answer is YES, Monitorix is installed, checking pveproxy process and port on a regular basis, I did not imagine it could harm this way...

just posted...

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

Should be only IPv4. Yes, here is the output of ss -tanp with existing /etc/default/pveproxy (edited as it contains public IP's)