Did your project recently renew or get a supplement?
Occasionally, accounts fail to be transferred from the previous version of the Project's allocation to the new version of the allocation. In this case, email firstname.lastname@example.org to create a support ticket. Be sure and include the Project code (example: TG-AAA000000) and your XSEDE account name to facilitate manually re-activating your account.
Have you in the past used compute resources at the Texas Advanced Computing Center (TACC) but haven't used them in more than 6 months?
If you have a Deactivated , PendingMigration, or otherwise disabled account with the Texas Advanced Computing Center (TACC), you will need to reactivate that account by changing your password here:
If you get a connection refused after multiple failed login attempts, you may need to use the unban utility mentioned in the section below titled You get an ssh "connection refused" message using a terminal-based shell client or Putty
VM gets stuck trying to provision the network or in deploying.
VM has IP address and shows active/green but is unreachable
Previously behaving and unmodifiedVMdevelops problems.
Try these in this order:
Refresh: Refresh your browser and confirm that the Atmosphere interface has synchronized with the latest Jetstream information.
Wait: Please be aware that while provisioning is generally rapid, it can sometimes take several minutes during times of heavy activity. (wait 5-10 minutes)
Redeploy/Reboot: Click Projects(on the top menu) and select the Project with the instance that is stuck. Then click on the instance name that's stuck. From the Actions menu on the right try • Redeploy first (waiting about 5-10 minutes before proceeding), • Reboot if that fails (waiting about 5-10 minutes before going to the next step), and • Hard Reboot if the first two actions fail (waiting about 5-10 minutes).
If everything otherwise seems in order deploying but the instance seems to be delayed in getting an IP address or in showing the WebShell buttons, the instance may be updating system packages. You will have to wait until this finalizes, then redeploy. Jetstream staff regularly update FEATURED IMAGES to address this. For images not maintained by Jetstream you will need to contact the owner.
If none of these Actions work, DO NOT DELETE THE INSTANCE. Make note of the Alias (UID) and IP Address of the Instance, and email that information to email@example.com or click the button.
If you have enabled a host-based firewall with ufw, iptables, or firewalld, you need to permit these IPs to ssh to your host on Atmosphere or deployment will fail.
The Ubuntu 18.04, 16.04 and Centos 7 featured images are piloting unattended security updates. Nodes will not reboot, but they will apply any update marked as a security update. It's still a good idea to update your VM, just in case.
To apply the updates: CentOS: sudo yum update Ubuntu: sudo apt-get update then sudo apt-get upgrade
If the kernel or glibc/libc packages are being updated, rebooting is necessary to implement those updates
Always run updates before requesting a new custom image - An actively updating instance may be slow to deploy and may require a redeploy or even a reboot after updating in order to fully successfully deploy.
If you’re having hostname mismatch issues with some software, try the following:
Volumes won't detach if they are actively being used. The unix umount will fail to protect you to prevent file corruption and/or to prevent you from accidentally stopping a process/job you didn't mean to kill. This, in turn, will prevent the Atmosphere detach from proceeding.
If your volume won't detach, try these steps:
make sure the instance to which the volume is attached is actively running
make sure no jobs or process are running on the instance are using the volume The command:
fuser -vm /vol_b
will show all processes using the volume named /vol_b
Kill those jobs (after verifying they don't need to be running):
fuser -km /vol_b
Volume fails to attach
make sure the instance to which the volume should be attached is actively running
My instance has been locked by an administrator
Are you running an insecure web-service like Apache or MongoDB with nosecurity features enabled ?
btrfs in conjunction with OpenStack's ceph has known kernel bug
please use a different file system. e.g XFS, EXT4
Mouse does not work in web desktop
Laptops with touchscreens are unable to use the mouse in the web desktop using Chrome and Firefox on Windows 10.
There is a bug in the web browser code in both Chrome and Firefox for using a touchscreen PC with the web desktop of Jetstream. This is not a bug we can easily work around since it's in the browser code itself.
While we do not recommend using Internet Explorer, it does not have the issue. Using a VNC Viewer also is a viable workaround.
web-shell works for my Ubuntu 16.04 version or newer instance, but I cannot ssh to it directly from an external ssh client
will show you all currently banned IPs. Find your IP in the list and do:
unban -i your_ip_address
sudo iptables -L -n
Look for your IP number in that output, if it's there, proceed
sudo fail2ban-client status
Should show you fail2ban is working and your jail name(s):
[js-157-95] USER ~>sudo fail2ban-client status
|- Number of jail: 1
`- Jail list: ssh-iptables
sudo fail2ban-client set ssh-iptables unbanip YOUR_IP_NUMBER
Jetstream can't be accessed from certain countries
Certain organizations and individuals are subject to trade sanctions, embargoes, and other restrictions under US law or by individual cloud provider policy. These restrictions apply to both domestic and foreign transactions.
You get a "403 Forbidden" or "403 Authentication credentials were not provided” error/screen trying to access the web shell or web desktop.
Your Globus credentials have become stale. Log out of Atmosphere by clicking on your username in the upper right hand corner of the Atmosphere interface and select "Sign Out" from the menu. Then log in again and try using the web shell or desktop.
I have an Ubuntu18-based instance that has been stuck deploying for quite some time.
Click on your instance and check the version:
Based on Ubuntu 18.04 Devel and Docker v1.12
If the version is < 1.8, you will have a known bug that introduces a configuration conflict that prevents rebooting/redeployment.
All Ubuntu versions ≥1.8 have been patched to fix this networking bug.
If possible, please rebuild your instance with a more recent version, otherwise, please contact firstname.lastname@example.org for assistance in applying the fix.
When I try to login after having selected XSEDE as my authorization provider, I get a page with the error message:
Unknown user or wrong password
Try logging into https://portal.xsede.org If you can login to the XSEDE portal, then it's likely that your username and password combination are correct.
Are you treating your username and password as if they were case-sensitive? Best results will occur if you treat your credentials as if they were case-sensitive when using Jetstream, Globus, or XSEDE.
My CentOS based instance shows active but isn't reachable via ping or SSH or my CentOS based instance is hung up at "Active Networking" in the booting phase.
Following an upgrade rebuilding virtual networks is now taking multiple hours. In the best case scenario, the failover happens successfully and no VMs are affected. If a networking node is rebooted before all of the rebuild has completed, there may be a gap where dhcp requests are not being answered. Red Hat based OSes like CentOS stop attempting to get a dhcp address after a certain period.
Rebooting the instance should bring the instance back online.
I want to use Microsoft Windows on Jetstream
While technically possible, Jetstream presently does not support Microsoft Windows at all. It will likely not be integrated into Atmosphere during the life of the current Jetstream project. If you wish to explore it with the understanding that we cannot provide support beyond normal VM operations, you can refer to Microsoft Windows on Jetstream
I have created a custom image in the Atmosphere interface but it isn't deploying properly in the API interface. (or vice versa)
We cannot recommend strongly enough not using Atmosphere images on the API side of Jetstream or vice-versa.
The Atmosphere user interface is designed to be extremely easy to use, particularly for beginning users but the trade-off is that Atmosphere enforces certain practices behind the scenes.
The API user interface is close to raw Openstack, makes almost no assumptions, requires advanced knowledge of Openstack and Linux, but is therefore much more flexible.
API and Atmosphere base images provided by Jetstream staff require SUBSTANTIAL work to make them CLEANLY work in the other environment.
My Debian/Ubuntu instance gives an error when I update packages.
I'm unable to unshelve my m1.xxlarge or s1.xxlarge instance – it begins the process and reverts to shelved_offloaded.
I’m unable to launch an m1.xxlarge instance - it goes to an error status very shortly after launch.
§ Please note that new s1.* instances are no longer supported. Please use m1.* instances with attached volumes instead.
While there are a number of reasons this may happen, the primary reason is usually that there are no hypervisors available for this size instance. Xxlarge instances require an almost entirely empty node to run on. If there is more than a pair of m1.tiny instance or m1.small instances, there won't be enough room to spawn an xxlarge instance on that node.
Because Jetstream has become a popular resource, it's become likely, especially on the IU cloud, that there is contention for getting entire nodes available for XXLarge instance usage.
The only options when this happens is to launch a smaller instance size, launch an xxlarge on the other cloud, wait, or keep trying. You can contact support via email@example.com if you want to verify that this is the issue.
You may want to benchmark your workflows and see if your code/workflow scales to need 44 cores and how efficiently it uses them. If you could use 24 cores, you'll generally have fewer issues shelving and unshelving. If you truly need 44 cores, you may encounter this from time to time - it's an unfortunate side effect of Jetstream's popularity.
My instance reverts to a shelved state without me shelving it.
Is the instance attached to a valid ACTIVE XSEDE allocation with service units still available?
If the allocation is expired or out of services units, the instance will auto-shelve.
Was the allocation recently renewed, converted from STARTUP to RESEARCH, or otherwise updated at XSEDE?
Instances can remain attached to the older, invalid incarnation of the allocation. In these cases you often see a “BLANK” allocation source drop-down menu. Try selecting a valid allocation from the drop-down menu, even if it means re-selecting the one you had before.