| Summary: | fix RHEL ifconfig config so client can boot w/ ip address | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Retired] CloudForms Cloud Engine | Reporter: | wes hayutin <whayutin> | ||||||||||
| Component: | imagefactory | Assignee: | jrd <jrd> | ||||||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | wes hayutin <whayutin> | ||||||||||
| Severity: | urgent | Docs Contact: | |||||||||||
| Priority: | urgent | ||||||||||||
| Version: | 0.3.1 | CC: | akarol, clalance, dajohnso, deltacloud-maint, dgao, mfojtik, morazi, sloranz, sreichar, ssachdev | ||||||||||
| Target Milestone: | beta | ||||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | Unspecified | ||||||||||||
| OS: | Unspecified | ||||||||||||
| URL: | https://ibm-x3650-05.ovirt.rhts.eng.bos.redhat.com/conductor/instances/4 | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | Type: | --- | |||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||
| Documentation: | --- | CRM: | |||||||||||
| Verified Versions: | Category: | --- | |||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
| Attachments: |
|
||||||||||||
|
Description
wes hayutin
2011-07-11 22:35:48 UTC
Created attachment 512306 [details]
ss2
cat /var/log/messages | grep eth0 1.I see eth0 is using the intel pro/1000 driver 2. something renamed eth0 to eth1 Using the console I cp /etc/sysconfig/network-scripts/ifcfg-eth0 to ifcfg-eth1 and reconfig'd the mac address in eth1 to be the one dc/conductor was reporting [root@dhcp75-50 network-scripts]# cat /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE="eth0" BOOTPROTO="dhcp" HWADDR="52:54:00:5C:C6:0D" IPV6INIT="yes" MTU="1500" NM_CONTROLLED="yes" ONBOOT="yes" TYPE="Ethernet" [root@dhcp75-50 network-scripts]# cat /etc/sysconfig/network-scripts/ifcfg-eth1 DEVICE="eth1" BOOTPROTO="dhcp" HWADDR="00:50:56:a9:00:42" IPV6INIT="yes" MTU="1500" NM_CONTROLLED="yes" ONBOOT="yes" TYPE="Ethernet" [root@dhcp75-50 network-scripts]# the deltacloud driver now reports the ip address properly Public Addresses 10.16.75.50 So I'm not sure where the bug is, I'm wondering if there is a diff between fedora and RHEL here. I am also wondering why 1. the nic was moved from eth0 -> eth1 This seems to prevent the nic from starting due to a mac address conflict. 2. Why is conductor not picking up the ip if deltacloud can. I suspect we only make a call once to deltacloud to get the ip of the instance. We *may* want to make a call everytime someone visits that page like deltacloud does?? If anyone is interested is sshing in and taking a look.. please ping me. Take a look at ss1 and ss2 to see how the guest originally came up template used...
<template>
<name>RHEL_westestVmware01</name>
<os>
<name>RHEL-6</name>
<version>1</version>
<arch>x86_64</arch>
<install type="url">
<url>http://download.devel.redhat.com/released/RHEL-6-Server/6.1/x86_64/os/</url>
</install>
</os>
<description>RHEL61 x86_64 with postgres</description>
<repositories>
<repository name='vmwareTools'>
<url>http://packages.vmware.com/tools/esx/latest/rhel6/x86_64/</url>
<signed>False</signed>
</repository>
</repositories>
<packages>
<package name='vmware-open-vm-tools'/>
</packages>
</template>
[root@ibm-x3650-05 ~]# rpm -qa | grep aeolus
aeolus-all-0.3.0-0.el6.20110711131044git5bc7abf.noarch
aeolus-configure-2.0.1-0.el6.20110708134115gitab1e6dc.noarch
aeolus-conductor-0.3.0-0.el6.20110711131044git5bc7abf.noarch
aeolus-conductor-daemons-0.3.0-0.el6.20110711131044git5bc7abf.noarch
rubygem-aeolus-cli-0.0.1-1.el6.20110711131044git5bc7abf.noarch
aeolus-conductor-doc-0.3.0-0.el6.20110711131044git5bc7abf.noarch
[root@ibm-x3650-05 ~]# rpm -qa | grep delta
libdeltacloud-0.9-1.el6.x86_64
deltacloud-core-0.3.9999-1308927004.el6.noarch
rubygem-deltacloud-client-0.3.1-1.el6.noarch
condor-deltacloud-gahp-7.6.0-5dcloud.el6.x86_64
[root@ibm-x3650-05 ~]#
potential fix.. fix this go into the /etc/udev/70-peristent-net.rules and change eth1 to eth0 potential fix found here.. http://communities.vmware.com/message/1748690 *** Bug 721038 has been marked as a duplicate of this bug. *** RHEL 6
************************************************
[root@ibm-x3650-05 yum.repos.d]# cat /etc/udev/rules.d/70-persistent-net.rules
#GENERATED BY A SUCKY KS POST SCRIPT
SUBSYSTEM==net, ACTION==add, DRIVERS==?*, ATTR{address}==00:1A:64:C7:4A:BC, ATTR{type}==1, KERNEL==eth*, NAME=\eth
SUBSYSTEM==net, ACTION==add, DRIVERS==?*, ATTR{address}==00:1A:64:C7:4A:BE, ATTR{type}==1, KERNEL==eth*, NAME=\eth
SUBSYSTEM==net, ACTION==add, DRIVERS==?*, ATTR{address}==00:15:17:97:F2:D0, ATTR{type}==1, KERNEL==eth*, NAME=\eth
SUBSYSTEM==net, ACTION==add, DRIVERS==?*, ATTR{address}==00:15:17:97:F2:D1, ATTR{type}==1, KERNEL==eth*, NAME=\eth
SUBSYSTEM==net, ACTION==add, DRIVERS==?*, ATTR{address}==00:15:17:97:F2:D2, ATTR{type}==1, KERNEL==eth*, NAME=\eth
SUBSYSTEM==net, ACTION==add, DRIVERS==?*, ATTR{address}==00:15:17:97:F2:D3, ATTR{type}==1, KERNEL==eth*, NAME=\eth
SUBSYSTEM==net, ACTION==add, DRIVERS==?*, ATTR{address}==00:1B:21:29:CD:4C, ATTR{type}==1, KERNEL==eth*, NAME=\eth
# PCI device 0x8086:0x10c7 (ixgbe) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1b:21:29:cd:4c", ATTR{type}=="1", KERNEL=="eth*", NAME="eth6"
# PCI device 0x14e4:0x164c (bnx2) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1a:64:c7:4a:bc", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
# PCI device 0x8086:0x10a4 (e1000e) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:15:17:97:f2:d1", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3"
# PCI device 0x8086:0x10a4 (e1000e) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:15:17:97:f2:d2", ATTR{type}=="1", KERNEL=="eth*", NAME="eth4"
# PCI device 0x14e4:0x164c (bnx2) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1a:64:c7:4a:be", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
# PCI device 0x8086:0x10a4 (e1000e) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:15:17:97:f2:d0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"
# PCI device 0x8086:0x10a4 (e1000e) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:15:17:97:f2:d3", ATTR{type}=="1", KERNEL=="eth*", NAME="eth5"
[root@ibm-x3650-05 yum.repos.d]#
************************************************
FEDORA
************************************************
# PCI device 0x14e4:0x1600 (tg3) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:19:b9:05:81:b1", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
[whayutin@localhost ~]$
************************************************
In the cloud context (which is the purpose of the Factory) we essentially never want to create an association between a particular ethernet device name and a MAC address, since the MAC address will change with every launch of the Image into an Instance. I have opted to remove the udev rule file entirely when constructing images. Note that it is recreated at boot time (at least on RHEL6) and populated with the correct information. This is now in our master branch on git in the following commit: https://github.com/aeolusproject/image_factory/commit/fe7fa0e51805516a4640061a350e3d61b1969214 I have tested this using RHEL6 and a local VMWare test instance. With the change in place the guest brings up its primary network on eth0. This is either not in the build or not fixed.. [root@hp-sl2x170zg6-01 ~]# rpm -qa | grep imagefactory rubygem-imagefactory-console-0.4.0-1.el6.20110721153525gitaaac737.noarch rimagefactory-0.4.0-1.el6.noarch pm [root@hp-sl2x170zg6-01 ~]# rpm -qa | grep oz oz-0.5.0-1.el6.noarch [root@hp-sl2x170zg6-01 ~]# THe RHEL 6.1 guest itself does not have an ip address. Created attachment 514717 [details]
ss3
seems like that file should be removed..
# In the cloud context we currently never need or want persistent net device names
270
+ # This is known to break networking in RHEL/VMWare and could potentially do so elsewhere
271
+ # Just delete the file to be safe
272
+ if g.is_file("/etc/udev/rules.d/70-persistent-net.rules"):
273
+ g.rm("/etc/udev/rules.d/70-persistent-net.rules")
274
+
269 275
g.sync ()
My theory is that we remove the file but do not remove the MAC address from the /etc/sysconfig/network-scripts/ifcfg-eth0 file. If we do that in addition to removing the udev net rules file, this should work. [root@hp-ml310g5-01 html]# rpm -qa | egrep 'aeolus|factory|oz|iwhd' | sort aeolus-all-0.3.0-0.el6.20110721214453git381316a.noarch aeolus-conductor-0.3.0-0.el6.20110721214453git381316a.noarch aeolus-conductor-daemons-0.3.0-0.el6.20110721214453git381316a.noarch aeolus-conductor-doc-0.3.0-0.el6.20110721214453git381316a.noarch aeolus-configure-2.0.1-1.el6.20110721154028git42b1e20.noarch imagefactory-0.4.0-1.el6.noarch iwhd-0.97-1.el6.x86_64 oz-0.5.0-1.el6.noarch rubygem-aeolus-image-0.0.1-1.el6.20110721174118git6f9d8d4.noarch rubygem-imagefactory-console-0.4.0-1.el6.20110721153525gitaaac737.noarch Okay, so we've tested a patch that removes the HWADDR from /etc/sysconfig/network-scripts/ifcfg-eth0 and deltacloud shows the public IP but it's not showing up in the conductor UI. 6:51 PM] <rwsu> morazi-afk: deltacloud api does show the public ip fwiw: http://hp-sl2x170zg6-02.rhts.eng.bos.redhat.com:3007/api/instances/9b9c6e12-6214-4454-b399-e8e101a6bbb3 I've pushed this change to master. https://github.com/aeolusproject/image_factory/commit/1551e194ee40e939bfac1ff1cd0bd03bf3ca8792 This looks good now and marking as verified aeolus-all-0.3.0-2.el6.noarch aeolus-conductor-0.3.0-3.el6.noarch aeolus-conductor-daemons-0.3.0-3.el6.noarch aeolus-conductor-doc-0.3.0-3.el6.noarch aeolus-configure-2.0.1-2.el6.noarch imagefactory-0.4.1-1.el6.noarch iwhd-0.97-1.el6.x86_64 oz-0.5.0-1.el6.noarch rubygem-aeolus-image-0.0.1-3.el6.noarch rubygem-imagefactory-console-0.4.0-1.el6.noarch Created attachment 515410 [details]
conductor gets ip from vsphere for RHEL 6
[whayutin@thinkdoe ~]$ ssh root.75.56
The authenticity of host '10.16.75.56 (10.16.75.56)' can't be established.
RSA key fingerprint is 31:b0:90:a4:79:0e:3d:45:1e:c1:f3:bd:52:fe:5c:b9.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.16.75.56' (RSA) to the list of known hosts.
root.75.56's password:
Last login: Wed Jul 27 01:00:19 2011
[root@dhcp75-56 ~]# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:50:56:A9:00:E2
inet addr:10.16.75.56 Bcast:10.16.75.255 Mask:255.255.252.0
inet6 addr: fe80::250:56ff:fea9:e2/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:944 errors:0 dropped:0 overruns:0 frame:0
TX packets:81 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:68138 (66.5 KiB) TX bytes:9736 (9.5 KiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:298 (298.0 b) TX bytes:298 (298.0 b)
[root@dhcp75-56 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.1 (Santiago)
[root@dhcp75-56 ~]#
[root@intel-d3c4702-01 ~]# rpm -qa | grep aeolus
aeolus-configure-2.0.1-2.el6.noarch
aeolus-conductor-0.3.0-3.el6.noarch
aeolus-conductor-daemons-0.3.0-3.el6.noarch
rubygem-aeolus-image-0.0.1-3.el6.noarch
aeolus-all-0.3.0-2.el6.noarch
aeolus-conductor-doc-0.3.0-3.el6.noarch
[root@intel-d3c4702-01 ~]# rpm -qa | grep imagefactory
rubygem-imagefactory-console-0.4.0-1.el6.noarch
imagefactory-0.4.1-1.el6.noarch
[root@intel-d3c4702-01 ~]# rpm -qa | grep iwhd
iwhd-0.97-1.el6.x86_64
[root@intel-d3c4702-01 ~]#
removing from tracker release pending... release pending... closing out old bugs perm close |