Search results

I found some other thread and bug report filled about it. Looks like the same problem. https://forum.proxmox.com/threads/kvm-guests-freeze-hung-tasks-during-backup-restore-migrate.34362/page-2#post-174960 https://bugzilla.proxmox.com/show_bug.cgi?id=1453

I did some more experiments this morning and found that: - changing the vm storage from virtio to sata doesn't help - changing the SCSI Controller type from VirtIO SCSI to Default (LSI 53C895A) doesn't help + changing the network cards type from virtio to e1000 helped a little. It is still...

I found this topic here: https://forum.proxmox.com/threads/storage-san-fibre-channel-and-load-sharing.26563/ I think maybe I'm having the same issue here. All my VMs right now are capped (their disk throttled) to 30MB/s and still I have the issue. I found also that restoring from backup to the...

103.conf:

In my case the storage is not slow. It is achieving about 80-90MB/s and about 600 fsync/s (pveperf). My VMs are mostly idle, so I doubt more than 2-3% of the storage is utilized at any time. Those io wait are some spikes (probably some software inside the VMs are flushing their data) so I really...

I agree - it is not nfqueue in your case. But you are using OpenVPN. Is your bad network experience via the OpenVPN only? Because OpenVPN is also an userspace daemon. And as such you are probably affected by the same problem - userspace network related process hanging because of IO load...

try with: iptables -nvL |grep NFQUEUE it is in upper case. I guess your rules are pretty simple and you know what they are doing actually (only accept/drop/...) I'm wondering if shorewall or something else in your system is using something similar networking in userspace ? I'm redirecting...

I managed to pinpoint where exactly the problem in my system. It is only happening if I'm using NFQUEUE target in my iptables. If the network packets are routed via nfqueue for packet decision they are severely delayed if any IO wait on the system is shown. Unfortunately I really need to use...

I'm using OVS. Still have the issue.

I didn't. I'm not sure this would help in my case. I have running iostat on the cluster nodes. On all of them during this surge there is 100% utilization of the SAN for a 2-3 seconds. I don't know why is this - I don't have any big writes which can make the SAN utilization 100% But the thing...

Some iostat and ping logs to show what is happening during the hiccups (this VM is a router, the ping is to hosts behind it):

This is exactly what I'm wondering too. I was forced to emergency move elasticsearch from the guest machine because any 10-20 seconds there were network ping hiccups because of elasticsearch writing its shards to the disk, and they were not really big IO writes. Everything (disk/network) is...

Not exactly the same setup (linux guests here), but I notice too in PVE 5 there are some huge network hiccups with virtio networks on virtio disk load. IO wait induce huge network latency (1000-2000ms) and packet reordering.

I have decided to "invest" in your app and purchased the lifetime subscription ;-) I understand the current issue with OTP and I hope you can find a solution in the near future. I want to report a bug, which prevents me (and probably many others) from using it: The app doesn't honor the routing...

Yes, thanks, I know about your app. I'm glad you finally create the option to buy the app and not pay subscription every month (which is really crazy idea for such app in the first place). I'm waiting for the moment your app begin to support pve auth+otp and then probably will buy it.

Well I guess it depends on how many virtual machines you had on the failed node (Node1). If it is only one it will go only to Node2 OR Node3 ;-) If there are more than one VM they most probably will get distributed to Node2 AND Node3. If you want to restrict or control which VM goes where please...

Thank you Proxmox Team for keeping your promise to release 5.0 quickly after Stretch is released!

The disk cleanup on install now removes correctly the old stuff. No need to do manually dd if=/dev/zero of=/old/disk before reinstall anymore. Thank you guys ;-)

Hi you can use this (I have used it last week on PVE 5.0 beta1): ### Removing cluster configuration: (Perform the following steps on each node) ## stop the services systemctl stop pvestatd.service systemctl stop pvedaemon.service systemctl stop pve-cluster.service systemctl stop corosync...

I had the same issue today. Tried to install 5.0 beta1 over fresh test install of PVE 4.4. It failed on the disk partitioning operation (/dev/sda3...) I saw your post earlier today so I have booted from live CD (knoppix), removed the partition table and just to be sure did a wiping of the first...