5 ms·

> I think the remaining Linux parts mostly exist as hardware drivers, and VMware is providing the core kernel routines like scheduling and memory management and

> I think the remaining Linux parts mostly exist as hardware drivers, and VMware is providing the core kernel routines like scheduling and memory management and "world" management (equivalent to process management, but it's a hypervisor). That description of vmkernel reminds me of Xen's hypervisor (dom0 handling hardware access, providing drivers but otherwise still sitting "above" the hypervisor), one technical difference I'm aware of is that Xen's hypervisor is the first piece of code loaded by the bootloader. But does that even count as a technical difference once the system is running? Does vmkernel effectively do the same thing Xen does even though it loads dynamically via the kernel module interface after the Linux kernel boots? I don't know much at all about how each of these common hypervisors (vmkernel, KVM, Xen, Hyper-V) interact with their "driver domain", and certainly I'm in no position to say whether any technical distinction in the way they each load or work will matter legally, but I've been interested in the vmkernel situation for a long time so I'll be watching closely. I'm also reminded that there seem to be several proprietary versions of Xen's (otherwise GPL'd) hypervisor that bolt on closed source features, perhaps they'll end up in a similar situation as VMWare if this goes badly for them?

hga 12y ago
I don't think so. Xen is a Type 1 "bare metal" hypervisor, perhaps like ESXi, this is about a Type 2 hypervisor like Virtual Box: https://en.wikipedia.org/wiki/Hypervisor#Classification https://en.wikipedia.org/wiki/Hypervisor#Classification. Proper Type 1 hypervisors run on top of the bare metal, boot first, and then in the case of Xen load a privileged virtual machine as Dom0 which has access to the bare hardware, which can be e.g. NetBSD in addition to Linux. Dom0's device drivers then provide as services raw block and network devices to the DomUs (and there can also be pass-through of devices to DomUs, something I'm not familiar with). So the isolation is very white line, and as we engineers view it, not GPL violating. But as someone else has noted, the address space concept is not a legal one.
- makomk 12y ago
  Unfortunately, it sounds like recent versions of ESXi avoid having a privileged Linux virtual machine for drivers by incorporating GPLed Linux kernel code into their proprietary hypervisor, which allows it to run Linux drivers and userland software directly. Which is why they're in deep legal hot water right now.
- mrsteveman1 12y ago
  This case does seem to be about ESXi though. My read of what they've been doing as their "enterprise" hypervisor evolves (it's hard for me to keep track anymore) is that they went from the old ESX bootstrapping vmkernel using Linux and a kernel module (as I was vaguely recalling in my other post), to ESXi loading vmkernel directly, and in the process of moving to this new Type-1 architecture they decided to just lump a bunch of GPL'd code from the Linux kernel in to vmkernel. I'll be interested to see more about how this thing actually works at runtime, legal issues aside. It's quite fascinating :)

hga 12y ago

I don't think so. Xen is a Type 1 "bare metal" hypervisor, perhaps like ESXi, this is about a Type 2 hypervisor like Virtual Box: https://en.wikipedia.org/wiki/Hypervisor#Classification https://en.wikipedia.org/wiki/Hypervisor#Classification. Proper Type 1 hypervisors run on top of the bare metal, boot first, and then in the case of Xen load a privileged virtual machine as Dom0 which has access to the bare hardware, which can be e.g. NetBSD in addition to Linux. Dom0's device drivers then provide as services raw block and network devices to the DomUs (and there can also be pass-through of devices to DomUs, something I'm not familiar with). So the isolation is very white line, and as we engineers view it, not GPL violating. But as someone else has noted, the address space concept is not a legal one.

makomk 12y ago
Unfortunately, it sounds like recent versions of ESXi avoid having a privileged Linux virtual machine for drivers by incorporating GPLed Linux kernel code into their proprietary hypervisor, which allows it to run Linux drivers and userland software directly. Which is why they're in deep legal hot water right now.
mrsteveman1 12y ago
This case does seem to be about ESXi though. My read of what they've been doing as their "enterprise" hypervisor evolves (it's hard for me to keep track anymore) is that they went from the old ESX bootstrapping vmkernel using Linux and a kernel module (as I was vaguely recalling in my other post), to ESXi loading vmkernel directly, and in the process of moving to this new Type-1 architecture they decided to just lump a bunch of GPL'd code from the Linux kernel in to vmkernel. I'll be interested to see more about how this thing actually works at runtime, legal issues aside. It's quite fascinating :)