I'm currently running with the same workaround: IDE bus for the hard disk and VirtIO SCSI as controller.
> 3000 mSec Ping and packet drops with VirtIO under load
- Thread starter Andreas Piening
- Start date
-
- Tags
- kvm network packet loss virtio
I'm currently running with the same workaround: IDE bus for the hard disk and VirtIO SCSI as controller.
I didn't want to hijack this topic for my own issue
Please see this post for the answer on your question and additional details: https://forum.proxmox.com/threads/vm-crash-with-memory-hotplug.35904/#post-181622I will post some additional test results in a few minutes there. Thanks!
Hi,
could you try to disable transparent hugepage on host ?
it was disable in proxmox 4 before january 2017, 4.4.x kernel (don't remember exactly which version), and now set to madvise by default
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag
(you need to stop/start the vm after this change)
could you try to disable transparent hugepage on host ?
it was disable in proxmox 4 before january 2017, 4.4.x kernel (don't remember exactly which version), and now set to madvise by default
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag
(you need to stop/start the vm after this change)
Last edited:
Hi aderumier,
both options was on "madvise" on my system as well (whatever this means):
I stopped my machine, set both options to never and changed by disks to scsi again (was IDE before). But the windows guest fails with "no boot device" after already presenting the spinning wheel on blue background and booting a while.
I even restored the VM to an earlier state, but I can't get it to boot anymore. It fails with a blue screen collecting a memory dump and reboots again.
Luckily I did this on my test system, so the production system is still on IDE and it is running fine since the switch.
I can't tell if switching my disks from scsi to ide and back again did any bad. But for me it is not working right now.
both options was on "madvise" on my system as well (whatever this means):
Code:
#cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never
#cat /sys/kernel/mm/transparent_hugepage/defrag
always defer [madvise] neverI stopped my machine, set both options to never and changed by disks to scsi again (was IDE before). But the windows guest fails with "no boot device" after already presenting the spinning wheel on blue background and booting a while.
I even restored the VM to an earlier state, but I can't get it to boot anymore. It fails with a blue screen collecting a memory dump and reboots again.
Luckily I did this on my test system, so the production system is still on IDE and it is running fine since the switch.
I can't tell if switching my disks from scsi to ide and back again did any bad. But for me it is not working right now.
You can easily go back to the old values by:
Or simply reboot your host.
My problem is solved with a patch from @wbumiller I asked for an updated pve-qemu-kvm package for you to test. The fix applies to virtio, maybe it also solves your problem.
Code:
echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
echo madvise > /sys/kernel/mm/transparent_hugepage/defragMy problem is solved with a patch from @wbumiller I asked for an updated pve-qemu-kvm package for you to test. The fix applies to virtio, maybe it also solves your problem.
it's 100% unrelated. Note that if you change disk from ide->scsi, scsi->ide, you need to change boot drive each in vm option.
Do you mean the transparent_hugepage setting is unrelated to the issue in general, or to the problem with my vm that doesn't boot anymore?
I can't refuse the second assumption, I had not the time yet to investigate any further.
I mean, transparent huge can't impact boot. (maybe windows don't like switch between ide-> scsi, I really don't known).
Transparent hugepage could impact performance only.
BTW, I have build last pve-qemu-kvm with patch for@hansm bug. (which is virtio related, so maybe it could improve performance too)
http://odisoweb1.odiso.net/pve-qemu-kvm_2.9.1-1_amd64.deb
I have a question - is anyone seeing i/o issues when using LXC?
If not we'll migrate some systems. We are noticing disk slowdown as time goes on . testing with xfce disk utility as per forum suggestion.
If not we'll migrate some systems. We are noticing disk slowdown as time goes on . testing with xfce disk utility as per forum suggestion.
I have no I/O issues with LXC. I have a mail server running on the same host and it performs perfectly fine and does not drop or delay packets even under load.
I just upgraded pve node and this was installed. then i restarted all kvms
Code:
pve-qemu-kvm (2.9.1-1)have you tested pve-qemu-kvm (2.9.1-1) ?
Last edited:
I can't reproduce the problem from this thread, so I'm blind currently.
Note that my pve-qemu-kvm package 2.9.1-1 is not the same than 2.9.1-1 from proxmox repo. (I have added the patch, but not changed the version number)
This thread is very interesting to me.
I have a moderately used 5 node cluster (PVE version 5.0-31 on all nodes) using OVS with 10Gig ethernet to a couple of NFS shared storage hosts.
All my VMs (~25) are configured with virtio disks using the 'virtio scsi single' controller type and all the vnics are virito with multiqueues set to equal the number of vcpus.
I see none of the symptoms mentioned in this thread.
Attached is a snapshot of my busiest host. It shows no IO delay, even though there is a lot of IO on that host.
What makes my setup any different from the people that are having issues?
I have a moderately used 5 node cluster (PVE version 5.0-31 on all nodes) using OVS with 10Gig ethernet to a couple of NFS shared storage hosts.
All my VMs (~25) are configured with virtio disks using the 'virtio scsi single' controller type and all the vnics are virito with multiqueues set to equal the number of vcpus.
I see none of the symptoms mentioned in this thread.
Attached is a snapshot of my busiest host. It shows no IO delay, even though there is a lot of IO on that host.
What makes my setup any different from the people that are having issues?
Attachments
In fact interesting. One difference I see now is that you are using "VirtIO SCSI single" and I haven't even tried that. I was using simply "VirtIO SCSI".
Can you tell the difference? Is it one single port then?
virtio-scsi && virtio-scsi-single controller are for scsi disks.
if you use virtio disks, it does nothing.
virtio-scsi single is 1 virtio-scsi pci controller for 1 scsi disk
virtio-scsi normal controller, is 1 virtio-scsi controller for 7 disks.
The main usage of virtio-scsi single is for enable iothread, as iothread is enabled on controller. (so you have have 1 iothread by disk/controller)