Linked by Rahul on Sun 9th Nov 2008 10:20 UTC
Red Hat Red Hat and AMD have just done the so-called impossible, and demonstrated VM live migration across CPU architectures. Not only that, they have demonstrated it across CPU vendors. "If you look at the video here, you will see that they did it. Live migration while streaming HD video isn't all that bad a trick mind you, but doing it between a Barcelona, Shanghai and Intel box is. 36 more of these, and we will be in great shape." Only a few months ago during VMworld, Intel and VMware claimed that this was impossible. Looking at the initial reaction, VMware is quite irked by this accomplishment by Red Hat using KVM technology and they are pointing to stability concerns. Red Hat has been a heavy contributor to KVM and acquired Qumranet, the original developers of KVM a while back.
Order by: Score:
oops
by TechGeek on Sun 9th Nov 2008 17:24 UTC
TechGeek
Member since:
2006-01-14

awww, someone just got their Wookie bent. Go Red Hat.

Reply Score: 3

only thing missing...
by hobgoblin on Sun 9th Nov 2008 17:37 UTC
hobgoblin
Member since:
2005-07-06

is for the ability to live migrate from vmware or ms virtual pc onto kvm ;)

Reply Score: 2

Gui?
by HeLfReZ on Sun 9th Nov 2008 17:55 UTC
HeLfReZ
Member since:
2005-08-12

Anyone get a bead on that gui they were using? Wonder what it i? Doesnt look like ovirt.

Reply Score: 2

RE: Gui?
by TechGeek on Sun 9th Nov 2008 18:56 UTC in reply to "Gui?"
TechGeek Member since:
2006-01-14

I was wondering that too. Would be nice if they listed the software they were using. Like the client. Was that a client running rdp into a windows guest? I didnt know rdp supported full video.

Reply Score: 2

RE[2]: Gui?
by HeLfReZ on Sun 9th Nov 2008 19:29 UTC in reply to "RE: Gui?"
HeLfReZ Member since:
2005-08-12

Actually I think i answered my own question. I think they may be running early access or a mod of xvmserver from Sun. check it out at xvmserver.org. I thought it was ovirt at first, but that looks nothing like ovirt.

edit: funny thing is the first binary code release is due tomorrow! fun fun. I'm a virtualization addict so I can't wait.

Edited 2008-11-09 19:32 UTC

Reply Score: 2

RE[3]: Gui?
by ian.woodstock on Sun 9th Nov 2008 22:32 UTC in reply to "RE[2]: Gui?"
ian.woodstock Member since:
2008-11-09

A Red Hat demo using Sun XVM would be interesting, but very unlikely.

Looks like the SolidICE tools they acquired from Qumranet

Reply Score: 1

RE: Gui?
by sdodson on Sun 9th Nov 2008 20:25 UTC in reply to "Gui?"
sdodson Member since:
2007-01-06
RE[2]: Gui?
by HeLfReZ on Sun 9th Nov 2008 21:21 UTC in reply to "RE: Gui?"
HeLfReZ Member since:
2005-08-12

Well that would definately make more SENSE! I think you hit it on the head. I never could find any info on solid ice, was always behind closed doors.

Reply Score: 2

pretty sweet
by TechGeek on Sun 9th Nov 2008 22:09 UTC
TechGeek
Member since:
2006-01-14

They definitely have a pretty sweet technology. I wonder if Red Hat will open it up now that they own it? Solid ICE looks very cool. I wonder if it will replace O-virt or if this will continue to be a pay-for enterprise solution.

Reply Score: 2

Good for RedHat
by tyrione on Mon 10th Nov 2008 00:41 UTC
tyrione
Member since:
2005-11-21

They've needed something like this to get some growth coming their way once more. I hope they succeed and continue with more sucesses.

Reply Score: 3

NOT architectures
by 3rdalbum on Mon 10th Nov 2008 09:50 UTC
3rdalbum
Member since:
2008-05-26

They did NOT migrate a VM between different architectures. All three hosts and the guest were all ia32 architecture.

Microarchitecture, yes. But they all run the same instructions, and the kernel will abstract away the differences between the processors.

When Red Hat can migrate a VM between an Acorn Archemides, a Playstation 2 and a quad-core Xeon server, then they can boast. :-D

Reply Score: 1

RE: NOT architectures
by Adurbe on Mon 10th Nov 2008 11:48 UTC in reply to "NOT architectures"
Adurbe Member since:
2005-07-06

they can boast now

this is very clever!

Reply Score: 2

Umm
by Brendan on Mon 10th Nov 2008 13:45 UTC
Brendan
Member since:
2005-11-16

Hi,

So, let me get this straight - you've got a kernel running under one "quad core virtual machine" that was told that each of the virtual CPUs support certain features (e.g. SSE4).

Then you migrate this virtual machine to an old 80486 box, and suddenly 3 cores and all the modern CPU features are gone, and the kernel and all the applications that were relying on these features just keep running?

Maybe, for the purpose of demonstration, they made sure that all CPUs were very similar (same number of cores, similar features, etc) and disabled any features in some CPUs that weren't present in others...

Reply Score: 1

RE: Umm
by NxStY on Mon 10th Nov 2008 14:20 UTC in reply to "Umm"
NxStY Member since:
2005-11-12

So, let me get this straight - you've got a kernel running under one "quad core virtual machine" that was told that each of the virtual CPUs support certain features (e.g. SSE4).

Then you migrate this virtual machine to an old 80486 box, and suddenly 3 cores and all the modern CPU features are gone, and the kernel and all the applications that were relying on these features just keep running?


If you have an app that requires some special instruction set like SSE4 it wouldn't run on the 486 in the first place.

Reply Score: 2

RE[2]: Umm
by Brendan on Mon 10th Nov 2008 23:35 UTC in reply to "RE: Umm"
Brendan Member since:
2005-11-16

Hi,

If you have an app that requires some special instruction set like SSE4 it wouldn't run on the 486 in the first place.


I'm thinking you missed the point entirely. All CPUs have a variety of features. Some of those features are vendor specific (e.g. Intel's SpeedStep, AMD's Cool'n'Quiet, machine check, performance monitoring, certain debugging features, etc) and some are just "new" (e.g. SSE5, x2APIC). For VM migration to work you'd need to tell the virtual machine that none of the new CPU features and none of the vendor specific features are present.

Then there's certain optimizations (page coloring, NUMA, instruction selection, etc) that tune the software/kernel to the CPU. Kiss them goodbye too.

Now, let's imagine you install an OS inside a virtual machine, and the OS detects that the CPU has flaws and implements work-arounds for those flaws. Then it's migrated to a different CPU with different flaws that need different work-arounds.

Basically, what they're doing is reducing the CPU feature set to the lowest common denominator (and the number of CPUs/cores, amount of RAM, etc), so that inside the virtual machine all (supported) computers look the same. The problem is that all (supported) computers aren't the same - you lose features, you lose optimizations and you lose reliability.

Reply Score: 1

RE[3]: Umm
by bert64 on Tue 11th Nov 2008 11:17 UTC in reply to "RE[2]: Umm"
bert64 Member since:
2007-04-23

Well, features like cool'n'quiet and speedstep would be abtracted away by the hypervisor anyway, the hypervisor would want to be in control of the cpu frequency as individual guests can't know how busy other guests are so you dont want an idle guest downclocking the cpu that a busy guest is trying to use...

Same with numa etc...

When it comes to CPU specific performance tuning, yes some performance could potentially be lost if something is tuned to the timing of a particular cpu, but a performance loss is already accepted simply by running a virtualization environment...

Also the number of cores/cpus would be abstracted by the hypervisor, each cpu seen by the virtual is actually a process running on the host, a physical host with 1 core could run 4 processes to supply a guest with 4 (slow) virtual cores. It's just not done very often because it's not useful for anything other than debugging and use in scenarios like the one described here.

Also it takes quite some time before mainstream applications are compiled for specific cpu features like SSE4. You may have problems migrating a heavily tuned gentoo image, but most precompiled systems would move across fine.

However where i see this technology really working, is migrating existing running machines to new hardware (which will almost certainly support everything it's predecessor did and then some) without interrupting the work the machines are doing.

Reply Score: 1

RE: Umm
by broken_symlink on Mon 10th Nov 2008 17:18 UTC in reply to "Umm"
broken_symlink Member since:
2005-07-06

I'm pretty sure that KVM requires virtualization extensions in order to work, so you couldn't migrate to a 486. You would only be able to migrate to other x86 cpus with virtualization extensions.

Reply Score: 2