×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

AMD Demos Live Migration Across Three Opterons

timothy posted about 5 years ago | from the which-walnut-under-which-cup dept.

AMD 25

bigwophh writes "Advanced Micro Devices has just revealed to the public the first video and images demonstrating live migration across three generations of AMD Opteron processors on VMware ESX 3.5, including the six-core AMD Opteron processor, often referred to as 'Istanbul.' For those unaware of the strains in a server environment, live migration of virtual machines across physical servers is crucial to providing flexibility for managing data centers. AMD is also taking this opportunity to highlight its continued, cooperative development efforts with Microsoft as evidenced in Windows Server 2008 R2 Hyper-V, which just also happens to be available today in beta form, that adds support for AMD-V technology with Rapid Virtualization Indexing."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

25 comments

Nothing new? (1)

morgan_greywolf (835522) | about 5 years ago | (#27334469)

VMWare ESX has been able to do live migrations for a while now. I'm not sure what makes the Opteron special in this regard.

Re:Nothing new? (4, Informative)

rachit (163465) | about 5 years ago | (#27334551)

What is new is live migration across different CPU generations.

I believe its using some features in the newer CPUs to turn off certain features / CPUID bits such that all CPUs look the same to the guest OS / applications running on top of it.

Re:Nothing new? (2, Interesting)

Anonymous Coward | about 5 years ago | (#27334813)

No, the CPU features (the CPUID bits) are masked out with ESX, your can fine-tune this in the settings of every VM.

Re:Nothing new? (5, Informative)

Domint (1111399) | about 5 years ago | (#27334569)

The crucial part is the 'across three generations' bit - I can tell you from first hand experience that VMWare ESX has problems performing live migrations across CPUs with different steppings even within the same generation, so the fact that AMD pulled it off across 3 distinct generations without having to utilize cobbed-together solutions like EVC is a pretty big deal. Or, at least it is to me.

Re:Nothing new? (1)

morgan_greywolf (835522) | about 5 years ago | (#27334697)

without having to utilize cobbed-together solutions like EVC

I was just about to say 'EVC' when I got that part of your post. The thing is if you are already running EVC, then it doesn't matter much. The hard part of EVC is getting the first couple of hosts running. Once that's going, EVC is cake.

Re:Nothing new? (1)

Natales (182136) | about 5 years ago | (#27338083)

It's not that ESX has issues. It's that the Guest OS is flat out not designed for "something" to change your CPU on the fly, which is the way the guest sees it... In fact we (yes, I work for VMware) used to allow that back in the ESX 2.0 days, but the guest bluescreened/panicked after a while as the microcode is loaded at boot time. The only way we can pull these tricks today is by masking some specific instructions of newer chip generations vs. the previous ones. Hard, but not rocket science. Get me a guest that adapt to those changes live and you'll have what you want...

Re:Nothing new? (1)

morgan_greywolf (835522) | about 5 years ago | (#27340357)

Get me a guest that adapt to those changes live and you'll have what you want...

Generally speaking, Linux distros will move between different processors as long as they are the same generation...x86-64 will move to other x86-64s, for instance.

Re:Nothing new? (1)

WaxMan0 (1417015) | about 5 years ago | (#27341187)

Pretty certian the is marketing bumpf, Is this not what the AMD-v and intels equivilent (cant remember of the op of my head) allow. Realy wish i kept my sources to refernace but from what i remember the different levels of virtuilisation include emulation where the complete pc is emulated and the OS sees this as a native hardware this is the Slow method and used by older desktop virtual pc applications. Another 2 one of which I have completely forgotten the other uses a set of cpu instructions to allow the hyper-visor to present to a modified OS an interface the OS calls this and is rerouted directly to the hardware, requires different kernals if I recall available on Linux for a while and now in Windows server 2008. This model allows for the level of migration that you would find with the fully emulated version but with close to bare metal performance, most recent opterons and AM2 athalon and phenoms have amd-v while c2d+ as well as some older P4's (some pentium D's) have the intel version. Would love to be corrected but old hat tbh. and if not only because AMD took so long to finalise the amd-v instruction sets from one core gen to the next.

Yay? (3, Interesting)

eln (21727) | about 5 years ago | (#27334505)

They can call me when they've demonstrated seamless live migration between Intel and AMD chips, not just generations of their own hardware. Nobody wants to build a large-scale cloud if they're going to be locked to one vendor forever once they get started.

Virtual machines horribly slow? (0)

Anonymous Coward | about 5 years ago | (#27334861)

I've never tried VMware ESX, but anytime I've used VMWare, or dealt with customers using virtual machines in there own data center it has been horribly slow. They often say they have these 8-16 core machines with gobs of ram, and allocate more then enough to the virtual machine running our software, but without fail it often runs 25-50% slower then a basic single core server with 1gb of ram.

I realize this can greatly depend on the load of the machine at the time, but does anyone have an URL to benchmarks with a single virtual machine running under VMWare ESX vs. the exact same machine not running VMWare ESX?

Re:Virtual machines horribly slow? (0)

Anonymous Coward | about 5 years ago | (#27334991)

Of course, it's a little bit slower - though in my experience not the numbers you've been getting. But get a cluster of VMWare ESX servers and the extra redundancy and ease of provisioning new VMs and reconfiguring existing VMs really does make up for the slowness.

Re:Virtual machines horribly slow? (0)

Anonymous Coward | about 5 years ago | (#27337143)

Unfortunately VMware really is very very slow, even in comparison with other competing vendors software virtualization technologies. I've found it to be anything upto half the performance of alternatives. AG

Re:Virtual machines horribly slow? (0)

Anonymous Coward | about 5 years ago | (#27337651)

Now you're just sounding like a troll.

What about networks? (0)

Anonymous Coward | about 5 years ago | (#27335099)

This is pretty impressive. Instruction set differences and chipset differences have to all be abstracted away. No small feat.

I was curious how they migrate active network connections though. Does the old host act as a proxy/router? Can anyone shed some light?

Re:What about networks? (3, Interesting)

Chris Burke (6130) | about 5 years ago | (#27335353)

I was curious how they migrate active network connections though. Does the old host act as a proxy/router? Can anyone shed some light?

Its been around 9 years since I did the project in college, but it is possible to transfer active network connection state from one computer to another. It was a "connection-aware seamless backup server", where our hacked linux kernels would exchange state about an active TCP/IP connection at regular intervals, and when the primary dropped (in our demo we yanked the ethernet cable out of the hub in the middle of streaming an mp3), the other would take over, pretending to be the same IP and picking up where the other left off. The best part was that TCP/IP already deals with redundant, missing, or out of order packets so anything sent or received since the last update to the backup would be handled automagically.

That was just as stupid semester project on a 3-computer ethernet LAN, but I imagine the big boys have figured out how to make it work. Besides, they're literally transfering the memory image of the guest OS over to the other machine so all the state update is already done. The hard part is probably making the IP migrate along with, but I'm sure they've figured that out too.

Re:What about networks? (3, Interesting)

cowbutt (21077) | about 5 years ago | (#27335943)

That was just as stupid semester project on a 3-computer ethernet LAN, but I imagine the big boys have figured out how to make it work

Checkpoint's Firewall-1 product has been able to transfer the current firewall state to a backup firewall for quite some time (at least 1998 or so), but it originally required the use of RIP to implement failover which introduced delays. In about 1999, Stonesoft produced an add-on product, Stonebeat, which added ARP spoofing, so the failover was virtually instantaneous. These days, the failover is done using VSRP.

Re:What about networks? (1)

omfglearntoplay (1163771) | about 5 years ago | (#27342087)

Supposedly Double-Take software is good at "mirroring" one box with another... and then when box1 dies box2 very quickly takes over, stealing the IP, etc. I have the software, but I haven't had the balls or the weekend time to test it for real yet.

Re:What about networks? (0)

Anonymous Coward | about 5 years ago | (#27342789)

"The hard part is probably making the IP migrate along with, but I'm sure they've figured that out too."

It's called VRRP, it's been around for a very long time. I use it to move around Xen guests and for router failover. Works great.

Re:What about networks? (1)

Domint (1111399) | about 5 years ago | (#27335495)

Nothing that complex. It simply passes the TCP state from one nic to the other. I don't know the gory details of how that all happens behind the scenes, but it's pretty impressive to watch it happen - in our lab at work we tested this functionality on multiple guest OSes simultaneously and didn't lose a single packet, even when pulling the power chords out of a number of components (including one of the ESX servers).

Re:What about networks? (1)

chrome (3506) | about 5 years ago | (#27339769)

as far as the nics are concerned, its all just ethernet packets. There is no state to handle. The state is maintained by the guest OS, and is transferred when the OS memory is transferred.

Re: (1)

clint999 (1277046) | about 5 years ago | (#27344631)

Nothing that complex. It simply passes the TCP state from one nic to the other. I don't know the gory details of how that all happens behind the scenes, but it's pretty impressive to watch it happen - in our lab at work we tested this functionality on multiple guest OSes simultaneously and didn't lose a single packet, even when pulling the power chords out of a number of components (including one of the ESX servers).
Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...