On Mon, Dec 15, 2014 at 06:56:19PM +0100, intrigeri wrote: > hi, > > Chris Boot wrote (15 Dec 2014 12:39:52 GMT) : > > The intel-microcode 3.20140913.1 update disables TSX-NI (transactional > > memory instructions). When a server running libvirt is rebooted with > > this update, libvirt no longer considers the machine to have a Haswell > > CPU: > > > dietrich ~ # virsh capabilities | grep -A1 '<arch>x86_64' > > <arch>x86_64</arch> > > <model>SandyBridge</model> > > > This causes a problem as any VMs that require a Haswell CPU, which would > > have worked previously, now fail to start altogether. Commenting out the > > two cpuinfo flags relevant to TSX-NI from /usr/share/libvirt/cpu_map.xml > > fixes this for me: > > FWIW, I've been suffering from the symptoms of that issue for a few > weeks. I guessed it was caused by that microcode update, but had no > time to report it. *If* that's a regression since Wheezy, I think > it would qualify as RC, since VMs that started just fine previously > now fail to come up at boot. The workaround (in the package) is tiny, > and makes sense to me: if Intel themselves now consider that Haswell > CPUs have no TSX-NI, then libvirt's view of what's a Haswell CPU > should be updated. > > OTOH, the user-side workaround (copy host CPU model) is easy enough > too, although a bit painful to discover initially for many users > I guess. > > Shall we ask the release team if they would happily unblock this > change for Jessie?
I think we should. I've submitted it upstream to get some feadback and make this a safe change and thanks to both of you! Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
