[lsc]

meh. From what I've seen it looks way better for "spin up a vm every now and then to test something" - But that's not what I do. My hosts run virtuals, and only run virtuals. But eh. I know many people who are obviously way smarter than I am telling me that KVM is the way to go. (I'm actually setting up a new KVM system for my old formerly known as tile networks customers this weekend. we will see)

I also have some (perhaps irrational? I have yet to test) fears about KVM's superior ram over-subscription mechanisms. That's the thing. Having poor over-subscription mechanisms is a honest signal to the customer that you aren't oversubscribing.

KVM systems can actually hand out host swap to the guests as if it were ram[1]. In a multi-tenant 'race to the bottom' kind of environment? Well, it hasn't happened yet, but I think it's quite possible that we will see KVM go the way of OpenVZ when it comes to multi-tenant setups, simply 'cause I could sell 144 gigabytes of ram on my servers with only 72 gigabytes of real ram. Aside from performance, I don't think customers would be able to tell. If I were to do that in Xen, it would be pretty goddamn obvious (I'd have to add the swap within the guest, so you could see how much swap you were actually using, then you'd have a 'balloon' driver eating up the ram that I said I gave you that you don't have.)

To be clear, feeding guests swap as ram is the most clumsy method of memory over-subscription. KVM has some super-slick methods... some of which are partly supported by later versions of Xen. Tmem actually can gain some benefits from oversubscription without any downside; e.g. deduping memory pages and using the leftovers for read-cache, that can be grabbed back by the guest. - but that isn't going to make the guest look like it has more ram, that's just going to make disk I/O slightly better.

[1]https://access.redhat.com/site/documentation/en-US/Red_Hat_E...