snapshotting interferes a lot with the underlying guest OS. It's impossible to pass audio, for example, with snapshotting turned on as the guest OS dispatching is delayed a "lot"
You understand that taking a 'snapshot' of a running guest involves stopping it dead and recording all of the machine's state, all memory, all virtual h/w, etc... It's then diffed against the previous to get something to store... It's hard to maintain the responsiveness that even a single call requires (100 packets per second for each active call in MBG, for example) if you snapshot a running guest.
My observations are that even with "reservations", the physical h/w you are running on makes a difference and that reservation is not always honoured, that's what the starvation alarms are doing, performing *actual* measurements from within the guest OS, they aren't lying, that's what the guest is experiencing. Moreover, most of the problems I've seen are i/o issues, so much delay between the guest linux kernel and the virtual disk that the kernel gets blocked (lookup io_wait in the 'iostat' command), this is time lost to the entire guest.
I know on my el-cheapo vmware server, I've monitored disk performance (datastore delay) and seen 100's of milliseconds being charted. Even occasionally, 1000's of milliseconds. You know the guest VM's have to be suffering.
