Recent content by skraw

Ok, i found another thread with quite the same problem showing up: https://forum.proxmox.com/threads/trying-to-shrink-qcow2-image-to-make-space-for-another-one-on-the-proxmox-host-image-gets-corrupted-after-resize.119920/ Only he tries to enlarge the disk. With the hints he gave I found that...

sometimes the real problem hides behind a simple question. In the meantime I found out that qemu-img resize does not work but shoots the disk resized, no matter how few bytes you shrink it. How about that?

Hello all, I have to move around some physical boxes and virtualise them later on. So I came across this question about qcow2 images and cannot find a conveniant solution for it. Lets assume having a qcow2 disk image with a big virtual size and a relatively small partition size inside. How can...

Now, I investigated the problem further and got the impression that the kernel on client and server side must have some influence. The problem arose after a proxmox kernel update. My client kernel with problems was 6.12.something. I had another box that nfs-mounted another zfs volume from the...

Ok, to make the story a bit simpler. You are right, the problem turns around mtime. But you seem wrong about the rest. If I do an "ls -l"' on the source dir of the rsync I see some dates/times for every file. These are of course mtimes. If I do the rsync as stated (-avxAHX) I see (before last...

Hello, it seems I see a problem with my proxmox based nfs server (on host) on a zfs volume in conjunction with a nfs-client using rsync. Once a month I copy some files with rsync -avxAHX from some place to a nfs-mounted fs coming from a proxmox nfs-server exporting a zfs volume. This has never...

No, I don't have a fine-grained monitoring, and really, this is not exactly the point. I am very sure that all your working nodes are built on an empty network, just like the proxmox doc for corosync says. The thing is this: if I have even an 5-min-average throughput of about 400 MBit, a GBit...

Just to make that clear again: the networt link is not saturated. Monitoring shows an average of around 400 MBit/s on a GBit interface. Which means it is quite far away from a bandwith problem. So the real question here is: why are packets lost at all? And still: how does corosync really "find...

kernel is 6.17.13-2-pve, exactly the one pve-enterprise installs. The modules is indeed available Thanks

I wanted to try the problem situation with a bbr congestion variant. But I found that the kernel delivered with proxmox does not supply this congestion protocol. Why is this?

That is not the complete truth. Look at this: --- 192.168.192.250 Ping-Statistiken --- 14000 Pakete übertragen, 13862 empfangen, 0.985714% packet loss, time 14133836ms rtt min/avg/max/mdev = 0.103/1.065/3.615/1.127 ms This is quite a long running ping during nfs load. If there was really heavy...

No, the fiber link is dedicated, the copper is also used for other purposes. I checked that in detail and had to find out that the latest kernel networking is not really as good as one might think - after all those years. If there is nfs traffic (ok, heavy nfs traffic) going on on the link ICMPs...

There is definitely no address conflict.

Hello all, I recently experience a problem with corosync showing link flapping, but it seems to me that these are really fake. Neither the corresponding switch shows a link problem, nor the kernels of the boxes (3-box cluster). I use a 10G fiber main links and 1G copper backup links. Flapping...

We could not use pve8 because of the old zfs version included there. We incorporated a zfs volume from another setup which only worked with the zfs version of pve9. Mount was not possible with pve8.