Libguestfs - Feb 2018 - Problems with Fedora 27 image used by virt-builder

During this last week I fired up some tests using libvirt-tck that
haven't been run in awhile and ran into a couple problems with the
Fedora 27 image provided by virt-builder (which is used by the
libvirt-tck tests). One of them probably has a simple solution, I'm not
sure about the other.

1) there is an selinux labeling error with the versions of packages in
the Fedora 27 image. There are several (mostly related to iptables and
ebtables), but one in particular prevents dhcp from getting an IP address:

  audit[509]: AVC avc:  denied  { read } for pid=509
  comm="dhclient" name="ld.so.cache" dev="vda4"
ino=4513574
  scontext=system_u:system_r:dhcpc_t:s0
  tcontext=system_u:object_r:unlabeled_t:s0
  tclass=file permissive=0

I'm guessing that redoing the OS install of the image with updates
enabled will fix this (and most/all of the other AVCs)

2) The virt-builder images are created using

    virt-install ..... --nographic

which means that no video device is present during the OS install.
Because of this, the ethernet device is placed at slot 2, so it is named
"ens2" by the kernel, and anaconda creates config for
"ens2". But if the
image is later booted with a different config that has a graphics
device, the graphics device will be put at slot 2 and the ethernet will
be put on slot 3, so it will be named ens3.

This ends up providing the expected behavior, since the image has
NetworkManager enabled, and by default NetworkManager will enable all
interfaces it finds with an "in-memory" config for dhcp. But it does
mean that if someone decides to change the config to have a static IP,
they'll be surprised when just modifying the existing ifcfg file doesn't
have any effect. Also, if someone disables NetworkManager.service in the
image and enables network.service instead, the config will be incorrect.
(On the other hand, if they're doing something like this, they're
already messing around with files in the image, so I suppose they could
be expected to correct the inconsistency themselves.

It may be too late to change this, but in hindsight it may have been
good to add "net.ifnames=0 biosdevname=0" to the kickstart file and
grub
config so that the network device is always named eth0 regardless of PCI
addressing. (I remember this previously being the case for virtio
devices in Fedora; no idea when it changed).