When you try to stop a service, it will warn you which services depend on it if they are running. If you try to start a service, it will warn you which services it depends on if they are not running. I believe Zookeeper, HDFS, and YARN are the only other services you need to run for Spark, HBase, and Hive. ... View more

The 2 tables that are created are called 'intermediate_access_logs' and 'tokenized_access_logs' when shown in Hive or Impala. The intermediate_access_logs table is backed by the raw 'original_access_logs' file which is copied into HDFS. If you want to view it as a table, it should still be queryable in Hive at the end of the tutorial. The underlying data should still be in /user/hive/warehouse/original_access_logs in HDFS or /opt/examples/log_files/ on your local filesystem. ... View more

I apologize for the confusion - the service got a bit backed up over the weekend because of too many people abandoning clusters mid-deployment improperly. I've cleared out everything that looks abandoned so it should work better now. Note that access codes can't be reused, however, so if you deleted your previous stack you'll need to register for a new access code to try again. ... View more

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