cloud image network config, virtio-net, libvirt autodetection, and network vs NetworkManager, F20 vs F21
TL;DR:
KB, I think the CentOS cloud images should use: https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?h=f21&id=9...
Dennis, we should revert: https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?h=f21&id=5...
Longer story:
I tried the CentOS 7 GenericCloud image: http://cloud.centos.org/centos/7/devel/ and it didn't have networking on boot. Let's look at the actors:
- A base cloud image: Fedora 20, Fedora 21, CentOS 7 - Network configuration: As specified in the kickstart - A network driver: virtio-net, rtl8139 - virt-install guest autodetection: Determines whether or not you get virtio-net - network system (or NetworkManager, or systemd-networkd) - systemd: http://lists.freedesktop.org/archives/systemd-devel/2014-July/020906.html - Anaconda/kickstart behavior
First, let's look at the current F20: https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-cloud-base...
It hardcodes eth0. And the version of systemd there uses eth0 for virtio-net.
Now, let's look at some changes Dennis committed in the F21 cycle:
ens3: https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?h=f21&id=e...
link: https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?h=f21&id=9...
eth0 (but only for atomic): https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?h=f21&id=5...
(Dennis and others, can you send patches to the list for review? This issue would have been more obvious if I'd noticed the changes going by)
A really critical variable here is whether or not libvirt guest autodetection works. Currently:
libvirt automatically provides virtio-net: Fedora 20, Fedora 21 Generic libvirt gives you rtl8193: Fedora 21 Atomic, CentOS 7
It took me a while to figure out here that the reason the CentOS 7 image wasn't working was becuase of the libvirt autodetection.
I have this utterly trivial "create-cloud-vm.sh" script I've been using:
https://gist.github.com/cgwalters/a366c14b2fc58e0f7367
It does work if I specify --os-variant rhel7 for CentOS7. Which I'm now going to start doing by default in my script (I don't use it to boot anything else).
But...the change to do DHCP on all links by default is also an important change. One we should highlight in the release notes.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sun, 23 Nov 2014 10:57:51 -0500 Colin Walters walters@verbum.org wrote:
TL;DR:
KB, I think the CentOS cloud images should use: https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?h=f21&id=9...
Dennis, we should revert: https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?h=f21&id=5...
I do not remember the exact details but link was not working for some reason. we can change rawhide but should not change f21 at this point.
Longer story:
I tried the CentOS 7 GenericCloud image: http://cloud.centos.org/centos/7/devel/ and it didn't have networking on boot. Let's look at the actors:
- A base cloud image: Fedora 20, Fedora 21, CentOS 7
- Network configuration: As specified in the kickstart
- A network driver: virtio-net, rtl8139
- virt-install guest autodetection: Determines whether or not you
get virtio-net
- network system (or NetworkManager, or systemd-networkd)
- systemd:
http://lists.freedesktop.org/archives/systemd-devel/2014-July/020906.html
- Anaconda/kickstart behavior
First, let's look at the current F20: https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-cloud-base...
It hardcodes eth0. And the version of systemd there uses eth0 for virtio-net.
Now, let's look at some changes Dennis committed in the F21 cycle:
ens3: https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?h=f21&id=e...
link: https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?h=f21&id=9...
eth0 (but only for atomic): https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?h=f21&id=5...
These were committed because things kept changing in the guests. it was all break fix. which is the only time I touch the non arm kickstarts. Sending patches slows down the testing process and is not tenable. you should watch the commits on spin-kickstarts list where all commits are sent if you care to follow the changes.
(Dennis and others, can you send patches to the list for review? This issue would have been more obvious if I'd noticed the changes going by)
A really critical variable here is whether or not libvirt guest autodetection works. Currently:
libvirt automatically provides virtio-net: Fedora 20, Fedora 21 Generic libvirt gives you rtl8193: Fedora 21 Atomic, CentOS 7
It took me a while to figure out here that the reason the CentOS 7 image wasn't working was becuase of the libvirt autodetection.
the network autodetection is broken and systemd's predictable naming actually makes it unpredicatable in the cloud/vm use cases.we probably should explicitly turn it off in the boot arguments.
I have this utterly trivial "create-cloud-vm.sh" script I've been using:
https://gist.github.com/cgwalters/a366c14b2fc58e0f7367
It does work if I specify --os-variant rhel7 for CentOS7. Which I'm now going to start doing by default in my script (I don't use it to boot anything else).
But...the change to do DHCP on all links by default is also an important change. One we should highlight in the release notes. _______________________________________________ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sun, 23 Nov 2014 17:42:52 -0600 Dennis Gilmore dennis@ausil.us wrote:
<snip>
the network autodetection is broken and systemd's predictable naming actually makes it unpredicatable in the cloud/vm use cases.we probably should explicitly turn it off in the boot arguments.
To give a little more detail of what actually happens here and to try and illustrate why systemd's predictabvle naming is broken for the use cases we are looking at.
the link argument tells anaconda to configure the device with a link. it only works when you have a single nic with a link. The device name used in the install environment is what is hardcoded into the config files of the installed image. anaconda makes a big assumption that the environment that is used when installing is the same environment that the system will be ran in. during f21 naming was bouncing backwards and forwards between ens3 and eth0 but depending on what was in use when the system was installed effected what was in use in the cloud image.
the outcome is that unless we turn off predictable naming it could randomly change under us and not work. if we turn off predictable naming we should always get eth0 and things should work. there is always a chance something goes wrong and no networking. to deal with that NetworkManager probably needs changing.
Dennis
-
Colin Walters -
Dennis Gilmore