Description of problem: Libvirt provides a virtual networking capability for users who are unable to make use of bridging - eg Laptop users, anyone with Wifi, anyone using NetworkManager, or anyone without connectivity. This sets up an isolated bridge device to which guests attach & NATs to outside world. This requires dnsmasq to provide DNS and DHCP services to guest VMs, since they can't get DHCP across the NAT forwarding. The dnsmasq package is part of the (former) Fedora Extras, and is used by libvirt in Fedora 6/7 Version-Release number of selected component (if applicable): libvirt-0.2.3 How reproducible: Always Steps to Reproduce: 1. Start the libvirt default network (virsh net-start default) 2. Verify dnsmasq has started on Dom0 attached to that virbr0 device 2. Create a guest attached to the network 3. Try and configure guest with DHCP Actual results: No DHCP Expected results: dnsmasq running & DHCP works in guest Additional info: Recommend taking existing package from Fedora Extras dnsmasq-2.38-1.fc7
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
added from fedora devel to dis-5E-U1 for CVS, brew, and comps file. initial build: http://brewweb.devel.redhat.com/brew/taskinfo?taskID=827918 Daniel Veillard (veillard) is set as the owner of the package.
thanks Cristian, the built completed successfully. Just wondering, libvirt is limited to arches i386, x86_64 and ia64. Since dnsmasq is added solely as an helper for this libvirt update, should we use the same set of limited arches, or the whole set. Pros: - minimize the disruption of adding the new package Cons: - increase the gap between the architectures - we may miss some bugs only raised on the new architectures Seems the cons override the pros, but I wonder if there are release engineering rules for such a case, Daniel
I just thinked: I think dnsmasq should _not_ be neccesary Req from libvirt, its just another DHCP server, a simple lightweight one, and should be build on all our arches. There can be some case when dnsmasq is used for small office DHCP setup and not for xen !, since its very easy to configure, so building it for all arches make a sense at all. Thats my 5 cent.
Well the Requires is required because libvirt may exec dnsmasq, that's why we are adding it at this point :-) Let's keep it built on all arches, thanks, Daniel
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2007-0653.html