Re: [Xen-users] VMWare vs. Xen, is the conflict by VMware deliberate?

["Ndex Server" <ndex.srvr@xxxxxxxxx>]

I can only get PV support (O/Ss that are AWARE they are being virtualized) in Xen.

 

This is one of the things makes this absolutely the most fascinating tech topic in the industry today, imo. 

 

It seems a lot of extra effort to have to deal with OSes that are aware they're virtualized.  Windows, for example, likes to self destruct under those circumstances which is why we're all here...   

 

My current reason for using Xen is to get DMA remapping support for PCIE devices with VMX enabled CPUs, so I must admit to a prejudice to urging the techology forward in favor of my own nefarious purposes o_O.

 

Experiments with hardware virtualization have shown that VMware's Server provides the superior performance with VMX enabled platforms over Xen 3.2 but I'm hoping that the networking issues will settle down and the *issues* with the various BIOS vendors will be, uhm, rectified so VT-d support will work or... something.  Meanwhile, I've been running VMware Server without VT-d because I want to be able to use unmodified guests.  PV isn't really appealing to me.

 

My chief complaint about VMware is that I'm tired of the 440BX chipset presented to the guest.  It's like some bad IT job that can't be escaped.  It's solid as a rock and it supports all the legacy hardware out there so 90% of the legacy x86 server farms can be run on it trivially.  It just seems pointless to me to use VMware unless you really have a need for that 440BX emulator.

 

At any rate, one solution to the problem may not be in VMwares hands but in Xen's.  The inability to *host* VMware is not VMware's failure, it is Xen's.  VMware workstation is a user space app, as is KVM.  It would be Xen that is blocking VMware's access to ring 0, wouldn't it?   Unless you install VMware as a module and load it in place of qemu?

 

I'm morbidly fascinated by the problem, but you'd have to pay me to work on it my friend!!  :-D

 

ndex 

 

 

 

On Fri, Feb 22, 2008 at 12:35 PM, Nick Couchman <Nick.Couchman@xxxxxxxxx> wrote:

It supports hardware and paravirtualization.

Only very recent versions of VMware support paravirtualization - this is a very new feature and, to my knowledge, only works on ESX 3.5 right now.  Paravirtualization requires modification of the guest kernel - MOST VMware products do NOT require that the guest kernel be modified and do not run correctly with a PV guest kernel - unless you know something about PV support in VMware that I don't.  If you have found Workstation, Player, or Server to support (provide) PV kernels, I'd be very interested to hear how you got that to work - I've not heard anything about that.

 

The reason to choose Xen over VMware are the same reason you'd choose Linux over Solaris.  Cost, support services and access to the open source. 

 

Maybe so, for the most part, but I choose Xen over VMware due to performance, as well.  Since I don't have ESX 3.5 running in my datacenter (yet), I can only get PV support (O/Ss that are AWARE they are being virtualized) in Xen.

 

-Nick

>>> On 2008/02/22 at 12:42, "Ndex Server" <ndex.srvr@xxxxxxxxx> wrote:

VMware is a fully functional, full featured virtualization engine.  It supports hardware and paravirtualization.

 

You don't run Xen *and* VMware together, that's the equivalent of running Solaris NIS+ inside Linux chroot.

 

VMware is a *closed* source commercial product which does provide a few open source packages.  Xen is an open source project which (under their new Citrix masters) also provides commercial products.

 

The reason to choose Xen over VMware are the same reason you'd choose Linux over Solaris.  Cost, support services and access to the open source. 

 

What you're suggesting is running nested hypervisors, there's NO performance advantage, no security advantage, no virutalization advantage.

 

What you are trying to do is completely illogical -- the VMware hypervisor and the Xen hypervisor cannot *both* own ring0.

 

Load a VMware Server instance on a Linux 32 bit host (on EM64T hardware) with VMX enabled then load an EM64T Guest, sent debug = "TRUE" in the guest .vmx configuration file and read the vmware.log output file. 

 

Full virtualization.

 

Then burn the box and invite everyone to the party.

 

Cheers,

ndex

 

 

On Tue, Feb 19, 2008 at 12:38 AM, Nico Kadel-Garcia <nkadel@xxxxxxxxx> wrote:

Javier Guerra wrote:
> On 2/18/08, Nico Kadel-Garcia <nkadel@xxxxxxxxx> wrote:
>
>> The bit about refusing to run with a Xen hypervisor in place was very
>> clear, however. It might be justified, but the refusal to even try to
>> start up seemed excessively harsh. I'm happy to accept a warning that
>> what I'm about to attempt with my software is a bad idea, but I want a
>> reference to exactly what the problem is or at least the ability to try
>> it, anyway, after insisting on the warning.
>>
>
> in most cases, "check; but try anyway" would be a serious bug IMO.
>
> if you're trying to run VMWare on PV, 'trying' would definitely fail,
> and quite possibly crash the whole system.  that's because PV doesn't
> emulate hardware, not even close.
>
> if it's refusing to run on HVM... well, it _should_ run, possibly with
> some limitations, and big overhead... but run.  then i would say it's
> not nice on VMWare's part
>
>

Javier, I was trying to do this on Dom0, not inside a DomU. I'll take a
shot at a fully Xen virtualized DomU runn VMWare inside it, as soon as I
get a few cycles.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users

---

This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users