Luca, Yes, I agree with all your points and recommendations of things to check. These baremetal machines have been in place, running qemu/kvm on CoreOS/Container Linux for years. They certainly have the virtualization extensions not disabled in the BIOS and the correct kernel module is loaded.
It is just a warning, yes. The VMs do load, but they are extremely sluggish, apparently not using the virtualization extension. I also realized, though, that this may have been going on for quite a bit longer than the latest update, and I just hadn't noticed. There was another problem I was investigating this morning which turns out to have probably been unrelated... thus my assertion that the problem started to occur in the "latest" version may well have been in error. I need to retire these older VMs anyway, so I'll see if I can find another workaround. Thanks On Thu, Jul 20, 2017 at 10:48 AM Luca BRUNO <[email protected]> wrote: > On Thursday, July 20, 2017 11:52:59 AM UTC Seán C. McCord wrote: > > > rkt[4522]: warning: host doesn't support requested feature: > > CPUID.01H:ECX.vmx [bit 5] > > > > I suspect this is a change in rkt rather than Container Linux, but I > > cannot be sure, and nothing in the 1.27.0 changelog of rkt seems to > > indicated a related change. It would make sense to restrict > > virtualization access from a container, but I'm unsure where I would > > look for that; no capability seems to be related to this. > > I don't think this is related to rkt, or at least not something that broke > during the 1.27.0 release cycle. > You mention above that this is in a stage1-fly environment, and there are > almost no restrictions applied there. I would confidently exclude rkt from > your debugging journey. > > Instead, it looks like the CPUID opcode is not reporting the VMX extension > bit > to userland. Assuming your machine actually offers that extension set, I > think > it may be something related to: > * VT extension that how got disabled by the BIOS > * a microcode update which turned it off due to some reasons > (e.g. instability/bug) > * a parent hypervisor which is now disabling nested-virtualization > * some kernel regression (but I'm not sure it could actually disabled VMX) > > You can probably remove many variable from this equation, and just check > with > a small static binary the content of ECX after a CPUID op. > Moreover, the log line you pasted seems to be a warning, is it actually > halting execution and the real bug? > > I unfortunately don't have enough knowledge in those area, and this is also > specific to your machine architecture/microcode/config. Those above are > just > some wild guesses, take them with a grain of salt. > > Cheers, Luca > > -- > "If you build a wall, think of what you leave outside it" - Italo Calvino > -- Seán C McCord CyCore Systems, Inc +1 888 240 0308 PGP/GPG: http://cycoresys.com/scm.asc
