Recent content by tmikaeld

I'm seeing the issue on Virtual Environment 7.1-12, running ZFS with Encryption enabled for the CT-Volumes. Does it affect the services? Aug 22 15:30:14 devbox lxcfs[1182]: proc_fuse.c: 980: proc_stat_read: Write to cache was truncated Aug 22 15:30:15 devbox lxcfs[1182]: proc_fuse.c: 980...

I have the exact same issue, tried upgrading, removing container, doing nested/unnested/unprivliged/priviliged etc... no avail. SOLVED: Not sure why, but changing IP fixed it, maybe DHCP or colliding IP in the above range (in our case)

Network issue on Hetzner, didn't occurr on new servers so moved to a new node and the problem is gone.

I've been running Proxmox Containers on the Hetzner Cloud without any issues for more than a year, upgrades, restarts etc worked fine. However, yesterday none of the containers can reach the local server IP or any network at all. I'm using floating IPs assigned to the container directly. The...

I'm running proxmox (Latest community) on a Hp micro server gen 8. Every time i create a new CT and start it, I get this error: <root@pam> end task UPID:local1:000079DF:007F34B9:5AC8B6C3:vzstart:103:root@pam: command 'systemctl start pve-container@103' failed: exit code 1 And nothing else in...

And like @giuliolinuz says, removing --sparse is the only thing that helps, disabling ZFS only helps for future written files not the current ones on disk (Already compressed).

I've also got the same issue, I was the one that commented on the bug-tracker. Would be nice if we could get an official Proxmox answer on this issue, It's extremely annoying and present in all of our backups and VM's (Since all of them use special characters in one way or another).

They initiated a fix even without me having to prove it this time (I did refer to the previous ticket) and they added a MAC address to the router and that fixed the issue.

Again i have this issue but this time on THE MAIN SERVER IP!!! This is getting so tiresome it's ridiculous!! This time doing an ARP ping does "fix" the download, but it does NOT solve the uplink that is below 20Mbit/s. Maybe it's time to make some noise on Webhostingtalk and other places so...

I just want to point out that this is only a temporary fix that OVH have applied, if you change the server that the IP range is bound to - the speed will again be slow after 7 minutes.

This is clearly a router/gateway issue, doing an ARP Cache broadcast towards the OVH Gateway, restores speed again for 7 minutes! Do this on a VM and see for yourselves: arping -c 1 -S VMIP GATEWAYIP EDIT: arping included in iputils is not the same, i had to do apt-get install arping for it to...

Even doing /etc/init.d/networking restart is enough to reset the speeds for 10 minutes. But yeah, they are simply not listening.

They said that they cannot test failover IP's, they only test the main host IP - which i've tried to make clear several times now - works just fine.

They want to do network tests on my production node, would you mind sharing your ticket number so i can save them and us the trouble of doing the same tests again? EDIT: I sent you a PM

They didn't do anything about it yesterday even though they said so over the phone and no one touched the ticket. This is murdering our business...