Bug 210108 - xen guest install not getting IP from desired DHCP specified in kickstart
xen guest install not getting IP from desired DHCP specified in kickstart
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: virt-manager (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Hugh Brock
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-09 21:59 EDT by eric magaoay
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-09 15:59:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description eric magaoay 2006-10-09 21:59:00 EDT
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:
Comment 1 eric magaoay 2006-10-18 15:57:36 EDT
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
Comment 2 Daniel Berrange 2006-10-27 12:11:32 EDT
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.
Comment 3 Hugh Brock 2007-05-09 15:59:53 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.