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. ... View more

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. ... View more

One possibility to have in mind is memory issues. The VM is a very compact environment, and it only gets tested with fairly small demo datasets. If you've loaded other data into HBase prior to trying to access it via Phoenix, you might need to do some tweaking of memory configuration in HBase or add more memory to the VM to get it to work as reliably as it ordinarily would. ... View more

Your best bet to figure out why it's failing is to check the log for the RegionServer role. Click on the HBase service and down the left hand side you'll see the RegionServer. You'll want to open that, go to the "Processes" tab, and the click "See Role Log Details". Most recent messages will be at the bottom, and my guess is the error should be in the last few entries. (I might be missing a link or tab or something in that navigation - hopefully this is clear enough for you to find it!) ... View more

Can you check that Zookeeper (and HDFS and HBase, for that matter) are running in Cloudera Manager? Port 2181 is ZooKeeper and it seems like it's not able to connect to that. Because running every service requires quite a lot of memory for a VM, when you migrate to Cloudera Manager or switch to parcels, it won't start every service for you. If you go to Cloudera Manager and log in, the home screen should show a table of all the services in the cluster. Make sure ZooKeeper, HDFS and HBase are marked with a green dot. Otherwise, they may need to started or restarted. If they're marked with a question mark, usually that means one of the "Management Services" (really, these are just parts of CM represented as separate services) need to be restarted.     ... View more

The script I suggested you use is just an automated version of the process documented at the link you provided. I would just try running the script, and when that's done going back and retrying the Phoenix parcel. ... View more

It's a button on the desktop in the QuickStart VM - I saw you were using Docker, so I added the CLI equivalent of 'sudo /home/cloudera/parcels' above <- that should run the same script that will install the parcel that matches the QuickStart image, remove the Linux packages, etc.. ... View more

Via CLI, that script can be invoked as `sudo /home/cloudera/parcels`. ... View more