>>> On 1/17/2015 at 06:37 PM, S.M. wrote:
> M.P. said:
>> You'll need to be a little more verbose. What about error recovery?
> Does KVM on a bare LPAR have code to recover from I/O, memory and
> processor failures? Does it have code to record transient errors for
> later analyses?
What you're talking about aren't features of a hypervisor, per se, but operating
systems in general. In this case, that would be Linux. So, with the _possible_
exception of recording transient errors for later analysis, I would say "yes."
Now, Linux does create records for "machine check events." They go in
/var/log/mcelog. However, I have little experience with that part of the OS, so
I don't know just how wide a range of things get recorded, nor how those would
compare to what gets recorded by logrec.
Based on the way you phrased your question (on a bare LPAR) it might be worth
pointing out that the Linux kernel executes the exact same code in an LPAR as it
would as a z/VM guest. When running as a KVM guest, that's not quite as true,
since KVM presents abstracted versions of virtual devices (virtio), while z/VM
does not. That caveat would apply mainly to device drivers, however, not the
kernel in general.
As a "proof point" (as the marketeers and sales 'droids like to say), SUSE runs
a number of "bare metal" LPARs for our software build service. Each of those
LPARs uses KVM to create virtual build servers to compile and package the nearly
3,000 packages that we ship for System z. As you might guess, we consider the
build service one of our mission critical applications, so it's important to us
that things work well. We don't assume that those applications are in any way
representative of what or customers would be doing, so we're not prepared to
declare KVM on System z ready for production without more real-world testing.
Those LPARs and KVM environments are relatively static when it comes to how many
there are of them, what resources are assigned to them, etc. The build service
tends to saturate the CPUs of our zEC12 pretty constantly. (Gotta love an
architecture that can handle that.)
We also have several z/VM LPARs that we use to host Linux systems. These
systems are more dynamic and transient. We use them to replicate customer
problems, do development and so on. We also have a few LPARs that are not part
of the build service for development and testing as well. So, we don't just do
z/VM, KVM, or LPARs, we do them all. My _personal_ preference is to run Linux
as a guest on z/VM. I think z/VM provides far more flexibility, stability and
performance than any other choice available t oday.