[libvirt] [PATCH 0/5] qemu: Detect KVM usability correctly

Andrea Bolognani posted 5 patches 5 years, 6 months ago
Failed in applying to current master (apply log)
src/qemu/qemu_capabilities.c                  |  27 +---
src/qemu/qemu_capabilities.h                  |   4 +-
tests/qemucapabilitiestest.c                  |   1 +
tests/qemucaps2xmldata/all_1.6.0-1.caps       | 129 ------------------
.../nodisksnapshot_1.6.0-1.caps               | 128 -----------------
.../caps_1.5.3.x86_64.xml}                    |  12 +-
.../caps_1.6.0.x86_64.xml}                    |  14 +-
.../caps_1.7.0.x86_64.xml}                    |  12 +-
.../caps_2.1.1.x86_64.xml}                    |  12 +-
.../caps_2.10.0.aarch64.xml}                  |  13 +-
.../caps_2.10.0.ppc64.xml}                    |  14 +-
.../caps_2.10.0.s390x.xml}                    |  14 +-
.../caps_2.10.0.x86_64.xml}                   |  12 +-
.../caps_2.11.0.s390x.xml}                    |  14 +-
.../caps_2.11.0.x86_64.xml}                   |  12 +-
.../caps_2.12.0.aarch64.xml}                  |  13 +-
.../caps_2.12.0.ppc64.xml}                    |  14 +-
.../caps_2.12.0.s390x.xml}                    |  14 +-
.../caps_2.12.0.x86_64.xml}                   |  12 +-
.../caps_2.4.0.x86_64.xml}                    |  12 +-
.../caps_2.5.0.x86_64.xml}                    |  12 +-
.../caps_2.6.0.aarch64.xml}                   |  13 +-
.../caps_2.6.0.ppc64.xml}                     |  14 +-
.../caps_2.6.0.x86_64.xml}                    |  12 +-
.../caps_2.7.0.s390x.xml}                     |  14 +-
.../caps_2.7.0.x86_64.xml}                    |  12 +-
.../caps_2.8.0.s390x.xml}                     |  14 +-
.../caps_2.8.0.x86_64.xml}                    |  12 +-
.../caps_2.9.0.ppc64.xml}                     |  14 +-
.../caps_2.9.0.s390x.xml}                     |  14 +-
.../caps_2.9.0.x86_64.xml}                    |  12 +-
.../caps_3.0.0.ppc64.xml}                     |  14 +-
.../caps_3.0.0.riscv32.xml}                   |  13 +-
.../caps_3.0.0.riscv64.xml                    |  25 ++++
.../caps_3.0.0.x86_64.xml}                    |  12 +-
tests/qemucaps2xmltest.c                      |  63 +++++++--
tests/qemuxml2argvtest.c                      |  11 +-
37 files changed, 229 insertions(+), 535 deletions(-)
delete mode 100644 tests/qemucaps2xmldata/all_1.6.0-1.caps
delete mode 100644 tests/qemucaps2xmldata/nodisksnapshot_1.6.0-1.caps
copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_1.5.3.x86_64.xml} (67%)
rename tests/{qemucaps2xmldata/nodisksnapshot_1.6.0-1.xml => qemucaps2xmloutdata/caps_1.6.0.x86_64.xml} (60%)
copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_1.7.0.x86_64.xml} (67%)
copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.1.1.x86_64.xml} (67%)
copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.10.0.aarch64.xml} (62%)
copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.10.0.ppc64.xml} (56%)
copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.10.0.s390x.xml} (56%)
copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.10.0.x86_64.xml} (67%)
copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.11.0.s390x.xml} (56%)
copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.11.0.x86_64.xml} (67%)
copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.12.0.aarch64.xml} (62%)
copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.12.0.ppc64.xml} (56%)
copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.12.0.s390x.xml} (56%)
copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.12.0.x86_64.xml} (67%)
copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.4.0.x86_64.xml} (67%)
copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.5.0.x86_64.xml} (67%)
copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.6.0.aarch64.xml} (62%)
copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.6.0.ppc64.xml} (56%)
copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.6.0.x86_64.xml} (67%)
copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.7.0.s390x.xml} (56%)
copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.7.0.x86_64.xml} (67%)
copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.8.0.s390x.xml} (56%)
copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.8.0.x86_64.xml} (67%)
copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.9.0.ppc64.xml} (56%)
copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.9.0.s390x.xml} (56%)
copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.9.0.x86_64.xml} (67%)
copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_3.0.0.ppc64.xml} (56%)
copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_3.0.0.riscv32.xml} (54%)
create mode 100644 tests/qemucaps2xmloutdata/caps_3.0.0.riscv64.xml
rename tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_3.0.0.x86_64.xml} (67%)
[libvirt] [PATCH 0/5] qemu: Detect KVM usability correctly
Posted by Andrea Bolognani 5 years, 6 months ago
There are a few cases in which we're not reporting the correct
information through 'virsh capabilities', leading to applications
such as libguestfs attempting to launch KVM guests on a host that
doesn't actually support them.

Our code is also more complicated than it needs to be due to
backwards compatibilty reasons that we no longer care about these
days, so we can perform some cleanup there; there are further
cleanup opportunities in the same area, but some of them are a
bit tricky so I'll leave them for a follow-up series.

We also get some extra test coverage pretty much for free. Yay!

Andrea Bolognani (5):
  tests: Reuse qemucapabilities data for qemucaps2xml
  tests: Add more tests to qemucaps2xml
  qemu: Drop QEMU_CAPS_ENABLE_KVM
  qemu: Clarify QEMU_CAPS_KVM
  qemu: Don't check for /dev/kvm presence

 src/qemu/qemu_capabilities.c                  |  27 +---
 src/qemu/qemu_capabilities.h                  |   4 +-
 tests/qemucapabilitiestest.c                  |   1 +
 tests/qemucaps2xmldata/all_1.6.0-1.caps       | 129 ------------------
 .../nodisksnapshot_1.6.0-1.caps               | 128 -----------------
 .../caps_1.5.3.x86_64.xml}                    |  12 +-
 .../caps_1.6.0.x86_64.xml}                    |  14 +-
 .../caps_1.7.0.x86_64.xml}                    |  12 +-
 .../caps_2.1.1.x86_64.xml}                    |  12 +-
 .../caps_2.10.0.aarch64.xml}                  |  13 +-
 .../caps_2.10.0.ppc64.xml}                    |  14 +-
 .../caps_2.10.0.s390x.xml}                    |  14 +-
 .../caps_2.10.0.x86_64.xml}                   |  12 +-
 .../caps_2.11.0.s390x.xml}                    |  14 +-
 .../caps_2.11.0.x86_64.xml}                   |  12 +-
 .../caps_2.12.0.aarch64.xml}                  |  13 +-
 .../caps_2.12.0.ppc64.xml}                    |  14 +-
 .../caps_2.12.0.s390x.xml}                    |  14 +-
 .../caps_2.12.0.x86_64.xml}                   |  12 +-
 .../caps_2.4.0.x86_64.xml}                    |  12 +-
 .../caps_2.5.0.x86_64.xml}                    |  12 +-
 .../caps_2.6.0.aarch64.xml}                   |  13 +-
 .../caps_2.6.0.ppc64.xml}                     |  14 +-
 .../caps_2.6.0.x86_64.xml}                    |  12 +-
 .../caps_2.7.0.s390x.xml}                     |  14 +-
 .../caps_2.7.0.x86_64.xml}                    |  12 +-
 .../caps_2.8.0.s390x.xml}                     |  14 +-
 .../caps_2.8.0.x86_64.xml}                    |  12 +-
 .../caps_2.9.0.ppc64.xml}                     |  14 +-
 .../caps_2.9.0.s390x.xml}                     |  14 +-
 .../caps_2.9.0.x86_64.xml}                    |  12 +-
 .../caps_3.0.0.ppc64.xml}                     |  14 +-
 .../caps_3.0.0.riscv32.xml}                   |  13 +-
 .../caps_3.0.0.riscv64.xml                    |  25 ++++
 .../caps_3.0.0.x86_64.xml}                    |  12 +-
 tests/qemucaps2xmltest.c                      |  63 +++++++--
 tests/qemuxml2argvtest.c                      |  11 +-
 37 files changed, 229 insertions(+), 535 deletions(-)
 delete mode 100644 tests/qemucaps2xmldata/all_1.6.0-1.caps
 delete mode 100644 tests/qemucaps2xmldata/nodisksnapshot_1.6.0-1.caps
 copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_1.5.3.x86_64.xml} (67%)
 rename tests/{qemucaps2xmldata/nodisksnapshot_1.6.0-1.xml => qemucaps2xmloutdata/caps_1.6.0.x86_64.xml} (60%)
 copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_1.7.0.x86_64.xml} (67%)
 copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.1.1.x86_64.xml} (67%)
 copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.10.0.aarch64.xml} (62%)
 copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.10.0.ppc64.xml} (56%)
 copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.10.0.s390x.xml} (56%)
 copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.10.0.x86_64.xml} (67%)
 copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.11.0.s390x.xml} (56%)
 copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.11.0.x86_64.xml} (67%)
 copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.12.0.aarch64.xml} (62%)
 copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.12.0.ppc64.xml} (56%)
 copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.12.0.s390x.xml} (56%)
 copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.12.0.x86_64.xml} (67%)
 copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.4.0.x86_64.xml} (67%)
 copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.5.0.x86_64.xml} (67%)
 copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.6.0.aarch64.xml} (62%)
 copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.6.0.ppc64.xml} (56%)
 copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.6.0.x86_64.xml} (67%)
 copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.7.0.s390x.xml} (56%)
 copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.7.0.x86_64.xml} (67%)
 copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.8.0.s390x.xml} (56%)
 copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.8.0.x86_64.xml} (67%)
 copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.9.0.ppc64.xml} (56%)
 copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.9.0.s390x.xml} (56%)
 copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_2.9.0.x86_64.xml} (67%)
 copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_3.0.0.ppc64.xml} (56%)
 copy tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_3.0.0.riscv32.xml} (54%)
 create mode 100644 tests/qemucaps2xmloutdata/caps_3.0.0.riscv64.xml
 rename tests/{qemucaps2xmldata/all_1.6.0-1.xml => qemucaps2xmloutdata/caps_3.0.0.x86_64.xml} (67%)

-- 
2.17.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/5] qemu: Detect KVM usability correctly
Posted by Jiri Denemark 5 years, 6 months ago
On Fri, Sep 14, 2018 at 10:35:58 +0200, Andrea Bolognani wrote:
> There are a few cases in which we're not reporting the correct
> information through 'virsh capabilities', leading to applications
> such as libguestfs attempting to launch KVM guests on a host that
> doesn't actually support them.
> 
> Our code is also more complicated than it needs to be due to
> backwards compatibilty reasons that we no longer care about these
> days, so we can perform some cleanup there; there are further
> cleanup opportunities in the same area, but some of them are a
> bit tricky so I'll leave them for a follow-up series.
> 
> We also get some extra test coverage pretty much for free. Yay!

So this makes things cleaner and fixes KVM reporting in capabilities.

But we also check /dev/kvm in virQEMUCapsIsValid. Which means we may
reprobe QEMU everytime in case the kvm module is not loaded (but
/dev/kvm exists) and we will never catch the case when kvm module was
loaded originally, but the admin unloads it while libvirtd is running.
Although this series doesn't make it any worse.

>   qemu: Drop QEMU_CAPS_ENABLE_KVM

After removing this capability it looks like virQEMUCapsIsValid will
always invalidate every single non-native QEMU binary since kvm could
not clearly be used when probing and /dev/kvm is present. Shouldn't we
add a check which makes sure we don't go this far for non-native
binaries?

Jirka

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/5] qemu: Detect KVM usability correctly
Posted by Andrea Bolognani 5 years, 6 months ago
On Fri, 2018-09-14 at 15:01 +0200, Jiri Denemark wrote:
> On Fri, Sep 14, 2018 at 10:35:58 +0200, Andrea Bolognani wrote:
> > There are a few cases in which we're not reporting the correct
> > information through 'virsh capabilities', leading to applications
> > such as libguestfs attempting to launch KVM guests on a host that
> > doesn't actually support them.
> > 
> > Our code is also more complicated than it needs to be due to
> > backwards compatibilty reasons that we no longer care about these
> > days, so we can perform some cleanup there; there are further
> > cleanup opportunities in the same area, but some of them are a
> > bit tricky so I'll leave them for a follow-up series.
> > 
> > We also get some extra test coverage pretty much for free. Yay!
> 
> So this makes things cleaner and fixes KVM reporting in capabilities.
> 
> But we also check /dev/kvm in virQEMUCapsIsValid. Which means we may
> reprobe QEMU everytime in case the kvm module is not loaded (but
> /dev/kvm exists)

We can try poking harder at /dev/kvm, eg. open() it, run some
ioctl()s on it or whatever is necessary to figure out whether the
device is actually functional rather than just showing up.

However, that would mean duplicating some work that QEMU can
already do for us, so I'm not too fond of it. It also feels a bit
too ad-hoc.

How ridiculous would it be to invalidate capabilities whenever
the daemon is restarted? That might strike a somewhat reasonable
balance between requiring the admin to delete a bunch of internal
files after configuring the system to load the KVM module and
re-probing QEMU all the time.

> and we will never catch the case when kvm module was
> loaded originally, but the admin unloads it while libvirtd is running.
> Although this series doesn't make it any worse.

Is there a concrete use case for that? It doesn't look like a
situation that we should really concern ourselves with.

> >   qemu: Drop QEMU_CAPS_ENABLE_KVM
> 
> After removing this capability it looks like virQEMUCapsIsValid will
> always invalidate every single non-native QEMU binary since kvm could
> not clearly be used when probing and /dev/kvm is present. Shouldn't we
> add a check which makes sure we don't go this far for non-native
> binaries?

We can use virQEMUCapsGuestIsNative() and skip all KVM-related
checks for non-native binaries. Does that sound okay?

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/5] qemu: Detect KVM usability correctly
Posted by Jiri Denemark 5 years, 6 months ago
On Fri, Sep 14, 2018 at 15:36:42 +0200, Andrea Bolognani wrote:
> On Fri, 2018-09-14 at 15:01 +0200, Jiri Denemark wrote:
> > On Fri, Sep 14, 2018 at 10:35:58 +0200, Andrea Bolognani wrote:
> > > There are a few cases in which we're not reporting the correct
> > > information through 'virsh capabilities', leading to applications
> > > such as libguestfs attempting to launch KVM guests on a host that
> > > doesn't actually support them.
> > > 
> > > Our code is also more complicated than it needs to be due to
> > > backwards compatibilty reasons that we no longer care about these
> > > days, so we can perform some cleanup there; there are further
> > > cleanup opportunities in the same area, but some of them are a
> > > bit tricky so I'll leave them for a follow-up series.
> > > 
> > > We also get some extra test coverage pretty much for free. Yay!
> > 
> > So this makes things cleaner and fixes KVM reporting in capabilities.
> > 
> > But we also check /dev/kvm in virQEMUCapsIsValid. Which means we may
> > reprobe QEMU everytime in case the kvm module is not loaded (but
> > /dev/kvm exists)
> 
> We can try poking harder at /dev/kvm, eg. open() it, run some
> ioctl()s on it or whatever is necessary to figure out whether the
> device is actually functional rather than just showing up.
> 
> However, that would mean duplicating some work that QEMU can
> already do for us, so I'm not too fond of it. It also feels a bit
> too ad-hoc.

I don't know. I think we can keep the code as is for now since this
series does not make it any worse :-)

> How ridiculous would it be to invalidate capabilities whenever
> the daemon is restarted? That might strike a somewhat reasonable
> balance between requiring the admin to delete a bunch of internal
> files after configuring the system to load the KVM module and
> re-probing QEMU all the time.

This would effectively revert the addition of on-disk cache, which was
introduced with a very good reason. Starting libvirtd with a lot of QEMU
binaries would take a very long time without the persistent cache. Also
libguestfs running libvirt in session mode would get crazy about it. In
other words, invalidating capabilities cache whenever libvirtd is
started is not acceptable.

> > and we will never catch the case when kvm module was
> > loaded originally, but the admin unloads it while libvirtd is running.
> > Although this series doesn't make it any worse.
> 
> Is there a concrete use case for that? It doesn't look like a
> situation that we should really concern ourselves with.
> 
> > >   qemu: Drop QEMU_CAPS_ENABLE_KVM
> > 
> > After removing this capability it looks like virQEMUCapsIsValid will
> > always invalidate every single non-native QEMU binary since kvm could
> > not clearly be used when probing and /dev/kvm is present. Shouldn't we
> > add a check which makes sure we don't go this far for non-native
> > binaries?
> 
> We can use virQEMUCapsGuestIsNative() and skip all KVM-related
> checks for non-native binaries. Does that sound okay?

Yeah, I think that should work.

Jirka

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/5] qemu: Detect KVM usability correctly
Posted by Andrea Bolognani 5 years, 6 months ago
On Fri, 2018-09-14 at 16:35 +0200, Jiri Denemark wrote:
> On Fri, Sep 14, 2018 at 15:36:42 +0200, Andrea Bolognani wrote:
> > How ridiculous would it be to invalidate capabilities whenever
> > the daemon is restarted? That might strike a somewhat reasonable
> > balance between requiring the admin to delete a bunch of internal
> > files after configuring the system to load the KVM module and
> > re-probing QEMU all the time.
> 
> This would effectively revert the addition of on-disk cache, which was
> introduced with a very good reason. Starting libvirtd with a lot of QEMU
> binaries would take a very long time without the persistent cache. Also
> libguestfs running libvirt in session mode would get crazy about it. In
> other words, invalidating capabilities cache whenever libvirtd is
> started is not acceptable.

Fair enough!

[...]
> > > After removing this capability it looks like virQEMUCapsIsValid will
> > > always invalidate every single non-native QEMU binary since kvm could
> > > not clearly be used when probing and /dev/kvm is present. Shouldn't we
> > > add a check which makes sure we don't go this far for non-native
> > > binaries?
> > 
> > We can use virQEMUCapsGuestIsNative() and skip all KVM-related
> > checks for non-native binaries. Does that sound okay?
> 
> Yeah, I think that should work.

I just posted a 6/5 that does just that.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list