|
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 > >
shot at a fully Xen virtualized DomU runn VMWare inside it, as soon as I
get a few cycles.
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.
|
