Re: VMWARE/ESXi Linux

Matthew R. Wilson <mwilson@mattwilson.org> wrote:

On 2024-11-28, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Wed, 27 Nov 2024 22:24 +0000 (GMT Standard Time), John Dallman wrote:
>

In article <vi84pm$6ct6$4@dont-email.me>, ldo@nz.invalid (Lawrence
D'Oliveiro) wrote:

>
On Wed, 27 Nov 2024 16:33:56 -0500, David Turner wrote:
>

I keep being told that VMWARE is not an OS in itself.
But it is... based on Ubuntu Kernel....  stripped down but still
Linux

 
And not even using the native KVM virtualization architecture that is
built into Linux.

 
History: VMware ESXi was released in 2001 and KVM was merged into the
Linux kernel in 2007.

>
In other words, VMware has long been obsoleted by better solutions.

 
Please explain how ESXi is obsolete, and how KVM is a better solution.
 
Both KVM and ESXi use the processor's VT-d (or AMD's equivalent, AMD-Vi)
extensions on x86 to efficiently handle instructions that require
hypervisor intervention. I'm not sure how you'd judge which one is a
better solution in that regard. So the only thing that matters, really,
is the virtualization of everything other than the processor itself.

Little nitpick: virtualization need to handle _some_ system instructions.
But with VT-d and particularly with nested page tables this should
be easy.
 

KVM is largely dependent on qemu to provide the rest of the actual
virtual system. qemu's a great project and I run a ton of desktop VMs
with qemu+KVM, but it just doesn't have the level of maturity or
edge-case support that ESXi does. Pretty much any x86 operating system,
historical or current, _just works_ in ESXi.  With qemu+KVM, you're
going to have good success with the "big name" OSes...Windows, Linux,
the major BSDs, etc., but you're going to be fighting with quirks and
problems if you're trying, say, old OS/2 releases. That's not relevant
for most people looking for virtualization solutions, and the problems
aren't always insurmountable, but you're claiming that KVM is a "better"
solution, whereas in my experience, in reality, ESXi is the better
technology.

What you wrote is now very atypical use: faithfully implementing
all quirks of real devices.  More typical case is guest which
knows that it is running on a hypervisor and uses virtual
interface with no real counterpart.  For this quality of
virtual interfaces matters.  I do not know how ESXi compares
to KVM, but I know that "equivalent" but different virtual
interfaces in qemu+KVM may have markedly different performance.

(As an aside, VMWare's _desktop_ [not server] virtualization product,
VMWare Workstation, looks like it's making moves to use KVM under the
hood, but they have said they will continue using their own proprietary
virtual devices and drivers, which is really what sets VMWare apart from
qemu. This is a move they've already made on both the Windows and Mac OS
version of VMWare Workstation if I understand correctly [utilizing
Hyper-V and Apple's Virtualization framework]. This makes sense... as I
said, the underlying virtualization of the processor is being handled by
the VT-x capabilities of the processor whether you're using VMWare,
VirtualBox, KVM, etc., so when running a desktop product under Linux,
you may as well use KVM but you still need other software to build the
rest of the virtual system and its virtual devices, so that's where
VMWare and qemu will still differentiate themselves. None of this is
relevant for ESXi, though, because as has been pointed out earlier in
the thread, it is not running on Linux at all, so VMKernel is providing
its own implementation of, essentially, what KVM provides in the Linux
kernel.)

From what you wrote seem that ESXi is more similar to Xen than to
KVM+qemu, that is ESXi and Xen discourage running unvirtualized programs
while in KVM+qemu some (frequently most) programs is running unvirtualized
and only rest is virtualized.  I do not know if this sets limits on quality
of virtualization, but that could be valid reason for ESXi to provide its
own kernel.

--
                              Waldek Hebisch