I disagree (politely) with your assumption about QCOW2 and BTRFS performance, if I get some time this week I'll do some objective benchmarking (I design and bui

I disagree (politely) with your assumption about QCOW2 and BTRFS performance, if I get some time this week I'll do some objective benchmarking (I design and build Linux based storage systems) and see hey I might be proven wrong but regardless I can let you know the results if you're interested? People not willing to update their kernel in production environments is a social problem, not a technical problem. The kernel is one of the most reliable, well tested and reviewed software projects in the world. When you upgrade your kernel 99.5% of the time you get new features, performance and bug fixes without any negotiate impact. There are of course rare corner cases especially if running propriety hardware when they are generally slower to release updates that show the benefits of a modern kernel. The problem there is the culture and traditional slow moving operational engineered haven't all embraced the well proven fact that regular, small charges are safer and have various added benefits. There is also a serious language barrier between many engineers and management / project managers who clearly would not be likely to understand the benefit of upgrading to a kernel version that say properly supported the new SCSI blk_mq backend for storage, so there either needs to be degree of trust and respect to (proven) engineers(ing) and teams or they need to be clearly taught the value add of a fast release cycle and practising quick (hopefully automated) patching. That's where I think books like Gene Kim's - The Phoenix Project and his soon to be released book - The DevOps Handbook which may in fact be more useful to people performing PM/PO tasks.