Contents


The My GoGrid Server Image (MyGSI) feature allows you to create, save, and store a "server image" from which you can instantiate Database and Web/App Servers.

Key Features

  • Reduce setup and configuration times for new servers
  • Enable rapid horizontal scaling of servers - deploy new app and web servers to meet sudden spikes and delete them as demand drops
  • Create and manage a repository of personalized GoGrid Server Images
  • Deploy multi-data-center solutions with MyGSI migration

Data Center Availability

MyGSIs are currently available in our US-West-1, US-East-1, and EU-West-1 data centers.

Server Flavors

There are now multiple server flavors which impacts the behavior of MyGSI. MyGSI's will always deploy on the server flavor that it was created from. For example, saving a MyGSI from a Standard Cloud Server will always deploy into another Standard Cloud Server. It's not always guaranteed to work on other flavors (such as SSD, Raw Disk or High RAM).


Flavor Standard SSD Raw Disk High RAM
Standard Yes Yes No No
SSD Yes Yes No No
Raw Disk No No Yes No
High RAM No No No Yes

This table shows that MyGSIs saved from a Standard Cloud Server can be deployed to Standard and SSD but not Raw Disk or High RAM. MyGSIs saved from Raw Disk or High RAM Cloud Servers can be deployed only to its own flavor.

MyGSI Migration

You can copy MyGSIs to multiple data centers by opening a Support ticket from the management console. You'll need to have Cloud Storage activated in each data center to which you wish to copy MyGSIs because the image is stored in your Cloud Storage. Deleting a MyGSI from your account will only remove the image from its original data center. To delete the MyGSI copies, please open a Support ticket. Updates to a copied MyGSI are not global. Migration and standard Cloud Storage fees may apply.

API

Use grid.image.list, grid.image.get, grid.image.edit, grid.image.save, grid.image.delete, and grid.image.restore to manage your MyGSI.

User Manual

See the MyGSI User Manual for information on creating a MyGSI.

Pricing

Servers from which MyGSIs are created incur the same RAM and transfer charges as any other cloud server. You are not charged to create or use MyGSIs, but you will be charged for the cloud storage space they consume. MyGSIs are free if you are under your 10 GB free cloud storage allotment. Additional storage is billed at cloud storage rates. There are no set up fees and no long-term commitments.

Getting Help

See our Support page for information on contacting GoGrid for any questions or issues that arise.

Frequently Asked Questions

General Behavior

  • Can I save a cloud server while it is running?
Yes you can. Please note though that your server will be automatically restarted at the beginning of the save process, so we recommend gracefully shutting down processes as appropriate before initiating a save. Several operations are performed while the server is off, so you will experience up to 15 minutes of downtime (usually less). If your server is powered off when you initiate a save, it will not be restarted and will remain off during and after the save process.
  • Do I have access to my cloud server while a MyGSI is being saved?
Assuming you initiated a save while the cloud server was powered on, your server will be online and available after a brief period of downtime. However, no customer portal or API actions are permitted until the save process is fully completed. Therefore, if you initiated the save process while the server was powered off, you will not be able to start it until the save process is fully completed.
  • When I delete a server image, how long does it remain in the Trash state?
In most cases, server images are permanently deleted (purged from the trash) within an hour of being deleted via the Portal or API.

Troubleshooting

  • Why did my save fail and what should I do about it?
If your save job fails, you should first check the Jobs Tab. The Details section of your Save Server Image Job often contains helpful debug messages. Common messages include the following:

Timeout waiting for Linux prep or Windows sysprep to shutdown or
Exception occured while waiting for sysprep.
These messages indicate an incompatibility with the Windows sysprep utility that is used as part of the save process. Common culprits include:

  • Roles not supported by sysprep. See this MS TechNet article for more information.
  • AVG and other antivirus software. We recommend disabling these services before saving.
  • Corrupted Windows system files (e.g BCD Store libraries). Running sfc and/or chkdsk will reveal these issues and allow repair.
  • Startup scripts and services. We recommend using msconfig to disable these before initiating a save
  • Older .NET versions. The save process requires .NET 2.0 or later. Please update your .NET framework if you are running an earlier version.
  • Renamed Administrator account. The save process requires that the Windows Administrator account not be renamed

Unable to attach/detach block device
This message most often indicates a transient issue due to resource contention on the physical node that hosts your cloud server. We recommend waiting a few minutes, then resubmitting the save job.

invalid literal for int() with base 10
This message indicates that your cloud server has been configured with multiple disk partitions. At this time, MyGSI does not support saving logical volumes with >1 partition, so unfortunately this error indicates that your cloud server cannot be saved.
If none of the above helps resolve your issue, please contact GoGrid Support for assistance.


  • Why does my password change after I create a new server from a MyGSI?
We change the system password every time a server is instantiated. This is a security precaution, though you can always change the password back. We do not change any system or user passwords other than root or administrator.


  • All of my network configurations and drive mappings have disappeared on the server I instantiated from a MyGSI. What happened?
Our preparation scripts intentionally remove all networking from your Image Server as it becomes a MyGSI. This means that any routes set up for accessing other servers on your grid or cloud storage are removed. You will have to manually set these up again for the near feature. We suggest against configuring any static networking on your Image Server as it will be removed in the save process.
  • I changed my Administrator user to another name. I noticed that this is not working on a server I instantiated from a MyGSI.
Changing the administrator log on for a Windows server is not supported at this time. We suggest that you do not change your administrator user on your Image Server as this will not be supported when you save your server as a MyGSI.
  • All of the logs and bash history I had on my Server Image are not present on servers instantiated from my MyGSI. What happened?
Our preparation scripts remove all bash and command history as well as any logs stored on your Image Server. Instantiating a new server from a MyGSI will have no bash history or logs saved inherited from the Image Server.
  • My application runs on files stored on Cloud Storage. Now that I have saved several MyGSIs, I keep getting I/O errors on my application. What is going on?
All MyGSIs are stored on Cloud Storage. This means that if you are rapidly approaching your quota, saving a MyGSI may put you over your limit. If you exceed your quota, writing to Cloud Storage may result in errors as you are out of storage space. Cloud Storage quotas are updated on a daily basis to ensure that you have 100 GB more than 80% of your current utilization. If you are receiving these errors, immediately remove data from Cloud Storage or submit a support case to have your Cloud Storage quote increased.
  • I installed several 3rd party applications on my cloud server. When I saved a MyGSI and instantiated a new server, my applications did not work. What happened?
Our preparation scripts are customized to ensure that a wide variety of applications will continue to work after being saved as a MyGSI. If you encounter a situation in which your server generated from a MyGSI does not allow your 3rd party application to run properly, please submit a support case.

Previous MyGSI Versions

 The following FAQs apply only to image sandbox servers created before March 10, 2011. 
  • I just completed my Image Sandbox and I forgot to add something, but I've already run my preparation scripts. What do I do?
Once you have elected to run the preparation scripts on your Image Server, it is highly recommended against attempting to restart the server. If you forgot to add something to your Image Server, continue the save process and save your Image Server as a MyGSI. You can then re-instantiate your MyGSI as an Image Server and configure your changes before saving the Image Server as a MyGSI again.
  • I ran the preparation script on my Linux server, but the server is still started. What do I do?
If your Linux server reboots after you have run your preparation script, log into the server and run the shutdown now command.
  • Why am I being charged for an Image Sandbox?
An Image Server is essentially a virtual server that utilizes resources on the grid. Creating a server of any type will result in charges for the allotted RAM associated with that server. Image Servers are allocated 2 GB RAM, resulting in 2 Server RAM hours being charged to your account for every hour your Image Server is instantiated. Once your Image Server has been saved as a MyGSI, it will be deleted and you will only be charged for the cloud storage utilization filled by your image file.
  • Why does my server disappear after I save it?
This is by design. Once you have saved your image sandbox server as a MyGSI, the server is deleted.
  • I tried to start my server after I ran the prep script and the server didn't come up. What happened?
Once you have run your prep script, your server cannot be started or restarted. Our prep scripts run a variety of operations that make your server unbootable as we have prepared it to be converted into a MyGSI. Do not attempt to start or restart an Image Sandbox Server after running the prep scripts. This can cause unexpected results.
  • My Image Sandbox Server has only 20 GB of storage. Is this intentional?
Image Sandbox Servers have a fixed amount of RAM and storage. This is by design. Each Windows Image Sandbox Server is deployed with 2 GB RAM and 30 GB storage. Each Linux Image Sandbox Server is deployed with 2 GB RAM and 20 GB storage.
Personal tools