[libvirt] [PATCH] Expose SLIRP attributes

[Michal Privoznik]

On 28.03.2014 09:33, Laine Stump wrote:
> On 03/27/2014 07:17 PM, Michal Privoznik wrote:
>> We allow users to use SLIRP stack. However, there are some knobs
>> which are not exposed to users, such as host network address, DNS
>> server, smb, and others.
>>
>> Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
>> ---
>>   docs/formatdomain.html.in                          |  7 +-
>>   docs/schemas/domaincommon.rng                      | 23 +++++-
>>   src/conf/domain_conf.c                             | 88 ++++++++++++++++++++++
>>   src/conf/domain_conf.h                             |  6 ++
>>   src/qemu/qemu_command.c                            | 19 +++++
>>   .../qemuxml2argvdata/qemuxml2argv-net-user-ip.args |  7 ++
>>   .../qemuxml2argvdata/qemuxml2argv-net-user-ip.xml  | 33 ++++++++
>>   tests/qemuxml2argvtest.c                           |  1 +
>>   8 files changed, 180 insertions(+), 4 deletions(-)
>>   create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-net-user-ip.args
>>   create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-net-user-ip.xml
>
> It is essential that this new <ip> element be rejected, preferably at
> parse time in the qemu-specific post-parse callback, for any interface
> type that doesn't support it. Since it is the most obvious way of
> specifying an IP address for a guest (and it is a way that has been
> requested in the past) we are otherwise certain to have a lot of support
> questions asking why the IP address setting isn't being used.

Well, I think rejecting it goes against current policy 'silently ignore 
elements unknown to the libvirt'. But I can live with that here.

>
> Also, the attribute names seem confusing. The "address" attribute is the
> address of the *network*, not of the interface, and "dhcpstart" is the
> address of the interface. Even though qemu specifies the network address
> and interface address separately, the network address is really
> pointless, as it can/should be derived from the interface address.

It is, so what XML schema do you propose? I'm not pleased with <ip/> 
either. But it was the best I could come up with so far. Maybe we are 
aiming for more structured XML here:

   <interface type='user'>
     <network address='192.168.2.0' prefix='24'/>
     <dns address='92.168.2.3'/>
     <dhcp start='192.168.2.9'/>
     <mac address='00:11:22:33:44:55'/>
     <model type='rtl8139'/>
   </interface>

Or even more neting:

   <interface type='user'>
     <network>
       <ip address='192.168.2.0' prefix='24'/>
       <dns address='92.168.2.3'/>
       <dhcp start='192.168.2.9'/>
     </network>
     <mac address='00:11:22:33:44:55'/>
     <model type='rtl8139'/>
   </interface>


>
> (I realize that "dhcpstart" isn't *exactly* the interface IP, since qemu
> allows for multiple IP leases to be acquired from it's internal dhcp
> server, but I think that usage is very rare, and unlikely to be possible
> for any other backend we might support).
>
> Beyond that, a question not with your patch, but with qemu's
> implemenation - does it always assume that the gateway address is
> $network.1 ?  If that's the case, then I think definitely we should just
> have <ip address='x' prefix='y'/>. If there is support for specifying
> the gateway address, then it should be named "gateway", as is already
> done in the network xml for static routes.

That's good question, but my qemu code base reading skills are just too 
weak to answer it.

Michal