For the instructors, there are now 4 users:
admin1 — Brad
admin2 — John
admin3 — Karim
admin4 — Marc
password: !onecloud123
from there you can log into a pair of systems, separate from the rest of the labs:
admin1: aio221 compute231
admin2: aio222 compute232
admin3: aio223 compute233
admin4: aio224 compute234
ssh in the admin user accout is set to log in as centos user to the aio and compute nodes, , and you already have a ssh key for all of the system (they were all deployed with the same cloud key)
but just in case: the user is centos, the password is centos
the image is a standard CentOS Cloud image (Centos 7.1)
As with the student environments, I recommend that at least the first ssh session (or with tunnel setup in putty, first putty session) be run as:
ssh -L 8080:10.1.64.221:80 -L 6080:10.1.64.221:6080 [email protected]
{clearly this is for user admin1 and user aio221}
this allows you to eventually point your browser to http://localhost:8080 on your local laptop, and get to horizon when taht’s set up.
Also if you run:
nova get-vnc-console vm-name novnc
You’ll get a URL of the form:
http://10.1.64.221:6080/…….
If you take that URL, and again, drop it into your local browser (but you’ll need to change 10.1.64.221 to localhost before hitting “enter”) you will eventually be able to access your deployed VMs via webVNC.
Now the trick to all of the above is that if you need to help a student fix an issue that they have with their VMs….
Well, instead of logging in to your AIO node (and instead of setting the pointers to about to 10.1.64.221):
ssh -L 8080:10.1.64.11:80 -L 6008:10..164.11:6080 [email protected]
ssh admin@centos-1
source ~/keystonerc_admin
nova get-vnc-console {trouble_VM_name} novnc
and as above, take the http URL, paste it into your _local_ browser, change the 10.1… address with localhost, and voi la, KVM access to the troubled VM.
Since these are centos machines, the user is centos, password is centos.
————————————————————————————————————————-
Added Details on Access to Student Systems
Clearly getting access to tenants VMs when they break something (perhaps network wise) is one of the tricks that needs to be dealt with. I’ve created a script to help a bit on the jumpbox (66.220.11.249):