question Re: Cloudera QuickStart 5.5 and VMware Player 12 Network Issue in Archives of Support Questions (Read Only)

Cloudera QuickStart 5.5 and VMware Player 12 Network Issue

lobbie168 — Wed, 23 Mar 2016 00:49:55 GMT

Hi all,

I have been trying to get this working in the past few days and tried almost everything I can but with no success.

My laptop is a Surface Pro 3 on Windows 10. I am using WMware Player 12 to run the Cloudera QuickStart 5.5 as a single node virtual machine. In the Network Adapter settings of the VM player, I tried both Brigded, NAT and Custom. I even used vmnetcfg.exe to add vmnet0.

My issue is the IP addresses of both the Manager Node and Worker Node 1 are 127.0.0.1 instead of the assigned IP address. ifconfig and running socket.gethostby name revealed the following,

[cloudera@quickstart ~]$ ifconfig
eth1 Link encap:Ethernet HWaddr 00:0C:29:AA:BC:4B
inet addr:192.168.1.123 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:379 errors:0 dropped:0 overruns:0 frame:0
TX packets:391 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:174070 (169.9 KiB) TX bytes:50633 (49.4 KiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:33255 errors:0 dropped:0 overruns:0 frame:0
TX packets:33255 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:115884356 (110.5 MiB) TX bytes:115884356 (110.5 MiB)

[cloudera@quickstart ~]$ python -c "import socket; print socket.getfqdn(); print socket.gethostbyname(socket.getfqdn())"
quickstart.cloudera
127.0.0.1

If I run the quickstart image in Virtual Box, I have no issues and the IP addresses are correctly assigned. I prefer VMware because Virtual Box seemed to hangs alot when running the vm.

I am at my wits end and being a noob made figuring this out more difficult. Please help!

Thank you in advance,

Will

Re: Cloudera QuickStart 5.5 and VMware Player 12 Network Issue

Sean — Wed, 23 Mar 2016 14:51:01 GMT

I think if you edit /usr/bin/cloudera-quickstart-ip you can work around
this easily. On line 24 we set the device we're looking for, DEV, to eth0.
Your networking device got added as eth1. When it fails to find eth0, it's
falling back to the loopback device so things at least work internally to
the VM. So if you edit that variable in your VM to eth1 and reboot, I would
expect this to work better for you. I'll expand what devices the script
looks for in the next release.

More generally, you can edit /etc/hosts and the networking configuration
however you want and remove the networking configuration from
/etc/init.d/cloudera-quickstart-init (in version 5.5, this is lines 39-42).
As long as quickstart.cloudera resolves to a valid IP and reverse lookup of
that IP gives you quickstart.cloudera, everything else should work - you'll
just need to restart all the services once it's the IP you want. The only
tricky thing is if your hypervisor wouldn't give you the same IP every time
you booted - then you need a script like cloudera-quickstart-ip to try and
determine which IP you got before the services start, and edit the right
files accordingly.

Re: Cloudera QuickStart 5.5 and VMware Player 12 Network Issue

lobbie168 — Wed, 23 Mar 2016 22:35:14 GMT

Hi Sean,

Thank you for your guidance.

I changed DEV='eth1' in /usr/bin/cloudera-quickstart-ip but am still getting 127.0.0.1 after reboot.

You mentioned modifying the ip variables in /etc/init.d/cloudera-quickstart-init. Example if the assigned IP is 192.168.1.125, what do I need to amend in lines 39 to 42?

cloudera-quickstart-ip
HOSTNAME=quickstart.cloudera
hostname ${HOSTNAME}
sed -i -e "s/HOSTNAME=.*/HOSTNAME=${HOSTNAME}/" /etc/sysconfig/network

Thanks,

Will

Re: Cloudera QuickStart 5.5 and VMware Player 12 Network Issue

Sean — Wed, 23 Mar 2016 22:54:01 GMT

If your IP will reliably be 192.168.1.125, I would just comment-out the
lines you show there from /etc/init.d/cloudera-quickstart-init, and I would
edit /etc/hosts to be the following:

127.0.0.1 localhost localhost.domain
192.168.1.125 quickstart.cloudera quickstart

Upon reboot, all the services should pick up and use the new IP. For the
welcome page and the tutorial to use the new IP (I don't think this is
necessary, it won't functionally change anything that I can think of), you
can also edit /var/lib/cloudera-quickstart/tutorial/js/config.js. The 2
parts to edit are the value for manager_node_ip and worker_nodes_ip
(although note that worker_nodes_ip is a list, with a single element.

Re: Cloudera QuickStart 5.5 and VMware Player 12 Network Issue

lobbie168 — Wed, 23 Mar 2016 23:47:58 GMT

Heya Sean,

You are a champ! It works now and please see details below,

[cloudera@quickstart ~]$ ifconfig
eth1 Link encap:Ethernet HWaddr 00:0C:29:AA:BC:4B
inet addr:192.168.1.125 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:220 errors:0 dropped:0 overruns:0 frame:0
TX packets:220 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:156228 (152.5 KiB) TX bytes:31127 (30.3 KiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:6085 errors:0 dropped:0 overruns:0 frame:0
TX packets:6085 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:28645729 (27.3 MiB) TX bytes:28645729 (27.3 MiB)

[cloudera@quickstart ~]$ python -c "import socket; print socket.getfqdn(); print socket.gethostbyname(socket.getfqdn())"
quickstart.cloudera
192.168.1.125
[cloudera@quickstart ~]$ quickstart.cloudera

What I do not understand is why it works automatically in Virtualbox and not VMware?

Thanks for your help again and looking forward to the next release with the VMware one fixed.

Cheers,

Will

Re: Cloudera QuickStart 5.5 and VMware Player 12 Network Issue

Sean — Thu, 24 Mar 2016 20:26:01 GMT

Good to know. The difference is just the device name the virtual NIC gets
added as in the guest OS. eth0 gets used when I try this out in VMware too
- not sure why the difference in this case. But the script could be made a
bit more flexible to handle this and similar scenarios.