[libvirt] [PATCH v2] network: add 'bootp' and 'tftp' config

2009-09-15 Thread Paolo Bonzini
Currently, libvirtd will start a dnsmasq process for the virtual
network, but (aside from killing the dnsmasq process and replacing it),
there's no way to define tftp boot options.

This change introduces the appropriate tags to the dhcp configuration:

 network
   namedefault/name
   bridge name=virbr%d /
   forward/
   ip address=192.168.122.1 netmask=255.255.255.0
 tftp root=/var/lib/tftproot /
 dhcp
   range start=192.168.122.2 end=192.168.122.254 /
   bootp file=pxeboot.img/
 /dhcp
   /ip
 /network

When the attributes are present, these are passed to the
arguments to dnsmasq:

 dnsmasq [...] --enable-tftp --tftp-root /srv/tftp --dhcp-boot pxeboot.img
   ^^^ ^^^
  from tftp / from bootp /


Possible future features in this field include the following:

- At present, only local tftp servers are supported (ie, dnsmasq runs as
the tftp server), but we could improve this in future by adding a
server= attribute to bootp.

- Currently, the BOOTP file cannot be assigned to a specific range or
host.  Even if this was implemented, it would still make sense to
allow bootp appearing directly within the dhcp element, providing
a global default.

Signed-off-by: Jeremy Kerr j...@ozlabs.org
Signed-off-by: Paolo Bonzini pbonz...@redhat.com

2009-09-15  Paolo Bonzini  pbonz...@redhat.com
Jeremy Kerr  j...@ozlabs.org

* docs/formatnetwork.html.in: Document new tags.
* docs/formatnetwork.html: Regenerate.
* docs/schemas/network.rng: Update.
* src/network_conf.c (virNetworkDefFree): Free new fields.
(virNetworkDHCPRangeDefParseXML): Parse bootp.
(virNetworkIPParseXML): New, parsing dhcp and tftp.
(virNetworkDefParseXML): Use virNetworkIPParseXML instead of
virNetworkDHCPRangeDefParseXML.
(virNetworkDefFormat): Pretty print new fields.
* src/network_conf.h (struct _virNetworkDef): Add netboot fields.
* src/network_driver.c (networkBuildDnsmasqArgv): Add
TFTP and BOOTP arguments.

* tests/Makefile.am (EXTRA_DIST): Add networkschemadata.
* tests/networkschematest: Look in networkschemadata.
* tests/networkschemadata/netboot-network.xml: New.
---

Compared to v1, I fixed wrong HTML that was pointed out to me
offline by Jiri Denemark.  Note that make will give errors
for it but will _not_ abort.

 docs/formatnetwork.html |   15 ++-
 docs/formatnetwork.html.in  |   17 ++--
 docs/schemas/network.rng|   10 
 src/network_conf.c  |   60 +-
 src/network_conf.h  |3 +
 src/network_driver.c|   14 ++
 tests/Makefile.am   |1 +
 tests/networkschemadata/netboot-network.xml |   12 +
 tests/networkschematest |2 +-
 9 files changed, 124 insertions(+), 10 deletions(-)
 create mode 100644 tests/networkschemadata/netboot-network.xml

diff --git a/docs/formatnetwork.html b/docs/formatnetwork.html
index 845e558..e97b9be 100644
--- a/docs/formatnetwork.html
+++ b/docs/formatnetwork.html
@@ -235,7 +235,13 @@
address will be their default route. The codenetmask/code
attribute defines the significant bits of the network address,
again specified in dotted-decimal format.  span class=sinceSince 
0.3.0/span
-  /dddtcodedhcp/code/dtddImmediately within the 
codeip/code element there is an
+  /dddtcodetftp/code/dtddImmediately within
+   the codeip/code element there is an optional codetftp/code
+   element. The presence of this element and of its attribute
+   coderoot/code enables TFTP services.  The attribute specifies
+   the path to the root directory served via TFTP.
+   span class=sinceSince 0.7.1/span
+  /dddtcodedhcp/code/dtddAlso within the codeip/code 
element there is an
optional codedhcp/code element. The presence of this element
enables DHCP services on the virtual network. It will further
contain one or more coderange/code elements.
@@ -253,7 +259,12 @@
 assigned to that host (via the codeip/code attribute), and the
name to be given that host by the DHCP server (via the
 codename/code attribute).  span class=sinceSince 0.4.5/span
-  /dd/dl
+  /dddtcodebootp/code/dtddThe optional codebootp/code
+   element specifies BOOTP options to be provided by the DHCP server.
+   Only one attribute is supported, codefile/code, giving the file
+   to be used for the boot image).  The BOOTP options currently have to
+   be the same for all address ranges and statically assigned 
addresses.span class=sinceSince 0.7.1./span
+/dd/dl
 h2
   a name=examples id=examplesExample configuration/a
 /h2
diff --git 

Re: [libvirt] [PATCH v2] network: add 'bootp' and 'tftp' config

2009-09-15 Thread Paolo Bonzini

On 09/15/2009 11:43 AM, Daniel P. Berrange wrote:

I think we possibly ought to movetftp  one level higher up, outside
of theip  tag, since you can have a TFTP server regardless of whether
we've configured IP/dhcp details, and in the future we may well have
multipleip  tags.


In principle, the i...@address attribute would be the address to which the 
TFTP server would bind.  So if you have multiple ip tags you would 
also start multiple TFTP servers, each bound to a different address and 
possibly with a different root.


At that point, we may certainly introduce the possibility to specify the 
tftp tag one level up to easily specify a default (just like bootp). 
 However, given the current capabilities of libvirt it seems to me that 
this is the most logical schema.


Paolo

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


Re: [libvirt] [PATCH v2] network: add 'bootp' and 'tftp' config

2009-09-15 Thread Daniel P. Berrange
On Tue, Sep 15, 2009 at 12:09:53PM +0200, Paolo Bonzini wrote:
 On 09/15/2009 11:43 AM, Daniel P. Berrange wrote:
 I think we possibly ought to movetftp  one level higher up, outside
 of theip  tag, since you can have a TFTP server regardless of whether
 we've configured IP/dhcp details, and in the future we may well have
 multipleip  tags.
 
 In principle, the i...@address attribute would be the address to which the 
 TFTP server would bind.  So if you have multiple ip tags you would 
 also start multiple TFTP servers, each bound to a different address and 
 possibly with a different root.

Ah yes, that is a good point. In that case ACK to your 3rd patch

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

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