virt-host-validate is provided by libvirt-daemon, changing component

The command only validates the *host* (the machine you run it on) and whether it is fit for various hypervisors.  It can be used even without any QEMU installed, it does not check the binaries.

One might suggest to split the checks like this:

  QEMU: Checking for domain=type'kvm'
  QEMU: Checking for domain=type'qemu'

but since the host can always support emulated CPUs (on any architecture) the second test would always pass.  And because we do not check the binaries (which might not be installed or might not support KVM acceleration simply because they were built without it) it would essentially mean the same thing as "hardware virtualization" only with a more confusing naming.

So I would rather leave it like it is.  Remember that virt-host-validate only checks what the *host* is capable of.

(In reply to Martin Kletzander from comment #2)
> The command only validates the *host* (the machine you run it on) and
> whether it is fit for various hypervisors.  It can be used even without any
> QEMU installed, it does not check the binaries.
> 
> One might suggest to split the checks like this:
> 
>   QEMU: Checking for domain=type'kvm'
>   QEMU: Checking for domain=type'qemu'
> 
> but since the host can always support emulated CPUs (on any architecture)
> the second test would always pass.  And because we do not check the binaries
> (which might not be installed or might not support KVM acceleration simply
> because they were built without it) it would essentially mean the same thing
> as "hardware virtualization" only with a more confusing naming.
> 
> So I would rather leave it like it is.  Remember that virt-host-validate
> only checks what the *host* is capable of.

Hi Martin, if I understand correctly that the command can detect host compatibility with specific hypervisors, then it should still be possible to replace the error message for this specific validation result with a less ambiguous one, right? For example just "FAIL (Host hardware not compatible with KVM)" - no need to mention emulated CPUs explicitly, since, as you pointed out, every host can support those.

Or am I missing the point here?

(In reply to Jiri Herrmann from comment #3)
> (In reply to Martin Kletzander from comment #2)
> > The command only validates the *host* (the machine you run it on) and
> > whether it is fit for various hypervisors.  It can be used even without any
> > QEMU installed, it does not check the binaries.
> > 
> > One might suggest to split the checks like this:
> > 
> >   QEMU: Checking for domain=type'kvm'
> >   QEMU: Checking for domain=type'qemu'
> > 
> > but since the host can always support emulated CPUs (on any architecture)
> > the second test would always pass.  And because we do not check the binaries
> > (which might not be installed or might not support KVM acceleration simply
> > because they were built without it) it would essentially mean the same thing
> > as "hardware virtualization" only with a more confusing naming.
> > 
> > So I would rather leave it like it is.  Remember that virt-host-validate
> > only checks what the *host* is capable of.
> 
> Hi Martin, if I understand correctly that the command can detect host
> compatibility with specific hypervisors, then it should still be possible to
> replace the error message for this specific validation result with a less
> ambiguous one, right? For example just "FAIL (Host hardware not compatible
> with KVM)" - no need to mention emulated CPUs explicitly, since, as you
> pointed out, every host can support those.
> 
> Or am I missing the point here?

That explanation is a bit more clear, you are right.  I can still see that someone might get confused the other way, thinking that virtual machines will not work on the host.  I might not be completely hardware-related.  So anyway, I'll try to propose a change to "Host not compatible with KVM, performance will be significantly limited" and we'll see what the community thinks about that version.  Would that phrasing work for you?

(In reply to Martin Kletzander from comment #4)
> 
> That explanation is a bit more clear, you are right.  I can still see that
> someone might get confused the other way, thinking that virtual machines
> will not work on the host.  I might not be completely hardware-related.  So
> anyway, I'll try to propose a change to "Host not compatible with KVM,
> performance will be significantly limited" and we'll see what the community
> thinks about that version.  Would that phrasing work for you?

I think I'll first need to clarify the UX implications of the host not being compatible with KVM. If on such a host, you use "virt-install" or other libvirt utilities, will they work, but create (and manage) QEMU-type VMs rather than KVM-type VMs? Or will they fail, and you'd need to use the QEMU command line instead?

If the former, then I think your proposed wording works. If the latter, then it would probably be better to go into detail a bit more - e.g. "Host not compatible with KVM. Only emulated CPUs with limited performance are available."

WDYT?

(In reply to Jiri Herrmann from comment #5)
> (In reply to Martin Kletzander from comment #4)
> > 
> > That explanation is a bit more clear, you are right.  I can still see that
> > someone might get confused the other way, thinking that virtual machines
> > will not work on the host.  I might not be completely hardware-related.  So
> > anyway, I'll try to propose a change to "Host not compatible with KVM,
> > performance will be significantly limited" and we'll see what the community
> > thinks about that version.  Would that phrasing work for you?
> 
> I think I'll first need to clarify the UX implications of the host not being
> compatible with KVM. If on such a host, you use "virt-install" or other
> libvirt utilities, will they work, but create (and manage) QEMU-type VMs
> rather than KVM-type VMs? Or will they fail, and you'd need to use the QEMU
> command line instead?
> 
> If the former, then I think your proposed wording works. If the latter, then
> it would probably be better to go into detail a bit more - e.g. "Host not
> compatible with KVM. Only emulated CPUs with limited performance are
> available."
> 
> WDYT?

Well, it is a bit more complicated than that.

For example virt-install might choose to install a plain QEMU guest and maybe show a warning.  But it is an implementation detail of that particular management application and another application might behave completely differently and the decision is made at the discretion of the mgmt app.

Also don't forget that virt-host-validate checks the availability only for the current user.

I think there are might be false expectation of the tool in particular.

To your point about changing:

Checking for hardware virtualization: FAIL (Only emulated CPUs are available, performance will be significantly limited)

to:

Checking for hardware virtualization: FAIL (Host not compatible with KVM, only emulated CPUs with limited performance are available)

I must say, with all due respect, I don't see much of an improvement there.  "not compatible with KVM" already says the same thing as "hardware virtualization: FAIL" effectively being redundant.  And I believe that "performance will be _significantly_ limited" was chosen to indicate that the difference really is drastic.

But back to what I think is the original pain point about this.  Maybe the understanding of the output should be changed. The virt-host-validate tool is just a helper to point users to main known possible issues, but every non-PASS result should be read and understood on its own.  There are few cases for which the tool is able to provide hints on how to try fixing the issue, but in the end it might not be an issue at all, it might not be relevant to the particular user's scenario.

I hope what I wrote makes sense, feel free to request clarifications ;)

(In reply to Martin Kletzander from comment #6)
> 
> Well, it is a bit more complicated than that.
> 
> For example virt-install might choose to install a plain QEMU guest and
> maybe show a warning.  But it is an implementation detail of that particular
> management application and another application might behave completely
> differently and the decision is made at the discretion of the mgmt app.
> 
> Also don't forget that virt-host-validate checks the availability only for
> the current user.
> 
> I think there are might be false expectation of the tool in particular.
> 
> To your point about changing:
> 
> Checking for hardware virtualization: FAIL (Only emulated CPUs are
> available, performance will be significantly limited)
> 
> to:
> 
> Checking for hardware virtualization: FAIL (Host not compatible with KVM,
> only emulated CPUs with limited performance are available)
> 
> I must say, with all due respect, I don't see much of an improvement there. 
> "not compatible with KVM" already says the same thing as "hardware
> virtualization: FAIL" effectively being redundant.

Good point, but keep in mind that while it is eminently obvious to you that "hardware virtualization" = KVM, it may not be as clear to someone just starting out with virtualization (i.e. a major segment of users of virt-host-validate).

Perhaps more importantly, though, this avoids the potential for the user to interpret the message as "I'm good to go, should only expect performance issues" - which is especially important on RHEL, where we actually don't support QEMU guests. 

In fact, this specific error message was originally reported against our RHEL 8 "getting started" doc by a solution architect - https://bugzilla.redhat.com/show_bug.cgi?id=1651556

In hindsight, I probably should have suggested using a different wording for the error msg back then, but better late than never, I hope :-)

> And I believe that
> "performance will be _significantly_ limited" was chosen to indicate that
> the difference really is drastic.

Agreed, if the performance impact of using emulated CPUs is inevitably major, the output should mention it.

> 
> But back to what I think is the original pain point about this.  Maybe the
> understanding of the output should be changed. The virt-host-validate tool
> is just a helper to point users to main known possible issues, but every
> non-PASS result should be read and understood on its own.

Fair enough, but I believe that if the helpfulness of the tool can be improved (and/or its ambiguity minimized) by something as simple as changing the text of an error message, we should do it.

Or am I still missing anything here?

Cheers,
J.

>  There are few
> cases for which the tool is able to provide hints on how to try fixing the
> issue, but in the end it might not be an issue at all, it might not be
> relevant to the particular user's scenario.
> 
> I hope what I wrote makes sense, feel free to request clarifications ;)

(In reply to Jiri Herrmann from comment #7)
> (In reply to Martin Kletzander from comment #6)
> > I must say, with all due respect, I don't see much of an improvement there. 
> > "not compatible with KVM" already says the same thing as "hardware
> > virtualization: FAIL" effectively being redundant.
> 
> Good point, but keep in mind that while it is eminently obvious to you that
> "hardware virtualization" = KVM, it may not be as clear to someone just
> starting out with virtualization (i.e. a major segment of users of
> virt-host-validate).
> 
> Perhaps more importantly, though, this avoids the potential for the user to
> interpret the message as "I'm good to go, should only expect performance
> issues" - which is especially important on RHEL, where we actually don't
> support QEMU guests. 
> 

You're right, I guess users running this will be those who might need a bit of a redundancy to make sure we are understood.

> In fact, this specific error message was originally reported against our
> RHEL 8 "getting started" doc by a solution architect -
> https://bugzilla.redhat.com/show_bug.cgi?id=1651556
> 
> In hindsight, I probably should have suggested using a different wording for
> the error msg back then, but better late than never, I hope :-)
> 
> > And I believe that
> > "performance will be _significantly_ limited" was chosen to indicate that
> > the difference really is drastic.
> 
> Agreed, if the performance impact of using emulated CPUs is inevitably
> major, the output should mention it.
>

So I'll keep that bit.
 
> > 
> > But back to what I think is the original pain point about this.  Maybe the
> > understanding of the output should be changed. The virt-host-validate tool
> > is just a helper to point users to main known possible issues, but every
> > non-PASS result should be read and understood on its own.
> 
> Fair enough, but I believe that if the helpfulness of the tool can be
> improved (and/or its ambiguity minimized) by something as simple as changing
> the text of an error message, we should do it.
> 
> Or am I still missing anything here?
> 

No, I am definitely on your side here, I'm just trying to figure out the details so that we don't have the same discussion again when I submit the patch =)

I'll put some sentence together and see what others think about it.

Verify this bug with libvirt-8.7.0-1.el9.x86_64:

1. prepare a host which hardware not support KVM

2. run virt-host-validate

# virt-host-validate 
  QEMU: Checking for hardware virtualization                                 : FAIL (Host not compatible with KVM; HW virtualization CPU features not found. Only emulated CPUs are available; performance will be significantly limited)
  QEMU: Checking if device /dev/vhost-net exists                             : PASS
  QEMU: Checking if device /dev/net/tun exists                               : PASS
  QEMU: Checking for cgroup 'cpu' controller support                         : PASS
  QEMU: Checking for cgroup 'cpuacct' controller support                     : PASS
  QEMU: Checking for cgroup 'cpuset' controller support                      : PASS
  QEMU: Checking for cgroup 'memory' controller support                      : PASS
  QEMU: Checking for cgroup 'devices' controller support                     : PASS
  QEMU: Checking for cgroup 'blkio' controller support                       : PASS
  QEMU: Checking for device assignment IOMMU support                         : WARN (Unknown if this platform has IOMMU support)
  QEMU: Checking for secure guest support                                    : WARN (Unknown if this platform has Secure Guest support)

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (libvirt bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:2171