On Wed, Oct 7, 2009 at 4:29 PM, Bill Nottingham <notting@xxxxxxxxxx> wrote: > Richard W.M. Jones (rjones@xxxxxxxxxx) said: >> > This is going to be pretty important for scientific workloads where >> > atlas is going to be used. I've eavesdropped on several conversations >> > where people were talking about being able to run off-the-shelf >> > science code virtual appliance in order to reduce the environment >> > configuration workload for an individual researcher. >> >> Yup. The really fun starts when you do live migration. The processor >> literally changes underneath the running programs. If you thought you >> had SSE3 one minute, then the next you don't, or vice versa. >> >> No one has to my knowledge come up with a good way to deal with this. >> But it probably involves signalling the kernel and processes so that >> they can redo processor detection. You can see why that is not going >> to be pleasant. > > Surely the way to do this is to know what your workload is doing, > and not do live migration to random hardware? In fact the proper way to do this it to have the same hardware in the group of servers that VMs might be live migrated between so that its not an issue. Then the only time this would then come into play is when you are upgrading the group/cluster of machines to newer hardware and that shouldn't be an issue as the newer hardware should have more features in the CPU and not less. This is the way we do it in the Enterprise hosting company that I work for which has a VM environment over around 250 hosts runninng around 2500 VMs. We have a few disparate clusters with different devices using different HW but in that case we use the CPU masking features of the main proprietary product that is in use in that particular case. Cheers, Peter -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
