Re: Xen vs VMware
wa1ter wrote @ Sat, 21 Oct 2006 10:25:31 -0700: Andreas Hauser wrote: dillon wrote @ Wed, 18 Oct 2006 11:34:02 -0700 (PDT): Xen is an operating environment. Operating systems running under Xen have to be aware that they are running under Xen. Unless you use a current processor (Intel or Amd e.g.) which come with hardware virtualization... Can you point out which processors have this hardware -- are they the 64-bit models only? My instincts tell me that the 64-bit hardware could virtualize a 32-bit machine -- but that's a pure guess on my part. No, it has nothing to do with 32-bit or 64-bit. Amd calls it Pacifica and Intel Vanderpool or VT. Newer Athlon 64 (AM2), Opteron, Core 2, All Intel from Apple etc. have it. AFAIR the non Apple mobile Core don't have it. -- Andy
Re: Xen vs VMware
: Can you point out which processors have this hardware -- are they the : 64-bit models only? My instincts tell me that the 64-bit hardware : could virtualize a 32-bit machine -- but that's a pure guess on my part. : :No, it has nothing to do with 32-bit or 64-bit. :Amd calls it Pacifica and Intel Vanderpool or VT. :Newer Athlon 64 (AM2), Opteron, Core 2, All Intel from Apple etc. have it. :AFAIR the non Apple mobile Core don't have it. : :-- :Andy There's nothing really special about any of it. It's just a way for the processor to run in ring 0 (kernel mode) but still have restricted, trappable access to hardware resources. That's it. My personal opinion is that its a hack on top of a hack. As much as it may seem like a nice idea to be able to run an operating system this way, I think it's an even better idea to spend the effort to retool the operating system to a more restrictive spec that does not require hardware virtualization technology to run, which is what I am doing. But I expect momentum will continue to build for the hardware virtualization method of doing things because OS vendors traditionally have not cooperated on creating a common hardware abstraction layer. The only thing about the new virtualization technology that really interests me is that the MMU will operate natively under it... that is, there will be no need to emulate the MMU. That is the *ONLY* part of the whole mess that can actually lead to significant improvements in performance in a hardware virtualized environment over a software virtualized environment. -Matt Matthew Dillon [EMAIL PROTECTED]
Re: Xen vs VMware
On Sun, October 22, 2006 9:41 am, Andreas Hauser wrote: wa1ter wrote @ Sat, 21 Oct 2006 10:25:31 -0700: Andreas Hauser wrote: dillon wrote @ Wed, 18 Oct 2006 11:34:02 -0700 (PDT): Unless you use a current processor (Intel or Amd e.g.) which come with hardware virtualization... Can you point out which processors have this hardware -- are they the 64-bit models only? My instincts tell me that the 64-bit hardware could virtualize a 32-bit machine -- but that's a pure guess on my part. No, it has nothing to do with 32-bit or 64-bit. Amd calls it Pacifica and Intel Vanderpool or VT. Newer Athlon 64 (AM2), Opteron, Core 2, All Intel from Apple etc. have it. AFAIR the non Apple mobile Core don't have it. The codenames for the hardware virtualisation projects are Pacifica for AMD and Vanderpool for Intel. The official release names are AMD-V and Intel-VT. From research I've been doing online, it seems that (again) the AMD implementation is much better, virtualising a lot more of the CPU and providing better support for virtual I/O. The Xen wiki has a nice list of CPU model numbers that have AMD-V and Intel-VT support: http://wiki.xensource.com/xenwiki/HVM_Compatible_Processors Freddie Cash, LPIC-2 CCNT CCLPHelpdesk / Network Support Tech. School District 73(250) 377-HELP [377-4357] [EMAIL PROTECTED]
Re: Xen vs VMware
dillon wrote @ Wed, 18 Oct 2006 11:34:02 -0700 (PDT): Xen is an operating environment. Operating systems running under Xen have to be aware that they are running under Xen. Unless you use a current processor (Intel or Amd e.g.) which come with hardware virtualization. There are only a handful of x86 hardware instructions that can't be virtualized without special hardware (like current processors have). It is currently no problem to run DragonFly under Xen on such systems. Xen actually has to run two operating systems, one serving as the master and the other as the 'guest' OS, and this compounds the number of potential bugs you might run into a lot more then a machine emulator does. The opposite is true. Xen is much simpler. It's also way more powerful and faster. Note that vmware also has Xen like offerings. It is also very easy for admins to convince their site to run DragonFly as one or more Xen domains with a less experimental OS as controlling Domain and be able to run any number of other OS. While the current DragonFly approach is restricted to DragonFly and needs a dedicated machine. And when presented the choice between Usermode DragonFly and jails I will often prefer jails anyways, as they take less effort to admin. But I'm sure the effort will help advance the kernel though. Happy Hacking! -- Andy
Re: Xen vs VMware
Andreas Hauser wrote: dillon wrote @ Wed, 18 Oct 2006 11:34:02 -0700 (PDT): Xen is an operating environment. Operating systems running under Xen have to be aware that they are running under Xen. Unless you use a current processor (Intel or Amd e.g.) which come with hardware virtualization... Can you point out which processors have this hardware -- are they the 64-bit models only? My instincts tell me that the 64-bit hardware could virtualize a 32-bit machine -- but that's a pure guess on my part.
Re: Xen vs VMware
On Sat, 21 Oct 2006, walt wrote: Andreas Hauser wrote: Unless you use a current processor (Intel or Amd e.g.) which come with hardware virtualization... Can you point out which processors have this hardware -- are they the 64-bit models only? My instincts tell me that the 64-bit hardware could virtualize a 32-bit machine -- but that's a pure guess on my part. Since people recently asked on NetBSD's port-xen list: (I don't think it has anything to do with 64 vs 32 bit, by the way.) MAgnus -- Forwarded message -- Date: Fri, 20 Oct 2006 18:21:19 +0200 From: Manuel Bouyer [EMAIL PROTECTED] To: Steven M. Bellovin [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: upgraded to 3.0.3, with hvm support On Fri, Oct 20, 2006 at 12:09:55PM -0400, Steven M. Bellovin wrote: I'm now persuaded that I need to update my desktop machine to one that supports HVM... (Is there any way to tell from vendor literature if the CPU has the right features?) For Intel it's http://indigo.intel.com/compare_cpu/default.aspx?familyID=1culture=en-US What you're looking for is VT -- Manuel Bouyer, LIP6, Universite Paris VI. [EMAIL PROTECTED] NetBSD: 26 ans d'experience feront toujours la difference -- -- Forwarded message -- Date: Fri, 20 Oct 2006 19:17:36 +0200 From: Christian Biere [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: upgraded to 3.0.3, with hvm support [...] What you're looking for is VT Though the AMD stuff virtualizes a bit more, and performance is supposed to be somewhat better, right? Which AMD CPUs have virtualization? I am having some trouble figuring out. Recent models of the Athlon 64, Opteron and Turion. They used to call it Pacifica but call it AMD-V now. I think AMD has a marketing issue. Xen apparently supports AMD Pacifica since 3.0.2. -- Christian
Re: Xen vs VMware
On Sat, Oct 21, 2006 at 06:38:06PM +0200, Andreas Hauser wrote: dillon wrote @ Wed, 18 Oct 2006 11:34:02 -0700 (PDT): Xen is an operating environment. Operating systems running under Xen have to be aware that they are running under Xen. Unless you use a current processor (Intel or Amd e.g.) which come with hardware virtualization. There are only a handful of x86 hardware instructions that can't be virtualized without special hardware (like current processors have). It is currently no problem to run DragonFly under Xen on such systems. It is still quite expensive and defeats the purpose of using Xen (compared to using VMware). E.g. you still have to emulate devices and have to do a lot more of copying etc. Joerg
Re: Xen vs VMware
On Sat, 21 Oct 2006, Joerg Sonnenberger wrote: On Sat, Oct 21, 2006 at 06:38:06PM +0200, Andreas Hauser wrote: dillon wrote @ Wed, 18 Oct 2006 11:34:02 -0700 (PDT): Operating systems running under Xen have to be aware that they are running under Xen. Unless you use a current processor (Intel or Amd e.g.) which come with hardware virtualization. It is still quite expensive and defeats the purpose of using Xen (compared to using VMware). E.g. you still have to emulate devices and have to do a lot more of copying etc. But when your operating system of choice takes the step into the 00's *cough* *cough* *nudge* that added expense disappears. :-) And of course, if you are using NetBSD (or Linux), it's nice to be able to have DF (or any other OS..) running under Xen. Even if there were other virtualization options available, why bother when one tool can do it all? One of these days I'm even going to start using it. MAgnus
Xen vs VMware
1) What is the difference beetwen Xen and VMware? 2) What is the better choice: Xen or VMware? 3) Why does it exist a project of porting for Xen on DragonFly, and why it doesn't exist the same project for VMware? __ Do You Yahoo!? Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi http://mail.yahoo.it
Re: Xen vs VMware
:1) What is the difference beetwen Xen and VMware? :2) What is the better choice: Xen or VMware? :3) Why does it exist a project of porting for Xen on :DragonFly, and why it doesn't exist the same project :for VMware? VMWare is a machine emulator. Operating systems running under VMWare think they are running on the actual hardware (generally speaking). Xen is an operating environment. Operating systems running under Xen have to be aware that they are running under Xen. Generally speaking I prefer the VMWare concept over the Xen concept. Xen actually has to run two operating systems, one serving as the master and the other as the 'guest' OS, and this compounds the number of potential bugs you might run into a lot more then a machine emulator does. -Matt Matthew Dillon [EMAIL PROTECTED]
Re: Xen vs VMware
On Wed, Oct 18, 2006 at 08:18:59PM +0200, Saverio Iacovelli wrote: 1) What is the difference beetwen Xen and VMware? Xen is a small kernel which provides an interface for specially modified kernels to issue privileged instructions. Means that instead of modifying e.g. the page table directly, the kernel instructs Xen to do so. It also provides modified interfaces to provide efficient inter-domain network traffic etc. VMware emulates a full PC with all hardware, by dynamically modifying the OS and/or trapping when necessary. 2) What is the better choice: Xen or VMware? Xen if it is available. Less overhead both in terms of memory and CPU usage. With Pacificia or VT the difference blurs though for unmodified kernels. 3) Why does it exist a project of porting for Xen on DragonFly, and why it doesn't exist the same project for VMware? See (1) Joerg
Re: Xen vs VMware
On 10/18/06, Matthew Dillon [EMAIL PROTECTED] wrote: Generally speaking I prefer the VMWare concept over the Xen concept. Xen actually has to run two operating systems, one serving as the master and the other as the 'guest' OS, and this compounds the number of potential bugs you might run into a lot more then a machine emulator does. I'm surprised by this. Xen (abstracting out some sort of meta operating system) seems a cleaner and simplier solution to me than running a complex software copy of real hardware. Anyway aren't we just talking about lines of C in both cases? I suspect the number of bugs in either would just be a function of the total lines of C. Xen is relatively small. Although vmware source, isn't available AFAIK would anyone care to estimate lines of source for it?
Re: Xen vs VMware
On 10/18/06, Matthew Dillon [EMAIL PROTECTED] wrote: Generally speaking I prefer the VMWare concept over the Xen concept. Xen actually has to run two operating systems, one serving as the master and the other as the 'guest' OS, and this compounds the number of potential bugs you might run into a lot more then a machine emulator does. The master and guest relationship exists inside the VMWare model as well. I don't see how Xen is any more or less bug prone. They are just two approaches at acheiving the exact same goal. And with the new VT hardware, guest operating systems no longer need to be Xen aware or ported. As an aside has anyone tried using DragonFly under Xen with the VT enabled hardware? -Kevink -- Kevin L. Kane kevin.kane at gmail.com
Re: Xen vs VMware
:On 10/18/06, Matthew Dillon [EMAIL PROTECTED] wrote: : : Generally speaking I prefer the VMWare concept over the Xen concept. : Xen actually has to run two operating systems, one serving as the : master and the other as the 'guest' OS, and this compounds the : number of potential bugs you might run into a lot more then a machine : emulator does. : :The master and guest relationship exists inside the VMWare model as :well. I don't see how Xen is any more or less bug prone. They are :just two approaches at acheiving the exact same goal. And with the :new VT hardware, guest operating systems no longer need to be Xen :aware or ported. : :As an aside has anyone tried using DragonFly under Xen with the VT :enabled hardware? : :-Kevink : :-- :Kevin L. Kane :kevin.kane at gmail.com Yes, that's very true. I suppose the approach I favor the most is the one I am taking with the DragonFly virtualization work... that is, running the virtualized kernel as a standard user process linked against libc, with only very minimal support required from the 'real' kernel to allow the virtual kernel to manage the VM contexts for its own 'user' processes. That way you don't actually have to learn to admin two different operating systems. -Matt Matthew Dillon [EMAIL PROTECTED]
Re: Xen vs VMware
:Possibly offtopic for this thread, but: : :Will the approach your taking with DragonFly allow for quickly and :easily migrating the virtualized kernels between machines? : :Also, what about the possibility of running your userland kernels :under other operating systems? One of the advantages that Xen and :VMWare has is that you CAN run multiple operating systems when you are :forced to. : :-Kevink I think its possible, but those other operating systems would still have to implement the virtualization system calls and mmap support. It isn't possible to run a kernel as a userland process without them because the kernel would not be able to manage the VM spaces for its own 'user' processes (from the point of view of the virtual kernel). It would be possible to make this into a defacto standard. The actual work involved isn't all that great... the hard part is switching between VM spaces and managing the execution contexts... which is the part I'm working on now. * Implement specialized mmap() operations that allow manipulation of managed VM spaces instead of the calling process's VM space. DONE. * Implement switching to the calling process's VM space (in order to run a managed VM space), then switching back if a signal ocurs or the managed VM space takes a page-fault, trap, or makes a system call. NOT DONE. * Implement a build for the virtualized kernel itself that links into a standard user program binary, plus drivers that emulate network, disk, and other resources. NOT DONE. -Matt
Re: Xen vs VMware
Possibly offtopic for this thread, but: Will the approach your taking with DragonFly allow for quickly and easily migrating the virtualized kernels between machines? Also, what about the possibility of running your userland kernels under other operating systems? One of the advantages that Xen and VMWare has is that you CAN run multiple operating systems when you are forced to. -Kevink On 10/18/06, Matthew Dillon [EMAIL PROTECTED] wrote: :On 10/18/06, Matthew Dillon [EMAIL PROTECTED] wrote: : : Generally speaking I prefer the VMWare concept over the Xen concept. : Xen actually has to run two operating systems, one serving as the : master and the other as the 'guest' OS, and this compounds the : number of potential bugs you might run into a lot more then a machine : emulator does. : :The master and guest relationship exists inside the VMWare model as :well. I don't see how Xen is any more or less bug prone. They are :just two approaches at acheiving the exact same goal. And with the :new VT hardware, guest operating systems no longer need to be Xen :aware or ported. : :As an aside has anyone tried using DragonFly under Xen with the VT :enabled hardware? : :-Kevink : :-- :Kevin L. Kane :kevin.kane at gmail.com Yes, that's very true. I suppose the approach I favor the most is the one I am taking with the DragonFly virtualization work... that is, running the virtualized kernel as a standard user process linked against libc, with only very minimal support required from the 'real' kernel to allow the virtual kernel to manage the VM contexts for its own 'user' processes. That way you don't actually have to learn to admin two different operating systems. -Matt Matthew Dillon [EMAIL PROTECTED] -- Kevin L. Kane kevin.kane at gmail.com
Re: Xen vs VMware
On Wednesday 18 October 2006 12:42 pm, Steve Mynott wrote: On 10/18/06, Matthew Dillon [EMAIL PROTECTED] wrote: Generally speaking I prefer the VMWare concept over the Xen concept. Xen actually has to run two operating systems, one serving as the master and the other as the 'guest' OS, and this compounds the number of potential bugs you might run into a lot more then a machine emulator does. I'm surprised by this. Xen (abstracting out some sort of meta operating system) seems a cleaner and simplier solution to me than running a complex software copy of real hardware. Anyway aren't we just talking about lines of C in both cases? I suspect the number of bugs in either would just be a function of the total lines of C. Xen is relatively small. Although vmware source, isn't available AFAIK would anyone care to estimate lines of source for it? Xen itself is small. However, every OS that you want to run on top of Xen needs to be made Xen-aware, with a custom kernel that uses Xen features. For that reason, you can really only run open-source OSes on top of Xen right now. You also lose the ability to query the hardware (lspci/pciconf for instance return empty statements on Xen) from within the guest OS. VMWare emulates a full PC, with a BIOS and everything. You can run any OS on top of VMWare, without changing the OS in any way. Everything runs the same as if it were installed on real hardware. You can even query the virtual hardware using things like pciconf/lspci. With the new CPUs from Intel/AMD that include hardware virtualisation features, it is theoretically possible to run any OS on top of Xen 3.0+, but I have not heard of anyone successfully doing that as yet (not that I've searched all that hard). Xen's para-virtualisation method is said to be a lot faster than VMWare full virtualisation method. With support for hardware virtualisation features in newer CPUs, VMWare's latest products are supposedly almost as fast as Xen. And they've started using a few para-virtualisation tricks as well to speed things up. Basically, it boils down to whether you want a virtual OS or a virtual PC. Xen is the former, VMWare is the latter. -- Freddie Cash, LPIC-2 CCNT CCLP Helpdesk / Network Support Tech. School District 73 (250) 377-HELP [377-4357] [EMAIL PROTECTED][EMAIL PROTECTED] -- Freddie Cash, LPIC-2 CCNT CCLP Network Support Technician School District 73 (250) 377-HELP [377-4357] [EMAIL PROTECTED]
Re: Xen vs VMware
Steve Mynott wrote: On 10/18/06, Matthew Dillon [EMAIL PROTECTED] wrote: Generally speaking I prefer the VMWare concept over the Xen concept. Xen actually has to run two operating systems, one serving as the master and the other as the 'guest' OS, and this compounds the number of potential bugs you might run into a lot more then a machine emulator does. I'm surprised by this. Xen (abstracting out some sort of meta operating system) seems a cleaner and simplier solution to me than running a complex software copy of real hardware. Anyway aren't we just talking about lines of C in both cases? I suspect the number of bugs in either would just be a function of the total lines of C. Xen is relatively small. Although vmware source, isn't available AFAIK would anyone care to estimate lines of source for it? Given that it is a commercial product? Aren't such coders paid by printout-weight? ;-) More seriously - look at the sizes of the binaries. The compiler has (hopefuly) sweated the worst of the diffrences out by then, else it would be far slower than it is..) VmWare not only has to emulate an entire machine, it has to also 'virtualize' the peripheral I/O fs - and therein lies a bit of a mystery. I've had my hands on a lot of these sort of products over the years, and one of the more curious experiences came out of the Connectix/InnoTek (Now Microsoft) 'Virtual PC' - from Intel/AMD O- used on OS/2 Windows thru OSX G4 versions. Whether 'benchmarks' or day to day, experience will vary all over the lot, but over time the curiosity was that a 'typical' VPC-emulating-Intel on-Intel with FAT fs seemed to run about 40 to 50% of the speed of the underlying hardware. Actually quite decent if one had a 1 or 2 GHz platform and had become accustomed to a 400-500 Mhz one anyway. The curiosity was that VPC-emulating-intel on-PPC-G4 wiht hfs(+) was much faster! Approximately 700 MHz Intel performance on a mere 1 GHz G4. And I don't kid myself that OSX is anywhere near as efficient as OS/2 (or necessarily even a 'stripped for combat' industrialized-version of NT - see LitePC). So - some of these are well-debugged and refined products. Matt's viewpoint and mine do differ, though. I'd like to see a 'DragonXen' to use for 'mothership' of baby Dragons, and Beasties in general. Something more akin to big-iron VM/MV - 'in between' having to emulate *everything* and bare-bones 'meet me half way or go panic yerself' Xen. AIX-5L-like, perhaps..? If/as/when I am ever moved to an Intel-ized Mac (d'ruther have polio..), 'Parallels' is on my 'must try' list. But to run *BSD guests and legacy OS/2, not WinWoes! What with dualcore and more we are on the brink of a whole new set of major changes. 83 year old mum just told me of a schoolmate of hers, gone deaf, who is now reliant on a real-time speaker-independent speech-to-text telephone with screen. Yesterday's lab gear is today's appliance Bill Bill
