Re: runqemu + dhcp server

[Patrick Ohly <patrick.ohly@intel.com>]

On Wed, 2014-11-05 at 16:29 +0000, Burton, Ross wrote:

> On 4 November 2014 08:09, Patrick Ohly <patrick.ohly@intel.com> wrote:
>         Recently I built a custom image which depended on a DHCP
>         server to
>         configure Ethernet. runqemu with tap for networking doesn't
>         provide one
>         at the moment, so ssh logins did not work.
>         
>         Instead of customizing images for runqemu, I think it would be
>         better to
>         adapt runqemu and uses images as on the target device.
>         Attached two
>         patches which work for me. Is that of interest for inclusion
>         upstream?
>         
> 
> 
> I've long been of the opinion that runqemu needs the ability to setup
> a DHCP/DNS server for the guest, as whilst you can special-case qemu
> machines and hard-code the relevant network configuration it doesn't
> help with testing.  That said, I'm not convinced that dhcpd+bind is
> the right way forward, something like dnsmasq (currently in
> meta-networking) might be quicker to build and more flexible in this
> environment.

I was looking for a solution that works inside the Poky repository,
without external dependencies, and thus only depends on oe-core. Are you
suggesting that dnsmasq should be moved into oe-core?

What extra flexibility would you like see provided on the host side? All
I needed was the DHCP server, so bind+dhcpd fit the bill for me.
Compilation speed didn't seem like a big deal.

Handing DNS settings to the DHCP client is missing in the patch, but
could be added also when using bind+dhcpd. It's a bit harder to do in
the general case than with dnsmasq, because runqemu-internal somehow
needs to determine where it can find a DNS server in order to configure
dhcpd, whereas dnsmasq itself could act as DNS proxy.

When using dhcpd, would hard-coding a well-known one like Google's
8.8.8.8 as default with an explicit override via env variable be
acceptable?

Either way, what would be the right way to integrate this from a user
perspective? Should running the DHCP server (whichever one it is) be
done by default? Always or should there be an option to turn it on or
off? How?

>         I suppose more work is needed, in particular around how to
>         enable or
>         disable this feature. Patching the .bb files also leads to a
>         (to me)
>         strange QA error. See the comments in the patches for details.
> 
> This is likely due to bind using PACKAGES_prepend instead of PACKAGES
> =+ (=+ is prepend), which messes up the native.bbclass magic.

That's right, replacing _prepend with =+ fixed the problem.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.