Hide Forgot
Created attachment 512304 [details] ss1 Description of problem: created a template that installed the rpms here http://packages.vmware.com/tools/esx/latest/rhel6/x86_64/ on RHEL6 Still getting just the mac address vmwareTools01/frontend01 IP Address: 00:50:56:a9:00:42 State: running I am getting the same result via dcloud http://sgi-xe3<snip>m:3006/api/instances/8975b038-2d7d-48c8-9dc5-5a8e41dc0b74 Public Addresses 00:50:56:a9:00:42 I tried upgrading the vmware tools on the client using the vsphere console, but the version is at the latest. ***********************************8 After logging into the console, it appears the RHEL6.1 guest does not have eth0 configured at all, and eth1 does not have an ip.
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...
closing out old bugs
perm close