[Info-vax] VMWARE/ESXi Linux

[Waldek Hebisch]

Matthew R. Wilson <mwilson at mattwilson.org> wrote:
> On 2024-11-28, Lawrence D'Oliveiro <ldo at nz.invalid> wrote:
>> On Wed, 27 Nov 2024 22:24 +0000 (GMT Standard Time), John Dallman wrote:
>>
>>> In article <vi84pm$6ct6$4 at dont-email.me>, ldo at 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