Re: runqemu + dhcp server

[Adrian Freihofer <adrian.freihofer@neratec.com>]

[-- Attachment #1: Type: text/plain, Size: 2480 bytes --]

On Friday 07 November 2014 10.12:02 Patrick Ohly wrote:
> Adrian Freihofer <adrian.freihofer@...> writes:
> > Personally I would prefer a slightly different implementation.
> > I consider the 192.168.7.2 network interface as development, debugging
> > and testing interface which should just work.
> 
> Agreed, and it doesn't work at the moment when the image has an Ethernet
> configuration mechanism that wasn't adapted to use the ip kernel parameter. 
> What you are proposing goes beyond just fixing that. I don't have any strong
> opinion about the right way forward.
> 
> > By the way, where does your solution make use of the DHCP server?
> 
> When Connman starts up, it finds eth0 and obtains an IP address for it via
> DHCP. Without the DHCP server, the guest ends up without an IP address. I
> have not checked if the ip parameter was ever used.
> 
> Note that this is what the default Tizen Connman config does, not what Poky
> would do when building and installing Connman. The whole point was the
> ability to use production images without special tweaks. 
> 
> > The 
> > eth0 IP configuration is assigned by kernel boot parameters in
> > runqemu-internal. If this configuration gets changed later on the NFS 
> > rootfs will break...
> 
> I haven't tried NFS rootfs. My hope is that it would still work because the
> ip parameter and the DHCP server assign the same IP address and thus nothing
> changes inside the guest when switching from one to the other.
> 
I see, the patch you are working on will provide just another option to get eth0 configured. This would definitely be an improvement.
Did you ever run the automated image tests? If I remember correctly the image tests are somehow related to the current implementation of the network configuration. At least the tests require a hostname starting with "qemu" and probably they run from NFS rootfs.
Would be nice, if you get the DHCP based network configuration fulfilling these requirements. An alternative approach is implemented in systemd networkd. I guess it does not touch interfaces which are already configured e.g. by kernel boot parameters. This could be done in connman as well. It would allow you to run the productive image in qemu.-- 

--------------------
Neratec Solutions AG
Postfach 83, CH-8608 Bubikon, Switzerland

adrian.freihofer@neratec.com
Direct: +41 55 253 2083
Office: +41 55 253 2000
www.neratec.com[1]

--------
[1] www.neratec.com

[-- Attachment #2: Type: text/html, Size: 8790 bytes --]