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.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-11-16
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.
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.
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.