[libvirt] [PATCH] Expose SLIRP attributes
Laine Stump
laine at laine.org
Fri Mar 28 12:02:21 UTC 2014
On 03/28/2014 12:34 PM, Michal Privoznik wrote:
> 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.
It's no longer unknown :-)
>
>>
>> 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>
Interesting idea - a mini <network> inside the <interface>. If we were
going to go this far, it should be in order to replicate the schema of
<network> as much as possible though. Otherwise it could lead to confusion.
For that reason, I think just a single <ip> element is fine, I just
think the attribute names should follow function rather than following
qemu (see my response to Rich). This will make it more likely that we
can add support for <ip> on some other network type in the future. (For
example, I could see us possibly adding the capability to use the <ip>
inside an interface to automatically populate the static IP list of a
libvirt network's dnsmasq instance before the domain is started, then
removing it once the domain is stopped - it would really only be
interested in the guest IP address, but would fail if any other info was
present and didn't match the network's config).
More information about the libvir-list
mailing list