[conspire] Yummy, yummy, virtual within virtual! :-)

[Michael Paoli]

Now, more typically I'd do:
$ sudo virsh start name_of_VM --console
But instead here I'm skipping all the console boot stuff
that would otherwise be seen on the serial console (I also
have the "quiet" option *not* present on the kernel options/arguments).

$ sudo virsh start host1; sleep 30; sudo virsh console host1; sudo  
virsh list --all
Domain host1 started

Connected to domain host1
Escape character is ^]

Debian GNU/Linux 9 debian ttyS0

debian login: root
Password:
Last login: Mon Jun  3 06:32:36 UTC 2019 on ttyS0
Linux debian 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u2 (2019-05-13) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root at debian:~#

virsh list --all
  Id    Name                           State
----------------------------------------------------
  -     swvirtonly                     shut off

root at debian:~# virsh start swvirtonly; sleep 30; virsh console  
swvirtonly; virsh list --all
Connected to domain swvirtonly
Escape character is ^]
... [lots 'o serial console output - should've allowed more than
... 30 seconds - virtual *without* hardware virtualization support
... is significantly slower]

Debian GNU/Linux 9 debian ttyS0

debian login: root
Password:
Last login: Mon Jun  3 14:14:20 UTC 2019 on ttyS0
Linux debian 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u2 (2019-05-13) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root at debian:~#

And, yes, I do have a (testing) use case.
I want to test some mucking about with the virtualization software
itself ... but at least first without doing it on physical host,
and see if I'm able to make the changes I want ... before doing
it "for real" on the production physical hosts.
If all appears well in (my) testing, then I'd next do
physical that doesn't have VMs running on it,
the move VMs to there, make sure they still run okay,
then same changes to VM software on the other nominally
primary physical host - while no VMs are running there ...
then move the VMs back to the nominal primary.
And also ... test in VM first?  Yes, the changes may be
hazardous/difficult to back out of on the physical.
On the virtual(s) dang easy - can always copy the full
data and metadata first (disk image and virtual machine
configuration data).