Description of problem: Looks like virt-manager is always querying IP through "eth0" even though the kickstart specified that DHCP is on "eth2". Version-Release number of selected component (if applicable): Xen dom0/guest are from today's development build: 10-9-06 virt-manager.x86_64 0.2.3-2.fc6 anaconda.x86_64 11.1.0.109-1 xen.x86_64 3.0.2-44 xen-libs.x86_64 3.0.2-44 kernel-xen.x86_64 2.6.18-1.2747.fc6 How reproducible: fails only on multiple network devices (eth0,eth1,...) and DHCP is install on device other than the first network device assigned (eth0) Steps to Reproduce: 1. Setup at least 2 Network devices and assign DHCP on secondary device (eth1) 2. start virt-manager using kickstart configuration. kickstart URL: http://192.168.3.102/a/ks/61x64 vnc --password install url --url http://192.168.3.102/a/fed/x86_64/os network --device eth1 --bootproto dhcp --hostname 61x64 lang en_US keyboard us rootpw install timezone American/New_York Actual results: Install will complain that it could NOT find DHCP server Expected results: Would proceed and obtain the IP through eth1 device Additional info:
It looks like some motherboards assign the order of devices differently, so when the target network and and install source tree is assigned last (ie eth1) the program will fail due to querying the wrong DHCP network it found first, which is in device (eth0). The quick solution is to have virt-manager check the desired device defined in kickstart file (ie above is eth1) and query DHCP in eth1 network. The other solution would be to add a field option (under "install Media URL" field) to input the desired device for install, if none is provided it would then simply query DHCP on the first device it found I think the above process is how the anaconda does the install outside XEN. It would be nice to have the same consistency installing FC both inside and outside XEN environment. eric
The xen networking auto-detects the active ethX device and puts it into a bridge, xenbrX. If not specifying an explicit bridge device though, xend will not do autodetection, instead always trying to attach the guest to xenbr0. Given the complexity & fragility of the xen nework scripts I don't think its safe to try changing this to auto-detect bridge device at this time. So, instead we should focus on making it possible to choose a bridge device in virt-manager - this also address the situation of a user having multiple active devices.
This is fixed per Dan's description above in Rawhide. On creating a guest, you can choose whether to connect it to a bridge (and which bridge, if there's more than one), or you can create a virtual network among guests on your physical host.