Search results

@iMer - a dumb way to do it which works, is to have a job run that watches the backup files to see when they're done being written to, and then pushes them elsewhere.

Marco?

@Madhatter The new 4.13 kernel and modules fixed it for me on most of my machines. My others are affected by a kernel bug & an updated 4.10 kernel helped with those. ~J

Hey all, Has anyone been using pve-zsync with "IO Thread" on a VirtIO SCSI drive successfully? Any thoughts or feedback before I try it? This would seem to have the best of all worlds - minimally impactful backups + higher performing I/O. Thanks!

Is this a retail Intel processor or an Engineering Sample?

To do that he'll also need to make sure Jumbo Frames are enabled on all hardware. Just enabling it on the storage server won't accomplish much.

Are you using VirtIO disk or network drivers on the Windows Guests? Recent ones? What about the QEMU Agent? Is it installed?

Thanks Fabian. I've been following that thread closely. I'll be happy to try the test kernel when you have one.

Thanks Fabian, The 4.10/0.7.3 kernel works perfectly on my two misbehaving servers. It seems 4.13 added a regression for the Supermicro SCU on at least the X9SRW-F motherboard (C602 chipset). Attached are two snapshots of 4.13 (not) booting - the first shows the kernel panic...

Thanks J. Carlos! I suspect you meant: apt-get install libzfs2linux=0.6.5.11-pve17~bpo90 instead of libzfs2linux-dev, as -dev doesn't seem to exist on a standard install. My two servers that are misbehaving on 4.13 are manifesting a kernel panic involving an interesting isci_task_abort_task...

@hardstone - Don't reboot. I was seeing what you were & rebooted. Big mistake. I had to restore all my virtual machines to a different server. (I might have been able to do a ZFS push, to the other server, but backups had just run.) There seems to be a bug in 4.13 which is causing...

Easy doesn't mean I have the time or inclination to do so on your schedule. Moving the VM between hosts on a mixed cluster is not the problem. Dealing with downtime from failure due to 700ms+ ping times does. Not to mention my time constraints this week. Plus the issue manifests under NETWORK...

Nope, but I could. Just not right now. With all the reboots to test, there's been enough downtime on that server for the day (week!). Going back to SCSI Virtio and changing to E1000 for the network is currently behaving decently. (I have CPU to burn.)

Changing from SCSI Virtio to IDE did not solve the problem for me. I'm seeing 900ms ping times from the gateway to the KVM virt. Should be .36ms. VM is nothing special- Apache serving lots of static content. VM's drive is on local-ZFS storage. Latest Proxmox 5 with all updates, VirtIO net...

Sorry @Glock24, but the problem we were all having involved ZFS. Yours is something different, and you should probably open a new thread. What sort of storage system are you using? Same disk(s), RAID controller, or other aspects? What sort of error is it? Hard crash, kernel panic, or something...

What does your network topology look like? And did any of your storage hang?

What device names did you use? Something static like /dev/disk/by-id/* or something potentially dynamic like /dev/sd*?

What kernel is in use on the guests? There are a few virtio-SCSI & virtio general bugs that were introduced in 4.10.6 or 7 that have been patched by 4.11 rc4.

Hey Hivemind, What SATA SSD drives do folk recommend for a production cluster? I've been using consumer drives with mostly good success, but the weird ZFS write throttle issue has bitten us enough times (twice!), so I want to get something in our school district's budget for next fiscal year...

@eth: You might also want to look at limiting the ZFS ARC size. By default, it will try to use half your RAM.