Good read on OS X Server virtualization and discontinuation of the X-Serve from University of Wisconsin-Madison's Dave Schroeder:
http://appleopenletter.org/ ./s ------------------------------------------------------------------------- The following was automatically added to this message by the list server: To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site: http://micronet.berkeley.edu Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet. This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past. |
On 11/9/2010 8:55 PM, Scot Hacker wrote:
> Good read on OS X Server virtualization and discontinuation of the > X-Serve from University of Wisconsin-Madison's Dave Schroeder: > > http://appleopenletter.org/ Very interesting and full of good points. I'd be willing to bet US$.05 that Mac OS X 10.7 will legally and technically run on some virtual machine products. One of the reasons I've always heard for why Apple doesn't want to run on non-Apple hardware is the burden of making sure everything works on all the hardware variations. If they ran in a virtual machine this problem would go away since all they'd have to do would be to make sure that Mac OS works in the virtualized environment. It would be up to the VM software vendor to make sure the VM works properly on the physical hardware. The big question is which VM vendor(s) Apple would choose to officially support, and whether they'd do anything to legally and/or technically prevent Mac OS from running on the others. Cordially, -- Jon Forrest Research Computing Support College of Chemistry 173 Tan Hall University of California Berkeley Berkeley, CA 94720-1460 510-643-1032 [hidden email] ------------------------------------------------------------------------- The following was automatically added to this message by the list server: To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site: http://micronet.berkeley.edu Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet. This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past. |
VMWare's Fusion lists 10.6 Server as an (Experimental) guest OS. Of
course running an Apple server on an Apple desktop is not much value at the enterprise level. It needs to run on ESXi /vSphere type environments to be really flexible. Graham On 11/10/10 9:01 AM, Jon Forrest wrote: > On 11/9/2010 8:55 PM, Scot Hacker wrote: >> Good read on OS X Server virtualization and discontinuation of the >> X-Serve from University of Wisconsin-Madison's Dave Schroeder: >> >> http://appleopenletter.org/ > > Very interesting and full of good points. > I'd be willing to bet US$.05 that > Mac OS X 10.7 will legally and technically > run on some virtual machine products. > > One of the reasons I've always heard for why > Apple doesn't want to run on non-Apple hardware > is the burden of making sure everything > works on all the hardware variations. If they > ran in a virtual machine this problem would > go away since all they'd have to do > would be to make sure that Mac OS works > in the virtualized environment. It would be > up to the VM software vendor to make sure > the VM works properly on the physical hardware. > > The big question is which VM vendor(s) Apple > would choose to officially support, and whether > they'd do anything to legally and/or technically > prevent Mac OS from running on the others. > > Cordially, -- Graham Patterson, Systems Administrator Lawrence Hall of Science, UC Berkeley 510-643-2222 "...past the Tyranosaurus, the Mastodon, the mathematical puzzles, and the meteorite..." - directions to my office. ------------------------------------------------------------------------- The following was automatically added to this message by the list server: To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site: http://micronet.berkeley.edu Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet. This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past. |
In reply to this post by Jon Forrest
On Wed, Nov 10, 2010 at 09:01:10AM -0800, Jon Forrest wrote:
> One of the reasons I've always heard for why > Apple doesn't want to run on non-Apple hardware > is the burden of making sure everything > works on all the hardware variations. If they > ran in a virtual machine this problem would > go away since all they'd have to do > would be to make sure that Mac OS works > in the virtualized environment. It would be > up to the VM software vendor to make sure > the VM works properly on the physical hardware. Are you confusing java style virtual machines with virtualized x86 environments? What x86 virtualization solutions completely abstract the underlying hardware vs. acting as a hypervisor? Erik ------------------------------------------------------------------------- The following was automatically added to this message by the list server: To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site: http://micronet.berkeley.edu Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet. This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past. |
On 11/10/2010 9:40 AM, Erik Klavon wrote:
> Are you confusing java style virtual machines with virtualized x86 > environments? What x86 virtualization solutions completely abstract > the underlying hardware vs. acting as a hypervisor? Any of them that provide virtualized resources such as virtual disks, network adapters, etc. VirtualBox and VMWare Server are two such examples. For what it's worth, these are the so-called "Type 2" hypervisors mentioned in the Wikipedia page about hypervisors (http://en.wikipedia.org/wiki/Hypervisor). Jon ------------------------------------------------------------------------- The following was automatically added to this message by the list server: To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site: http://micronet.berkeley.edu Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet. This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past. |
On Wed, Nov 10, 2010 at 10:09:07AM -0800, Jon Forrest wrote:
> On 11/10/2010 9:40 AM, Erik Klavon wrote: > >Are you confusing java style virtual machines with virtualized x86 > >environments? What x86 virtualization solutions completely abstract > >the underlying hardware vs. acting as a hypervisor? > > Any of them that provide virtualized resources such > as virtual disks, network adapters, etc. VirtualBox > and VMWare Server are two such examples. For what > it's worth, these are the so-called "Type 2" hypervisors > mentioned in the Wikipedia page about hypervisors > (http://en.wikipedia.org/wiki/Hypervisor). Are differences in the underlying CPU architecture exposed to the VMs when using VirtualBox? I know this can be the case with VMware. Differences in the underlying hardware will likely creep into the virtual environment for efficiency reasons, and to allow operators to take advantage of new features. Software vendors will continue to need to ensure that their software will run on the sundry processor architectures supported by a given hypervisor. Or they will need to specify that their software will run on a specific subset of architectures. I don't think one can really say at this point in time that hypervisors like VMware make the problems of hardware differences go away. They may decrease them, but at present they do not eliminate them. This was and is the promise of the java approach to virtualization. Erik ------------------------------------------------------------------------- The following was automatically added to this message by the list server: To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site: http://micronet.berkeley.edu Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet. This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past. |
On 11/11/2010 3:08 PM, Erik Klavon wrote:
> Are differences in the underlying CPU architecture exposed to the VMs > when using VirtualBox? It depends on what you mean by 'underlying CPU architecture'. There are some options you can select when configuring a virtual machine, such as APIC, PAE/NX, VT-x/AMD-V, and nested paging, but some of these aren't really CPU architecture features. I'd consider them system features, which can include BIOS, and other device features. To tell you the truth, I can't say much about the VMWare bare hardware hypervisors because I haven't used them. However, I've been able to figure out how to use VirtualBox to configure an HPC cluster in a box. This is a Beowulf cluster with as many virtual compute nodes as hardware resources allow, all contained in one physical box running VirtualBox. > I know this can be the case with > VMware. Differences in the underlying hardware will likely creep into > the virtual environment for efficiency reasons, and to allow operators > to take advantage of new features. I'd be surprised if this were to happen in the Type 2 hypervisors I mentioned. The whole point of them is that they provide virtual devices that emulate real devices that are supported in the guest OS. > Software vendors will continue to > need to ensure that their software will run on the sundry processor > architectures supported by a given hypervisor. Or they will need to > specify that their software will run on a specific subset of > architectures. This goes against what I've always believed is true about virtualization. The hypervisor provides a hardware abstraction that remains constant no matter what physical hardware is used. > I don't think one can really say at this point in time that > hypervisors like VMware make the problems of hardware differences go > away. They may decrease them, but at present they do not eliminate > them. This was and is the promise of the java approach to > virtualization. The Java approach was entirely different. In that case what's being virtualized is a machine hardware instruction set. VM software provides a virtualized computer, but one that runs the same hardware instructions as the guest operating system. When running guest user mode code, a VM hypervisor has almost no work to do because there is nothing that has to be trapped by the VM. Some people confuse emulators with VM software. As far as I know, none of the mainstream VM software lets you run guest OSs that use a different instruction set than what's on the physical hardware. The difference between 64-bit and 32-bit x86 doesn't count because the physical hardware supports both. Jon ------------------------------------------------------------------------- The following was automatically added to this message by the list server: To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site: http://micronet.berkeley.edu Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet. This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past. |
On Thu, Nov 11, 2010 at 04:39:52PM -0800, Jon Forrest wrote:
> On 11/11/2010 3:08 PM, Erik Klavon wrote: > > >Are differences in the underlying CPU architecture exposed to the VMs > >when using VirtualBox? > > It depends on what you mean by 'underlying CPU > architecture'. There are some options > you can select when configuring a virtual > machine, such as APIC, PAE/NX, VT-x/AMD-V, > and nested paging, but some of these aren't really > CPU architecture features. I'd consider them > system features, which can include BIOS, > and other device features. For the moment, I'll focus on differences in CPU instruction sets and in the implementation of the instructions themselves. > To tell you the truth, I can't say much about > the VMWare bare hardware hypervisors because > I haven't used them. However, I've been able > to figure out how to use VirtualBox to configure > an HPC cluster in a box. This is a Beowulf cluster > with as many virtual compute nodes as hardware resources > allow, all contained in one physical box running > VirtualBox. > > >I know this can be the case with > >VMware. Differences in the underlying hardware will likely creep into > >the virtual environment for efficiency reasons, and to allow operators > >to take advantage of new features. > > I'd be surprised if this were to happen in the Type 2 > hypervisors I mentioned. The whole point of them > is that they provide virtual devices that emulate > real devices that are supported in the guest OS. This issue really becomes apparent when you consider what is required to move a running VM from one physical host to another. If as you state there is no difference at all in the virtual environment presented by the two hosts, then you should be able to do this across different CPU architectures. > >Software vendors will continue to > >need to ensure that their software will run on the sundry processor > >architectures supported by a given hypervisor. Or they will need to > >specify that their software will run on a specific subset of > >architectures. > > This goes against what I've always believed is > true about virtualization. The hypervisor provides > a hardware abstraction that remains constant no matter > what physical hardware is used. Check out these documents. The VMware PDF goes into more detail on the problems that differences in CPU architecture create when you want to move a running VM from one host to another. The sun webpage lists as one of VirtualBox's prerequisits for doing this "farily similar CPUs". http://www.vmware.com/files/pdf/vmotion_info_guide.pdf http://blogs.sun.com/vreality/entry/teleporting If the hypervisor provided a hardware abstraction that remains constant no matter what physical hardware is used, you'd have no trouble moving a running VM from any one CPU architecture to any other. That that you cannot do this in general implies that the hardware abstraction does not remain constant with every change to the underlying hardware. > >I don't think one can really say at this point in time that > >hypervisors like VMware make the problems of hardware differences go > >away. They may decrease them, but at present they do not eliminate > >them. This was and is the promise of the java approach to > >virtualization. > > The Java approach was entirely different. In that case what's > being virtualized is a machine hardware instruction set. VM software > provides a virtualized computer, but one that runs the > same hardware instructions as the guest operating system. > When running guest user mode code, a VM hypervisor has > almost no work to do because there is nothing that has to be > trapped by the VM. This is the source of the rub I'm getting at. Since you're running on the bare hardware for non privileged instructions, what instructions you have available to you is dependent on what the CPU provides. Different CPUs can have different instruction sets, and can implement the same instruction differently. Since the underlying instruction set is exposed to the software, the writer of the software needs to pay attention to differences in CPU instruction sets. Therefore, you can't say that all of the problems of running software on different hardware go away when that software runs in a virtual environment, such as those provided by VMware or VirtualBox. Erik ------------------------------------------------------------------------- The following was automatically added to this message by the list server: To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site: http://micronet.berkeley.edu Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet. This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past. |
On 11/11/2010 7:35 PM, Erik Klavon wrote:
> For the moment, I'll focus on differences in CPU instruction sets and > in the implementation of the instructions themselves. The implementation of the instructions shouldn't matter. After all, it doesn't matter if you run Linux or Windows on an Intel, AMD, or other x86 compatible processor. All have different instruction implementations. Even one vendor will have different instruction implementations in their various processors. > This issue really becomes apparent when you consider what is required > to move a running VM from one physical host to another. If as you > state there is no difference at all in the virtual environment > presented by the two hosts, then you should be able to do this across > different CPU architectures. I think the VMs would work, but there would be a chance that some usermode instructions wouldn't work. For example, there are a number of instruction set extensions, such as the SSE* family. If you have a program that uses, say SSE4, the program won't work on hardware that doesn't support SSE4 since a VM doesn't generally do emulation (see below). > Check out these documents. The VMware PDF goes into more detail on the > problems that differences in CPU architecture create when you want to > move a running VM from one host to another. The sun webpage lists as > one of VirtualBox's prerequisits for doing this "farily similar > CPUs". > > http://www.vmware.com/files/pdf/vmotion_info_guide.pdf > > http://blogs.sun.com/vreality/entry/teleporting I wrote my first two paragraphs above before I read these references. The VMWare paper just repeats what I was saying above. The second reference says "The hosts must have fairly similar CPUs. Teleporting between Intel and AMD CPUs will probably fail with an error message." This isn't specific enough. "Fairly similar" and "will probably fail" need to be more specific. I bet that what he means is what's covered in the VMWare paper. > If the hypervisor provided a hardware abstraction that remains > constant no matter what physical hardware is used, you'd have no > trouble moving a running VM from any one CPU architecture to > any other. That that you cannot do this in general implies that the > hardware abstraction does not remain constant with every change to the > underlying hardware. I don't think we've established that you can't do this in general. Looking at page 9 in the VMWare document, the majority of the issues involve instruction set extensions. As far as I know Linux doesn't use these instructions, nor does it use the RDTSCP instruction (please correct me if I'm wrong). So, this means that any VM running Linux and usermode code that doesn't use the extensions can be migrated. I suspect, but can't prove, that this is the fast majority of VMs. By the way, I'd also love to be proven wrong about my general conclusion. If anybody has unsuccessfully tried to migrate VMs I'd like to know the cause of the failure. Maybe someone from the Data Center has some examples. > This is the source of the rub I'm getting at. Since you're running on > the bare hardware for non privileged instructions, what instructions > you have available to you is dependent on what the CPU > provides. Different CPUs can have different instruction sets, and can > implement the same instruction differently. Since the underlying > instruction set is exposed to the software, the writer of the software > needs to pay attention to differences in CPU instruction > sets. Therefore, you can't say that all of the problems of running > software on different hardware go away when that software runs in a > virtual environment, such as those provided by VMware or VirtualBox. I think this depends on how the VM software works. Some VM software does a prescan of the instructions to be executed, and if it finds an instruction that would cause trouble, it patches the binary so that instead of that instruction getting executed, routines in the VM software emulate the instruction. This is why I said VM software generally doesn't do emulation. It might, but only in special cases. Or, the instruction could be executed, which would cause a trap that can be handled by the VM software. Both these methods have runtime penalties. I remember when the x86 architecture came out it was said that it couldn't be virtualized. So, many people were very skeptical when Mendel Rosenblum claimed it could, and then proved it. Now that Intel/AMD are actively promoting virtualization, I suspect that these instruction set incompatibilities will become less and less an issue. Jon ------------------------------------------------------------------------- The following was automatically added to this message by the list server: To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site: http://micronet.berkeley.edu Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet. This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past. |
On 11/12/10 17:43, Jon Forrest wrote:
[snip] > I wrote my first two paragraphs above before I read these > references. The VMWare paper just repeats what I was saying > above. > > The second reference says "The hosts must have fairly > similar CPUs. Teleporting between Intel and AMD CPUs > will probably fail with an error message." This isn't > specific enough. "Fairly similar" and "will probably fail" > need to be more specific. I bet that what he means is what's > covered in the VMWare paper. > >> If the hypervisor provided a hardware abstraction that remains >> constant no matter what physical hardware is used, you'd have no >> trouble moving a running VM from any one CPU architecture to >> any other. That that you cannot do this in general implies that the >> hardware abstraction does not remain constant with every change to the >> underlying hardware. > > I don't think we've established that you can't do this > in general. Looking at page 9 in the VMWare document, > the majority of the issues involve instruction set > extensions. As far as I know Linux doesn't > use these instructions, nor does it use the RDTSCP > instruction (please correct me if I'm wrong). So, > this means that any VM running Linux and usermode code > that doesn't use the extensions can be migrated. I suspect, > but can't prove, that this is the fast majority of VMs. > > By the way, I'd also love to be proven wrong about > my general conclusion. If anybody has unsuccessfully > tried to migrate VMs I'd like to know the cause > of the failure. Maybe someone from the Data Center > has some examples. We do have experiences with this on campus. Typically, a system that is migrated from one sub-architecture to another will immediately become very unstable. Often it will crash quickly, which is better than staying up with instabilities and potential memory corruptions. Rebooting the system, where the OS kernel has a chance to detect the sub-architecture's features, will generally solve the problem. I suspect that the reason that the VMware documents are vague about this is that it is impossible to know which sub-architecture features a given OS and/or application are actively using, so one can't know a priori exactly what will go wrong. It may someday (maybe even today) be possible to configure an OS kernel not to take advantage of sub-architecture-unique features, but it is unlikely that we will ever get all applications to play along. Virtualization is great, but it's not magic, and here is one case in point. michael ------------------------------------------------------------------------- The following was automatically added to this message by the list server: To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site: http://micronet.berkeley.edu Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet. This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past. |
On 11/13/2010 2:28 PM, Michael Sinatra wrote:
> We do have experiences with this on campus. Typically, a system that is > migrated from one sub-architecture to another will immediately become > very unstable. Can you be more specific about what the source and destination sub-architectures are that don't work? > Often it will crash quickly, which is better than staying > up with instabilities and potential memory corruptions. Rebooting the > system, where the OS kernel has a chance to detect the > sub-architecture's features, will generally solve the problem. Other structural changes to the destination VM, like allocating a different amount of RAM, result in the same thing. When you see these instabilities are you 100% sure the source VM and the destination are configured the same? I wonder whether the problems you mention are caused by instruction set differences or other non instruction set differences? I also wonder whether VMWare would consider what you're seeing a bug. > I suspect that the reason that the VMware documents are vague about this is that > it is impossible to know which sub-architecture features a given OS > and/or application are actively using, so one can't know a priori > exactly what will go wrong. I think it would possible for VMWare to say that, for example, a standard CentOS 5.5 kernel is movable since it would be easy to know whether it uses any of the troublesome instructions. It might also be possible while moving the source VM to the destination to scan the text section of all processes the same way. There would be two problems with this, though. 1) It wouldn't detect problems in programs that aren't being run, and 2) it wouldn't detect any non instruction set differences. I wonder if these would be possible to detect so that you could know when you do the migration whether the newly created VM will work. > Virtualization is great, but it's not magic, and here is one case in point. True, but it's getting better and better. Plus, now that the CPU vendors are in favor of it, they're willing to add hardware to make it faster and better. One thing that I'm not aware that can be done with any of the x86 virtualization products is being able to run a hypervisor on top of a hypervisor. This was possible with IBM's VM/370. In fact, if I remember correctly, there was no limit on how deep you could stack VMs, other than hardware resources. Jon ------------------------------------------------------------------------- The following was automatically added to this message by the list server: To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site: http://micronet.berkeley.edu Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet. This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past. |
On 11/13/2010 5:47 PM, Jon Forrest wrote:
> > We do have experiences with this on campus. Typically, a system that > > is migrated from one sub-architecture to another will immediately > > become very unstable. > > Can you be more specific about what the > source and destination sub-architectures are that don't work? Moving Linux VMs (specifically RHEL 5) between blades with Intel 5160 ("Woodcrest") and Intel 5345 ("Clovertown") processors has resulted in a consistent state of 100% CPU usage by the guest virtual machine until a cold shutdown boot is performed. This seems to be limited to a subset of Linux VMs, but is reproducible across guests with differing functions (app, web servers), and very problematic since we, until recently, had blades within our clusters that contained these differing chipsets. Now, and in the future, the ESXi clusters in the VM Service will always contain exactly identical hardware to avoid situations like this. VMware does not see this as a bug on their side, but rather one in the guest OS - especially because we haven't been able to reproduce the issue with Ubuntu or Windows guests. I can't speak to other Type 1 hypervisor products, but, as far as I know, VMware does not consider CPUs to be virtualized in the same sense that the other hardware devices are (RAM, scsi controller, disk, network). CPUs are the only major hardware component that is not abstracted when presented to the guest (PCI-slot devices are now being passed through as well in some cases). Their Type 1 hypervisor, ESX/ESXi or vSphere, does allow you to hide some instruction set features from the guest virtual machines (Enhanced VMotion Compatibility or EVC mode). The problem with this approach is that these features are still available, just not advertised. If a guest OS or application makes a specific feature request of the underlying hardware (say on the newer chipset), then is moved live to older hardware, there is a good chance that it will crash - or at the very least run into an issue like the one I mentioned above. > > Virtualization is great, but it's not magic, and here is one case in point. > > True, but it's getting better and better. Plus, now that the CPU vendors are in > favor of it, they're willing to add hardware to make it faster and better. > > One thing that I'm not aware that can be done with any of the x86 > virtualization products is being able to run a hypervisor on top of a > hypervisor. This was possible with IBM's VM/370. In fact, if I remember > correctly, there was no limit on how deep you could stack VMs, other than > hardware resources. You can run VMware's vSphere/ESXi, their COS-less Type 1 hypervisor, on top of VMware Workstation. There are probably other examples of this, and I'm guessing that in the near future this will be extended to allow running ESXi-on-ESXi since Workstation is typically a test-bed for the features that are incoming to their datacenter products. Regarding the original discussion, I agree with one of Erik's original statements: >> I don't think one can really say at this point in time that hypervisors like VMware make the problems of hardware >> differences go away. They may decrease them, but at present they do not eliminate them. This was and is the >> promise of the java approach to virtualization. Apple is still going to have to verify that their OS and standard set of applications work on a wide array of chipsets, including most modern AMD/Intel processors - a far cry from their current support model. - Curtis Links regarding EVC mode: http://kb.vmware.com/kb/1005764 http://kb.vmware.com/kb/1003212 ------------------------------------------------------------------------- The following was automatically added to this message by the list server: To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site: http://micronet.berkeley.edu Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet. This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past. |
On 15-Nov-10 10:00, Curtis Salinas wrote:
> On 11/13/2010 5:47 PM, Jon Forrest wrote: [...] > I can't speak to other Type 1 hypervisor products, but, as far as I know, VMware does not consider CPUs to be virtualized in the same sense that the other hardware devices are (RAM, scsi controller, disk, network). CPUs are the only major hardware component that is not abstracted when presented to the guest (PCI-slot devices are now being passed through as well in some cases). Their Type 1 hypervisor, ESX/ESXi or vSphere, does allow you to hide some instruction set features from the guest virtual machines (Enhanced VMotion Compatibility or EVC mode). The problem with this approach is that these features are still available, just not advertised. If a guest OS or application makes a specific feature request of the underlying hardware (say on the newer chipset), then is moved live to older hardware, there is a good chance that it will crash - or at the very least run into an issue like the one I mentioned above. [...] It is the virtualization of the RAM, SCSI/SAS controller, disks, network adapters, etc. where I've seen the most benefit from virtualization. In my past two jobs we've been able to move VM's around very easily with no issues between different underlying VMWare ESX or ESXi hosts. Since all of the hardware other than the CPU remains the same as far as the guest OS can see the migrations are quick and complication-free (even keeping the same MAC address). This has effectively de-coupled the hardware replacement cycle and the OS major version upgrade/rebuild cycle, which is very nice. Rune ------------------------------------------------------------------------- The following was automatically added to this message by the list server: To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site: http://micronet.berkeley.edu Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet. This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past. |
Free forum by Nabble | Edit this page |