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@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).