Hello,
I have only one, but big server where I'm experimenting many things.
It is a Fedora 11 x86_64 host.
At first I configured it as a host for qemu/kvm guests, managing them with the virt-manager gui tool.
I successfully had dnsmasq instance run by libvirt layer coexist with the system provided dnsmasq daemon
This way I could manually PXE boot and install guests configured with shared physical networks (bridge br0 on the host).
(I have two dnsmasq processes listening on different interfaces, br0 and virbr0)

Now I'm looking at cobbler/koan to glue together things and provide also provisioning for physical and virtual servers. Unfortunately I have to configure/manage it on the same big box....

I configured cobbler to use dnsmasq and I thought that this way it would pick up the already configured one.
Instead it seems to me that it overwrote completely my previous /etc/dnsmasq.conf file ....
Is there any way to let cobbler use an externally configured dnsmasq or by design it has to manage it?
At this moment I have

in /etc/cobbler/modules.conf:
[dhcp]
module = manage_dnsmasq

in /etc/cobbler/settings:
manage_dhcp: 1

Is it correct that I can preserve my already setup configs and settings only putting manage_dhcp: 0?
this way cobbler will take advantage (or disadvantage if I scrumble things.. ;-) and not interfere?

cobbler check gives:
[root@virtfed etc]# cobbler check
/usr/lib64/python2.6/site-packages/Cheetah/CacheRegion.py:30: DeprecationWarning: the md5 module is deprecated; use hashlib instead
  import md5
The following potential problems were detected:
#0: change 'disable' to 'no' in /etc/xinetd.d/tftp
#1: since iptables may be running, ensure 69, 80, and 25151 are unblocked
#2: The default password used by the sample templates for newly installed machines (default_password_crypted in /etc/cobbler/settings) is still set to 'cobbler' and should be changed
#3: fencing tools were not found, and are required to use the (optional) power management features. install cman to use them

In particular, I see that it configured this way

[root@virtfed etc]# cat /etc/dnsmasq.conf
# Cobbler generated configuration file for dnsmasq
# Wed Jul  1 10:02:47 2009

# resolve.conf .. ?
#no-poll
#enable-dbus
read-ethers
addn-hosts = /var/lib/cobbler/cobbler_hosts

dhcp-range=192.168.1.5,192.168.1.200
dhcp-option=3,10.4.5.152
dhcp-lease-max=1000
dhcp-authoritative
dhcp-boot=pxelinux.0
dhcp-boot=net:normalarch,pxelinux.0
dhcp-boot=net:ia64,/var/lib/cobbler/elilo-3.6-ia64.efi

Where does it pick the 192.168 address range....? Suppose I want to have cobbler manage dhcp, where I configure the range? If I modify dnsmasq.conf and then run "cobbler sync" do I risk to overwrite again my changes?

Eventually it could be nice to have cobbler making a backup copy (luckily I had it) before overwrite....

I think that overwrite happened when I ran
cobbler import --path=/mnt --name=rhel4.8 --arch=x86
after mounting an iso of rhel4.8 x86....

btw: what is the difference between --path and --mirror? Perhaps the former can only manage local paths, while the latter also Uri such as http/nfs...? I didn't find clear answer...

I'm glad to say that anyway I was then able to install a guest on the same host provinding cobbler with the command
koan --server=10.4.5.152 --virt --profile=rhel4.8-i386-virt --virt-name=koantest
and then access it form within virt-manager. My compliments to you guys!

some annotations:

- even if in my kickstart I had
network --device=eth0 --bootproto static --ip 10.4.5.154 --netmask 255.255.255.0 --gateway 10.4.5.250 --nameserver 10.4.1.120 --hostname koantest
It asked the network parameters in anaconda......
I presume because the kernel command line "automatically" contained "ksdevice=link" but I'm not sure.
Also, this is a constraint with network installs and my line above is parsed only to configure network for the system but not used at the initial steps....
After putting the static network information, the installation proceeded successfully.

- in /etc/cobbler settings I have
default_virt_type: qemu
but it seems cobbler configured the guest with the mac address used for xen (initial 00:16:3e) instead of the one for qemu (52:54:00)

Thanks for your time,
Gianluca