Description of problem: The documentation for sandbox networking: http://sandbox.libvirt.org/networking/ says that if I specify -N dhcp,source=<virtual_network> that dhclient would be started in the container to acquire and setup the network. This does not currently work. If I specify -N \ source=net1,address=192.168.1.90/24,route=192.168.1.255%192.168.1.1 and "net1" is defined as a virtual (nat) network or a bridge to a host network which has dnsmasq running for dhcp & dns, the static specification works but the dhcp does not. Version-Release number of selected component (if applicable): Fedora 20 + fedora-virt-preview with libvirt-sandbox-0.5.1-4.fc20.x86_64 How reproducible: everytime Steps to Reproduce: 1. create a secure container with -N dhcp,... 2. after starting it, connect and do "ip addr" 3. repeat with -N address=... Actual results: no IP when dhcp specify; Ip assigned and started with static address Expected results: IP address assigned and started with both Additional info:
OK, I believe I have tracked down the problem ... not a fix but the problem anyway. In libvirt-sandbox-init-common.c, the start_dhcp() function dot not work! That is, it is not starting dhclient for a dhcp network device. I was wondering why there was no dhclient running for the dhcp NIC but ?? I tried starting my own copy after doing a connect with: /sbin/dhclient --no-pid eth1 & Slam, bang, I suddenly had a dhcp IP address on interface eth1!!! This is not a fix. Now I need to look into g_spawn_async().
After a lot more "instrumenting" and testing I believe I have a potential fix. I finally tried replacing the g_spawn_async() in start_dhcp() with g_spawn_sync() and (suddenly) dhcp works! I created /usr/sbin/dhclient.sh which I then invoked the real /usr/sbin/dhclient. When g_spawn_async() was used, the actual program did not start. But, replacing it with g_spawn_sync() worked. Now let's see if I can create a simple patch to fix things.
Created attachment 936277 [details] bugfix for starting dhclient
Created attachment 936278 [details] get more info about dhclient starting
I've just pushed the patches upstream: commit bf2bb41091cf8271af1c1790001858d58e5f49c8 Author: Gene Czarcinski <gczarcinski.com> AuthorDate: Fri Oct 31 14:02:53 2014 -0400 Commit: Michal Privoznik <mprivozn> CommitDate: Wed Nov 5 11:51:51 2014 +0100 v1.1 add -v to dhclient parameter arguments This patch improves the ability to understand what is happening with dchlient and is obviously optional. commit 25590372c87bce1b91bce7ba701f32efd79df9dc Author: Gene Czarcinski <gczarcinski.com> AuthorDate: Fri Oct 31 14:02:52 2014 -0400 Commit: Michal Privoznik <mprivozn> CommitDate: Wed Nov 5 11:51:43 2014 +0100 v1.1 for dhclient use g_spawn_sync() This patch addresses problem RHBZ #1133686. For some (unknown to me) reason, g_spawn_async() is not starting dhclient so that a dhcp NIC can be configured. However, simply using g_spawn_sync() works. This was the only use of g_spawn_async(). Note: There is no problem using sync instead of async since dhclient will disconnect and put itself in the background once the network is started. v0.5.1-15-gbf2bb41
Any idea as to when an updated libvirt-sandbox will be issued? The last update was over a year ago.
libvirt-glib-0.2.1-1.fc22, libvirt-sandbox-0.6.0-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/libvirt-glib-0.2.1-1.fc22,libvirt-sandbox-0.6.0-1.fc22
Package libvirt-glib-0.2.1-1.fc22, libvirt-sandbox-0.6.0-1.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libvirt-glib-0.2.1-1.fc22 libvirt-sandbox-0.6.0-1.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-11131/libvirt-glib-0.2.1-1.fc22,libvirt-sandbox-0.6.0-1.fc22 then log in and leave karma (feedback).
libvirt-glib-0.2.1-1.fc22, libvirt-sandbox-0.6.0-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.