[Micronet] Open letter to Jobs

[Scot Hacker]

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.

[Jon Forrest]

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.

[Graham Patterson]

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.

[Erik Klavon]

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.

[Jon Forrest]

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.

[Erik Klavon]

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.

[Jon Forrest]

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.

[Erik Klavon]

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.

[Jon Forrest]

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.

[Michael Sinatra-2]

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.

[Jon Forrest]

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.

[Curtis Salinas]

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.

[Rune Stromsness]

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.