Re: [PATCH] Expose SLIRP attributes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx>
---
  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

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]