Bug 580215

Summary: Virtual network <tftp> element does not enable tftp port
Product: [Fedora] Fedora Reporter: Darryl L. Pierce <dpierce>
Component: libvirtAssignee: Alan Pevec <apevec>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 13CC: apevec, berrange, clalance, crobinso, itamar, jforbes, mburns, tross, veillard, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 607294 (view as bug list) Environment:
Last Closed: 2011-06-10 13:50:01 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 607294    

Description Darryl L. Pierce 2010-04-07 13:59:18 EDT
Description of problem:
When creating a virtual network, libvirt starts an instance of dnsmasq. The description for defining a network via xml says that including a tftp tag within the dhcp tag will let the user point that instance of dnsmasq to a different directory for a tftp root. However, when I try to do this the instance of dnsmasq does not allow pxe booting of the ISO image I've contained in the supplied directory.

Version-Release number of selected component (if applicable):

(mcpierce@mcpierce-desktop:Podcast)$ rpm -q libvirt
libvirt-0.7.4-1.fc13.x86_64


How reproducible:
100%

Steps to Reproduce:
1. Use livecd-iso-to-pxeboot to create a tftp root directory for a LiveCD image.
2. Create a virtual interface and tell it to use the created directory as a tftp root.
3. Start a virtual machine and have it boot from the network.
  
Actual results:

The VM never PXE boots since dnsmasq never offers the LiveCD image.

Expected results:

The VM should PXE book the LiveCD image.

Additional info:

The virtual network is defined with the following XML:

<network>
<name>testbr5310</name>
<forward mode='nat' />
<bridge name='testbr5310' stp='on' forwardDelay='0' />
<ip address='192.168.210.1' netmask='255.255.255.0'>
<tftp root='/tmp/tmp.IpID1ZkCQ2' />
</ip>
</network>
Comment 1 Alan Pevec 2010-06-17 06:21:08 EDT
This seems to work with libvirt-0.7.7-4.fc13

nobody   11062     1  0 12:13 ?        S      0:00 /usr/sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file=  --listen-address 192.168.122.1 --except-interface lo --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-lease-max=253 --enable-tftp --tftp-root /var/lib/dnsmasq/tftp --dhcp-boot pxelinux.0


# virsh net-dumpxml default
<network>
  <name>default</name>
  <uuid>d0d1540f-89a2-4b2a-be23-fa74312c9ae8</uuid>
  <forward mode='nat'/>
  <bridge name='virbr0' stp='on' delay='0' />
  <ip address='192.168.122.1' netmask='255.255.255.0'>
    <tftp root='/var/lib/dnsmasq/tftp' />
    <dhcp>
      <range start='192.168.122.2' end='192.168.122.254' />
      <bootp file='pxelinux.0' />
    </dhcp>
  </ip>
</network>

But tftp port 69 is not allowed in the iptables, like ports for dns 53 and bootp 67.

Workaround is to insert it manually, then VM PXE boot worked:
# iptables -I INPUT -i virbr0 -p udp -m udp --dport 69 -j ACCEPT
Comment 2 Alan Pevec 2010-06-20 17:42:39 EDT
Patch posted upstream
 https://www.redhat.com/archives/libvir-list/2010-June/msg00499.html
Comment 3 Bug Zapper 2011-06-02 11:36:46 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 4 Cole Robinson 2011-06-10 13:50:01 EDT
Closing as CURRENTRELEASE, since this should be fixed in F15