Search results

Wow that is an impressive find, my tcpdump shenanigans were limited to the clients since I have no pbs server running. Thank you for looking into this!

Hi there, I am trying to apply the amd64-microcode updates from Debian testing (which will probably end in stable soonish https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014593) and get the following errors: Selecting previously unselected package amd64-microcode. (Reading database ... 75640...

Given what I have seen in the tcpdumps the connection fails way before the application layer is established. It would be great if anyone could confirm those findings. So either we are hunting multiple issues here or it is pure luck that it doesn't show up. We have less than hundred backups in...

Ok, I have correlated the tcpdumps with our perimeter firewall and they show the same results. The Server-Hello is coming late. I only have one firewall in front of that now where I currently cannot get tcpdumps. But if someone from @tuxis wanted to hop on a call with me and get tcpdumps on...

Hi @mira, I also see this issue and see it so frequently that one could call it reproducable; and I am located in Austria so we could (easily?) do a debugging session. I'll try to provide some hints for you so you might be able to reproduce on your own. The issue seems to occur with TLS...

Well you tickled it well enough. I am now getting routed via nextlayer in vienna: 1 _gateway (10.7.21.1) 0.470 ms 0.428 ms 0.424 ms 2 * * * * * 3 tengig0020-1702.cr1.grazkom.at (85.237.12.1) 4.206 ms 4.476 ms 4.556 ms 4 xe-0-0-5-r25.inx.vie.nextlayer.net (81.16.152.121) 10.065...

So, short update after further debugging. After moving the testclient outside the perimeter (or at least one firewall) results didn't get better. What did help though was tunneling the traffic to tuxis through a VPN. Which leaves me with the following possibilities: * The VPN also changes the...

Hi Richard, thanks -- yeah we wrote our posts at the same time I fear :) I'll update here once I figured out where the slow down occurs. Thanks, Florian

Yeah it was better, I was close to 100 MBit: granted it somewhat fluctuates, but looking at the yearly maximum transfer rates since we started using tuxis (not that long ago): I understand that due to the delta uploads etc there might not even be enough data to saturate the link. But I am...

I am seeing slow backup speed towards tuxis currently. Dumping onto a local disk yields a few hundred mb per second but running the proxmox server benchmark against tuxis yields: Uploaded 16 chunks in 11 seconds. Time per request: 744015 microseconds. TLS speed: 5.64 MB/s SHA256 speed: 1716.83...

That is good to know, although in my case I am not trying to protect against malicious users but rather want to prevent myself and colleagues to do something we do not want to do. That said the expectation of ACLs would probably be that they actually have an effect, giving a false security...

Well as I understood it the patch is not exactly backwards compatible so I understand that they didn't not have any option other than to restore the previous behavior. Given that permissions only allow access to stuff and can't hide stuff, this will be hard to add in a backwards compatible way...

Mhm wasn't this reverted by https://git.proxmox.com/?p=pve-manager.git;a=commitdiff;h=a37ff602ff742403f01d6682bf9948183f87eadb again? If I read that code correctly it always shows vmbr* again now? Can you share your config -- are you on pve-manager 7.2-3?

I have managed to work around this problem using the following simple python script: import socket import pathlib import time import sys import pyroute2 import logging QEMU_SERVER_PATH = "/var/run/qemu-server/" def announce_self(qmp_path): with socket.socket(socket.AF_UNIX...

Hi there, I am seeing a loss of connectivity after bond failover of an active-backup bond to two switches. My setup is as follows: +-------+ +-------+ |switch1|----(inter switch lacp trunk)---|switch2|----client +-------+ +-------+...

Hi Oguz, indeed it only affects https. Thank you for the links and sorry for not looking closer into bugzilla. Cheers, Florian

Hi there, I have configured a http proxy in datacenter -> options but it seems to be ignored when trying to download an ISO image by URL in the GUI. Is that expected behavior, or did I miss some configuration. I'll happily open a bug report if you consider this a bug. Thanks, Florian

qemu-server (7.0-11) bullseye; urgency=medium * nic: support the intel e1000e model * lvm: avoid the use of io_uring for now * live-restore: fail early if target storage doesn't exist * api: always add new CD drives to bootorder * fix #2563: allow live migration with local...

If you have cache=writeback you should not have to add aio=native as far as I understood the previous comments as writeback implicitly sets this (or something very similar at least). Was that in addition to the aio changes or did you just apply the microcodes now? I ran into this on Intel...

I managed to fix this by creating a new bpool for booting with a reduced feature set.