[libvirt] [libvirt-tck PATCH] TCK.pm: Define libvirt VMs with an RNG device

[Laine Stump]

On Tue, Sep 24, 2019, 6:02 AM Andrea Bolognani <abologna at redhat.com> wrote:

> On Tue, 2019-09-24 at 08:27 +0200, Erik Skultety wrote:
> > On Mon, Sep 23, 2019 at 04:47:06PM -0400, Laine Stump wrote:
> > > On 9/23/19 1:27 PM, Erik Skultety wrote:
> > > > The nwfilter 220-no-ip-spoofing.t test relies on an SSH connection to
> > > > the test VM. However, because the domain definition passed to libvirt
> > > > lacks an RNG device, the SSH server isn't started inside the guest
> > > > (even though that is the default on virt-builder images) and
> therefore:
> > > >
> > > > "ssh: connect to host 192.168.122.227 port 22: Connection refused"
> > >
> > > Strange that this has never happened to me. Is it perhaps because I'm
> using
> > > a very old cached image from virt-builder, and had started it up
> manually at
> > > some time in the past (thus giving it a long enough time to generate
> the
> > > keys, which are now stored away for posterity)?
> >
> > Btw I always thought that the keys are generated during the package
> > installation rather than first execution of the daemon, clearly I was
> wrong.
>
> I'm going to go out on a limb and assume virt-builder templates get
> their keys ripped out explicitly as part of the building process,
> because of course you wouldn't want all guests created from the same
> virt-builder template to share a single set of SSH keys, now would
> you? :)
>

My recollection about sshd was that it did this the first time the service
was started, but of course that me.ory is at least 10 years old, and so is
suspect from the start!

This has started me thinking again about the problem we have with the
creation of the default network at package installation time (I don't have
access to bugzilla right now to reference the BZ, but want to write this
down before I forget - I'm talking about the deal where we decide on the
subnet to use during a postinstall script, and that potentially creates a
conflict if libvirtd is later run in a different network environment than
when it was installed).

Anyway, maybe we should try mimicking what sshd does for it's initial run
(or maybe not, since we need to do our stuff after the host networking has
completely started and settled, but sshd has no such dependency. On the
other hand, sshd does manage to properly delay setting up it's keys until
it is running on the "final destination" system rather than doing it e.g.
when a booting a live image (which will then be used to do a "copy
everything en masse" install to the final destination).


>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20190924/242692eb/attachment-0001.htm>