| |||||||||||||
|
| |||||||||||||
No VT? No fair to *any* of the platforms reviewed.No VT? No fair to *any* of the platforms reviewed.Posted Feb 13, 2008 1:54 UTC (Wed) by xoddam (subscriber, #2322)In reply to: Virtualization in Linux: A Review of Four Software Choices (Techthrob.com) by Felix_the_Mac Parent article: Virtualization in Linux: A Review of Four Software Choices (Techthrob.com)
... and for the same reason not a reflection of the performance of *any* of the virtualisation environments on a VT-capable processor. Performance of *all* of them is likely to be better with fully-virtualised hardware than with paravirtualisation that traps everywhere. Mind you, there are still a lot of non-VT processors out there, so these 'gut feeling' performance benchmarks are of some use to those of us still running them.
(Log in to post comments)
No VT? No fair to *any* of the platforms reviewed. Posted Feb 14, 2008 3:38 UTC (Thu) by walken (subscriber, #7089) [Link] Full disclosure: I'm a VMware employee. VMware would not use VT even if the box supported it, because current VT hardware is slower than the emulation techniques we can do in software. VT holds some promise of getting faster in future CPU generations, and it does make things simpler if you don't already have the software emulation techniques implemented, but it is not a silver bullet as of today...
No VT? No fair to *any* of the platforms reviewed. Posted Feb 14, 2008 4:06 UTC (Thu) by xoddam (subscriber, #2322) [Link] > current VT hardware is slower than the emulation techniques we can do in software. I'm intrigued (though not *quite* incredulous). ... I suppose that's not the sort of comment your employer would encourage you to elaborate upon in a public forum, though? I would have thought the best you could do in a generic way would be to trap, though I suppose numerous specific performance optimisations are applicable if you're intimate with your various guest OSes.
No VT? No fair to *any* of the platforms reviewed. Posted Feb 14, 2008 8:37 UTC (Thu) by walken (subscriber, #7089) [Link] Well I can't tell *all* about the secret sauce but the main ingredients are already known... See http://portal.acm.org/citation.cfm?id=1168857.1168860 for example for a relevant published paper. VMware can use binary translation - a technique that is actually quite similar to what qemu or many java JIT environments are doing. It's complex but surprisingly inexpensive if you do it right. Since we don't directly execute the guest kernel code but rather a translation of it, we have an amount of flexibility not available in hardware - if we find out that our translation for something traps too much, we can look at it and figure out an alternative translation that will trap less. The first generation VT hardware, on the other hand, is actually quite limited, it provides all the traps you need to write a trap-based virtualization monitor, but in the end you still have to handle all these traps. Most notably the page table virtualization is left out as an exercise to the monitor implementor - this ends up being a lot of traps and with not much one can do about them other than waiting for future generations of VT hardware. Don't get me wrong though, hardware virtualization *will* get faster eventually... it just takes a while though, due to cpu design cycles being longer than software design cycles :)
No VT? No fair to *any* of the platforms reviewed. Posted Feb 14, 2008 15:35 UTC (Thu) by sg7jimr (guest, #22837) [Link] This statement about VMWare not using VT is not completely accurate. In order to have 64 bit virtual machines an Intel processor must have VT extensions for VMWare to allow it to run. That implies that VMWare does in fact make use of VT to some extent. It was not only necessary for the processor to support VT but those extensions had to be enabled in the BIOS, so it seems a real dependency and not some marketing thing.
No VT? No fair to *any* of the platforms reviewed. Posted Feb 14, 2008 14:58 UTC (Thu) by danpb (subscriber, #4831) [Link] The first generation of VT enabled hardware is not really focused on performance - it is more about enablement - ie it allows you to run unmodified guests, with the minimal software tricks. There are many ways to virtualize without hardware support and many of them will outperform current VT hardware. eg paravirtualized Xen will easily outperform VT enabled fullyvirtualized Xen. 2nd generation VT enabled hardware is starting to add some interesting features (NPT on AMD, EPT on Intel) that can make a huge difference to performance bringing fullyvirtualized guests closer to being on a par with paravirtualized ones. You still need to have paravirtualized drivers inside your fullyvirtualized guests though - without it I/O will be terrible. The article in question is really quite badly done. Plain QEMU is not really interesting unless you need to do cross-architecture virtualization, eg PPC on x86 - no one will claim you should use it for native x86 on x86 because emulation is simply never going to be fast enough. KVM's future is very bright indeed, but if there's no VT then it reduces to just QEMU emulation, so the review was rather worthless wrt to KVM. If you're talking state of art, then KVM should be compared against Xen paravirt and Xen fullyvirt since that's the most commonly used open source virt out there today, and for all its flaws Xen (eg not being in upstream LKML) does work pretty well in terms of performance. Finally, paravirtualized drivers should be used in all tests, since I/O performance will inevitably suck without it and anyone seriously deploying virtualization in production will use paravirtualized drivers.
|
|
||||||||||||