Talk:VMware

'ESX's kernel is definitely NOT Linux' - but requires Linux

See the ESX FAQ for details, the key part is "it is not derived from Linux or FreeBSD." Within the company, the ESX kernel is known as the "vmkernel," and the Linux-based "console OS" is essentially a specialized VM. Running "uname" there tells you that it's vmnix/Linux, just as a FreeBSD virtual machine that you log in to will tell you that it's, well, FreeBSD. The kernel source for this special vmnix VM can be found at ESX open source.

Beware of ignorance, ESX Server is very well based on a Linux 2.4.9 kernel, thats why they provide the GPLed sources at the address mentioned above. The mkvmnix script takes care of the patch job. Besides VMware uses ISOLINUX to make their installer CDs. They've stripped down the kernel so to provider better stability in those drivers needed to operate ESX (NIC's and SAN HBA's) --62.2.200.154 13:11, 6 June 2006 (UTC)

From the cited URL: "ESX Server runs natively on server hardware, without a host operating system. The ESX Server virtualization layer is a highly compact and efficient operating system kernel entirely developed by VMware for optimum virtual machine performance. This allows ESX Server to fully manage the hardware ::So, yes, ESX Server includes a full Linux installation (the service console), but it's a VM that runs inside a hypervisor based on a non-Linux-kernel. I suppose it runs alongside the user-configured VMs. The sources you are referring to are obviously just the sources for the modified kernel of the service console (as required by the GPL), not for the vmkernel (i.e. hypervisor kernel).

I can see at least two reasons why the VMs would not run directly under a Linux kernel: First, VMWare might not want to disclose the source code for certain functions that cannot be implemented in Linux user land. Second, and this reason is stated by VMWare themselves, better security. Think about it: If all the VMs would run as Linux processes then hijacking one VM by means of a bug in the virtualization code would likely give an attacker easy access to resources of other VMs. You could try to work around this problem by letting each VM run as a different user, using chroot to hide parts of the filesystem etc., but it's hard to achieve this separation and easy to miss something. Also, while many privilege escalation and chroot breaking problems have been fixed in the history of Linux, it's hard to say whether there are more.

On the other hand, a microkernel-based approach would allow hypervisor security to be designed properly and (from a security perspective) optimized for this single purpose. There's also less code to audit (mostly memory management, message passing and authorization) in the kernel and in a separate resource service that would (so I guess) authorize VMs to use certain resources depending on configuration. Of course, this architecture does not support the wide range of applications that Linux supports, but the whole point is that it does not even need to! Anything that's necessary for server administration but does not run at the hypervisor microkernel level can be run at the service console level, which from the point of view of the hypervisor is just a VM with certain extra privileges (for example, sshd and the webserver run in the service console). The service console is meant to only provide administration services, so for example if you're a web-hosting provider, you would not even allow ordinary users to connect to the service console, for example by blocking all access in your company firewall. And even if you manage to hijack another (user) VM process, you'll have a hard time hijacking other user VMs or the service console from there or even accessing resources that the hijacked VM process is not allowed to access.

Long story short, yes, a GNU/Linux-based VM is an essential part of ESX server as it's necessary for administration via the ESX server web interface and/or SSH. But that does not mean that the actual user VMs run under GNU/Linux. In fact, it's easy to see that they don't, unless VMWare is not only lying but also using rootkit-like methods for covering up their lies. (I have no reason to assume either, without actual evidence from your part.) For example, log into the service console using SSH and execute "free". On one of our ESX servers, the service console has only 256M RAM, which is far less than what the user VMs are using. vmware-vmx processes are visible via ps, but they are not in /proc and have far less CPU time than necessary to run our VMs over their entire uptime. So I'm guessing that these process table entries refer to hypervisor processes and are made accessible in the modified Linux kernel to enable or facilitate VM management. Also, the service console /proc/cpuinfo reports a single processor whereas this ESX server runs on a 4-way Opteron system. If you dig deeper into the information from /proc, I'll bet you'll find many more similarities with the configuration reported in user VMs. Aragorn2 20:38, 16 November 2006 (UTC)

Insert::Further proof that the service console is a special VM is found in that I've had the service console crash, i.e. not able to logon-even from the console, not able to ping the console IP address, etc, and yet, all the VMs on the host continued to run just fine. So the service console is just used to bootstrap the host, set up some system services like raw access to the floppy and CD drives and then it boots the vmkernel. It is somewhat like NetWare which used DOS to bootstrap which in turn loaded server.exe. You could remove DOS from running once the server was up since it was not needed once it booted. deandownsouth:66.21.26.4 18:43, 19 December 2006 (UTC)

I work for VMware, so will not edit the article because of NPOV policies. ESX Server's vmkernel is definitely not Linux or derived from Linux. A good citation for the relationship between the vmkernel and the Service Console is Chapter 2 of Oglesby, Herrod, and Laverick's ESX Server Advanced Technical Design Guide. Jtroyer 23:42, 11 May 2007 (UTC)

Does working someplace mean you really know waht you're talking about? If it's "definitely not Linux or derived from Linux" - then how come when I do a "diff" on the ESX SCSI driver source code, do I find that it's 90% compatible with the original Linux open sources ?

If your tech team stole GPL code (eg: RedHat AS3u6), modified it, and shipped it re-badged as "ESX" - do you think they'd *advertise* they did this to all vmware staff???

Here's a test to try - pretend you're not a vmware employee, and email vmware asking for the GPL source code (hint: read the GPL 1st - especially the bit about the requirement to provide *all* the bits needed to build the binary). You'll never get it. I've spent 2 years trying. VMware have secrets, and they're keeping them diligently.

JTroyer: that vmkernel isn't Linux doesn't change the fact that it is loaded by Linux, and that Linux is required to run VMkernel, and continues running while ESX is, according to the guide you've pasted. I've yet to see any VMware products which can run without an existing kernel. deadndownsouth: If the Linux kernel had crashed - as opposed to the userspace - the vmware kernel wouldn't have a proc filesystem to use, and wouldn't be able to allocate memory on the hardware, as both these tasks are provided by Linux while the ESX server runs - see references in article. Mike MacCana, 2007 05 25

I don't see your point. JTroyer didn't deny the fact that vmkernel needs the Linux kernel to work. What are you arguing about? Nikos 09:43, 25 August 2007 (UTC)

ESX has two kernels according to VMware - Linux, and vmkernel

Yes, vmkernel is not based on Linux. But according to both the ESX FAQ, and any ESX machine's boot process (a video of which is referenced on the page), the first kernel started on an ESX host is Linux, but it loads vmkernel (also described by VMware as being a kernel) which is, according to VMware, not based on Linux.

In traditional systems, a given operating system is considered to have a single kernel. The VMware FAQ mentions that ESX has both a Linux 2.4 kernel and vmkernel. Hence confusion over whether ESX is based on Linux. vmkernel is not based on Linux according to vmware. But vmkernel can not be started without Linux.

Mike MacCana, 2007 05 25

VMware vs DOSbox

Can anyone comment on this quote from the Windows XP Professional x64 Edition page:

Another solution is to use virtualization software like VMware or VirtualPC to run other versions of Windows or MS-DOS, but are considered "hellishly slow" to users compared to the aforementioned DOSBox. DOSBox will also allow 16-bit Windows applications to run by running Windows 3.1 on the emulator

I've always believed and heard that DOSbox is in fact slower then VMware and other virtualisation software. This makes sense because it's an emulator even if it does do dynamic translation on i386 machines. As such, this comment sounds incorrect to me. But I don't have enough experience to say for sure. If you're reasonably sure that this claim is incorrect, please go ahead and edit the Windows XP Professional x64 Edition page. Nil Einne 19:50, 24 July 2006 (UTC)

Running real mode code in VMware is slower than DOSBox; real mode has to be emulated even in VMware, and DOSBox has a faster emulator than VMware. At least from my own experience; the difference can sometimes be devastating, with the same DOS game running about 20 times faster in DOSBox than it does in VMware. Nikos 09:48, 25 August 2007 (UTC)

Version history wanted

Microsoft Virtual PC does have the version history, but VMware doesn't -- even though it's older (AFAIK). Even a brief version history is welcome; I've tried to google, but I can't find anything relevant myself. --tyomitch 11:54, 2 August 2006 (UTC)

Version history is listed at the download page of each VMware product. Nikos 09:51, 25 August 2007 (UTC)

Really? Then please read for me when VMware Workstation 3.0 was released. And when was the first public version released ? --Xerces8 07:28, 3 September 2007 (UTC)

Not an advertisement, but not an encyclopedia article either!

This starts out as an article about a corporation, but ends up being a highly specific technical discussion of a software product. "Known Issues" section?!?! Would this be "known issues" about the corporation?

With a new software release, or just release of a few patches, and a fair amount of information in this article becomes obsolete.

It seems to me that, if this article is indeed about the corporation, then most of the detailed product information needs to be moved to a separate article.

This product family clearly has a large number of knowledgeable and devoted fans. However, I would "call the question" on how much detailed technical information about the current state of a software product is appropriate in an encyclopedia article.

Thanks for your consideration. Keep up the good work.

Carl Gusler 02:42, 23 June 2007 (UTC)

CPU variants

Does anybody know, if different CPU variants are supported by VI3 DRS / HA? I once heard from SUN (an official VMWare ESX Vendor) that VMWare does not support DRS and HA on different CPUs - and different CPUs are CPUs with a different stepping! Does anybody know something about this? (If so, this would be an additional limitation to the VI.) --Sophis 18:59, 26 June 2007 (UTC)

Known issues

In my opinion it is not an issue that some kind of NAS / iSCSI / FC storage must be used for HA and DRS. This is the only logical way to implement this. I think this issue should be removed. --Sophis 19:09, 26 June 2007 (UTC)
I totally agree with Sophis. If the article is going to list the requirement of shared storage as an issue, it should also list the requirements of network cables and power as other potential issues. 68.164.207.118 04:08, 30 June 2007 (UTC) CCOSTAN

Looks, that nobody else has a problem, when I remove this now ... :-) --Sophis 22:04, 3 July 2007 (UTC)

Infrastructure Limitation?

I think the statement of VirtualCenter being a single point of failure is incorrect. Although, there is normally only one VirtualCenter Management server managing a particular ESX host at a time, you can have multiple Management servers in your environment if you so choose. Also, if VirtualCenter does fail, only DRS is affected. HA and the ESX hosts continue to function and each individual server can also be managed directly. If the VirtualCenter server ITSELF is a Virtual Machine and there is a Hardware failure on it's host ESX server, HA will kick in and restart the virtualcenter VM on another server providing some level of protection. I am not sure if all of this is appropriate but at the very least, the 'limitation' statement should be removed since I believe it to be more of an opinion than fact. 68.164.207.118 03:41, 30 June 2007 (UTC) CCostan

You are right: if the Console fails, the systems them selfs continue to run. Sorry for this - I think I mixed something up - maybe Sun N1 or so... --Sophis 22:01, 3 July 2007 (UTC)

External Links

I'm really new at this, but is okay to have so many external links to the company's site? It seems a bit like advertising to me. CP2002 22:32, 27 June 2007 (UTC)

So what's the difference between the VMWare products now?

The current way the products are being described, doesn't leave much of a clue about their actual differences. I came here to get information about just that, but just like the VMWare website this article fails to describe the products in an understandable way, instead it's only marketing or press blah-blah.--87.122.30.84 14:45, 7 July 2007 (UTC)

• I'm no "expert" but I have worked with VMWare stuff for several years. VMWare Player only 'plays' VMWare images. The VMWare images cannot be modified or created. VMWare Workstation is for use on workstations (desktops...)- typically in a testing/development scenario. VMWare Fusion is for OSX. VMWare Server is a daemon (service) that runs and is for use with servers that run 24/7. VMWare Infrastructure (formerlly ESX) is for Datacenters that require a higher level of tuning/performance, in addition to services such as DRS, HA, and other datacenter level services. Hope that helps...Gallwapa 19:53, 17 July 2007 (UTC)

Nessus sucking under VMWare

Nessus runs abysmally slow under VMWare and even Tenable discourages doing this. Oddly enough, I pulled up VirtualBox and Nessus runs great.

Guessing off the top of my head, I'd say that VMWare runs the Ring-0 guest OS in Ring-3 and encounters problems with memory protection. The top 1GB or so of memory holds the kernel's memory space in every process on Windows and Linux; but the Ring-3 code can't access this because of the Ring-0 protection level. Now, with Ring-3 OS execution, the OS memory has to have Ring-3 protection, allowing the Ring-3 application code to break this; alternately, some form of page table alteration or flipping has to occur on every syscall entry into and exit out of the kernel, meaning every network or file access or whatnot causes expensive housekeeping as well as tons of TLB and cache issues. Operations become extremely slow, causing database loads or things like Nessus to drop performance massively. It could use segmentation, but this would cause other issues and still leave cache and TLB isses.

With VirtualBox, Ring-0 executes in Ring-1. Again guessing, this would allow VirtualBox to use real memory protections and avoid most of the above page table handling issues and TLB/cache flushes needed to keep application code behaving. Execution would more closely follow native behavior, better utilizing the facilities of the real processor and effectively eliminating most if not all of the related work done for virtualization. This leaves only the trapping, emulating, and rewriting of privileged instructions to deal with; and rewritten privileged instructions behave similar to a paravitrualizing hypervisor like Xen, evading the trap-and-emulate behavior for the most part.

I'd be interested in seeing a discussion on this land here and/or in VirtualBox, if someone can find reliable technical information to confirm my above suspicions or to explain what's really going on here. As it stands, I'm fairly convinced the technique used by VirtualBox simply stands superior to the technique used by VMWare; occasionally someone does come up with an interesting new way to do something much better, and Innotek may have done just that.

VirtualBox only has one monitor, which is based on VT hardware-assist virtualization. VMware utilizes multiple monitors depending on the guest OS, some of which use VT and some of which use binary translation. Syscall-heavy loads like Nessus probably perform better with VT than with binary translation. Try it under a 64-bit OS (which utilizes VT under VMware). You should also consider trying a paravirtualized Linux distribution, like Ubuntu 7.04 (add vmi.present = “TRUE” to your .vmx file). --Che Fox 21:35, 7 July 2007 (UTC)

VirtualBox doesn't use the hardware VT stuff much at all. They have experimental AMD SVM support but they again don't use it. They find they can do it faster in software. VirtualBox does use Ring-1 for Ring-0 code, and uses in-place patching for annoying or dangerous code. --68.33.112.13 17:01, 8 July 2007 (UTC)

Hm. I guess I stand corrected. (I just read the VirtualBox architecture wiki.) --Che Fox 17:19, 8 July 2007 (UTC)

Non-NPOV Removals

Notice: I work for VMware on performance.

I removed the XenSource advertisements in the the performance section. The contents were not NPOV. If someone is going to claim bad performance for VMware in an area they need to cite sources. If they're going to claim superiority of of another product, it should be done on that page. —The preceding unsigned comment was added by ScottDrummonds (talk • contribs) 23:32, July 20, 2007 (UTC)

The text in the performance section cited both excerpts from the installation of Nessus from Tenable's RPM and the performance measurements made by XenSource. Comments about VirtualBox were added to avoid driving people directly from VMWare to Xen in an advertising manner; however, the performance assessments under VirtualBox were original research added under WP:IAR in order to improve the NPOV nature of the text by facilitating non-advertisement. --John Moser 15:08, 23 July 2007 (UTC)

More of the same, here's some stuff from the CTO at Tenable. [1]. There seems to be some definition of "Abysmal" and "Performance" here I'm not aware of (abysmal means limitless...). Statements on Nessus retracted; however, XenSource has some benchmarks and there has been much talk around the net about VMware vs "OS Intensive Loads." --John Moser 19:53, 25 July 2007 (UTC)

John, note that I have recently learned that, as a VMware employee, I am not supposed to be editing these pages. So, I'm going to refrain from doing so again. However, as a closing thought on the issue, and speaking as a huge fan of Wikipedia, I think that a certain boundary should exist in the content of competitors. For instance, check vmware.com/overview/performance and you can find several papers citing superior performance of ESX Server over free source Xen and XenEnterprise. And while the rules of Wikipedia permit me to go add these links and discussions on the subject to the Xen pages, I find that type of insertion a offense to the intent of this wonderful site. I'm not going to do that and I hope that the rest of the contributing pool agrees that doing the same to VMware's page is equally contrary to the goals of Wikipedia. ScottDrummonds 02:10, 3 August 2007 (UTC)

The problem with you guys is that you see Wikipedia as an advertisement opportunity. You said "if they're going to claim superiority of of another product, it should be done on that page," which confirms it. Articles are not supposed to claim superiority of their subject. You guys are almost as bad as the vandals. Nikos 10:03, 25 August 2007 (UTC)

Broken Link

The link (as of the writing it is reference 4): [ESX Server Advanced Technical Design Guide] is broken. I did not find the new location of the document. Can anybody help? --Sophis 09:58, 29 July 2007 (UTC)

Paragraph mentioned twice

The second paragraph in VMware ESX Server is a repetition of two sentences of the first one. My suggestion: remove the second paragraph. --Sophis 10:15, 29 July 2007 (UTC)

esx vmkernel module linux kernel derivative

I think someone should mention the potential problems found here: http://www.venturecake.com/the-vmware-house-of-cards/ maybe its already on the page, but I didnt see the link or any mention of a hint of doubt being cast on the esx server. —The preceding unsigned comment was added by 71.233.245.243 (talk • contribs) 22:00, August 16, 2007 (UTC)

Yes and No - The point in possible GPL violation is not, that ESX Server is booted with Linux (as described in the cited article) - it's (as stated in the bottom of The Register Article http://www.theregister.co.uk/2007/08/16/vmware_derived_from_linux/), that the ESX Server uses GPLed Linux - Kernel modules. --Sophis 06:18, 18 August 2007 (UTC)

Suggestion: ESX Server: add architecture section

The section about the ESX Server only views the ESX Server from the point of Linux. There is no architectural overview. My suggestion: add a sub-chapter 'Architecture' and describe some of the (documented) internals of the ESX Server, move the current content of the section to a new subsection 'ESX Server and Linux dependencies'. The content of the 'Architecture' section is something like: 1) Interaction with hardware 2) Handling guest systems 3) device handling 4) disk handling (FC, iSCSI, ...)

Ok? If so, I can start in the next days with some first version. --Sophis 06:29, 18 August 2007 (UTC)

Nobody said No :-) so I just added the section as suggested. I think the new section Dependencies to Linux needs some cleanup. In my opinion some things are unclear and may be better structured. Any suggestions for this? --Sophis 07:00, 23 August 2007 (UTC)

The ESX Server content has been migrated to VMware ESX Server, as part of my initiative to move the product-specific content to separate articles. — EagleOne\^Talk 18:44, 21 September 2007 (UTC)

Suggested split

Looking at the article as it is now, its some kind of hodgepodge composition of VMware as a company and VMware products. Perhaps some of the more major products should get their own article, or a VMware products page should be made so that the VMware article can be focused more directly on the company itself.--Oni Ookami Alfador^Talk|@ 19:06, 24 August 2007 (UTC)

I just completed the migration to separate product articles for each of the major products. We still need to untangle that mess called the Known Issues section, can copy each bullet point to the respective articles. Once that information has been added to th product articles, I think it can be deleted from this page. — EagleOne\^Talk 18:40, 21 September 2007 (UTC)

Tools for VMware

Hello. I would like to ask you to include the website http://www.veeam.com/ to and external links section. Veeam company develops very usefull tools for managing VMware ESX infrastructure. Thanks. —Preceding unsigned comment added by 80.249.183.82 (talk) 09:54, 10 January 2008 (UTC)

Wikipedia isn't an advertising medium. 74.39.225.12 (talk) 15:40, 18 January 2008 (UTC)

So, ah, what does it do?

Sorry for this silly question. I came to this article because one person told me that VMware would let me run Windows applications under GNU/Linux, but another told me that this would require that I have a copy of Windows installed on the computer on which I'm running GNU/Linux.

After reading the intro and most of the article, I've learned nothing :-/

The article talks non-stop about the features of VMware, but could someone mention it's requirement? Thanks in advance. --Gronky (talk) 11:43, 5 March 2008 (UTC)

Hi, Gronky. This page is more about VMware Inc., the company, not the VMware software products. The information that you're looking for is on the VMware Workstation and VMware Server articles. Also, near the top of the page, we have a link to List of VMware software, which lists just about every app from the company. I suggest looking at those articles for more information. — EagleOne\^Talk 18:50, 5 March 2008 (UTC)

Aha. Thanks. When I've read more, I'll come back and review how to prevent others from being confused as I was. --Gronky (talk) 08:28, 6 March 2008 (UTC)