Guest post by 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.
awww, someone just got their Wookie bent. Go Red Hat.
is for the ability to live migrate from vmware or ms virtual pc onto kvm
Anyone get a bead on that gui they were using? Wonder what it i? Doesnt look like ovirt.
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.
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
A Red Hat demo using Sun XVM would be interesting, but very unlikely.
Looks like the SolidICE tools they acquired from Qumranet
It looks like Solid Ice.
http://qumranet.com/products-and-solutions/video-library/27-video-l…
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.
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.
They’ve needed something like this to get some growth coming their way once more. I hope they succeed and continue with more sucesses.
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. 😀
they can boast now
this is very clever!
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…
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.
Hi,
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.
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.
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.