We are happy to announce "phantomize", a Phantom feature that will automatically install and run the tcollector sensor agent on the first boot of your virtual machines thereby automatically instrumenting your VMs to provide sensor measurements.
Phantom offers autoscaling based on sensor measurements from a variety of sources, including user's virtual machines. To collect these measurements, Phantom relies on the tcollector sensor agent being running on each of those virtual machines. Until now, users had to manually install tcollector in their virtual machines or use an image provided by us with tcollector already installed. The former requires extra effort and the latter restricts the user to the types of images provided by us.
The phantomize feature addresses this problem. To use it, all the user needs to do is pick the "phantomize" contextualization type in their launch configuration settings. The only requirement is that the user's virtual machine image is capable of downloading and executing the user-data script on boot.
Phantomize has been tested successfully with Debian, Fedora, and Ubuntu virtual machines on FutureGrid clouds running Nimbus and OpenStack.
Tuesday, July 15, 2014
Friday, June 6, 2014
OpenStack Hotel now supports the native OpenStack APIs
We have changed the configuration of the OpenStack Hotel cloud so that users can now access the native OpenStack APIs over secure HTTP connections.
You can download your OpenStack credentials file from the web interface via the "Access & Security" link in the left of any page and then click on the "API Access" link on the top.
You can download your OpenStack credentials file from the web interface via the "Access & Security" link in the left of any page and then click on the "API Access" link on the top.
Wednesday, June 4, 2014
FutureGrid multi-cloud VM image generator now available
We are happy to announce the alpha release of our newest tool for FutureGrid users: a multi-cloud VM image generator.
FutureGrid offers access to multiple clouds based on several different technologies (Nimbus, OpenStack, and Eucalyptus) using different hypervisors (Xen or KVM). Users can also supplement the use of FutureGrid resources by bursting out to commercial clouds such as Amazon EC2. While this allows users to use multiple clouds, such access is often hard to leverage as VM images are generally not portable across different formats and cloud providers.
This presents users with a few problems. First, moving from one cloud to another means creating a new image; this is time-consuming and error-prone. Second, users typically want the VM images to represent a consistent environment independently of what type of cloud the image is deployed on; this is hard to achieve using a manual configuration process as even small differences in configuration can have significant consequences. Third, even if the user does produce a set of images that are initially consistent, as images subsequently evolve it is hard to keep track of which changes were applied to which image. In short, the problem is the lack of traceability and repeatability of VM image customizations.
Our image generator aims to solve these problems by providing an interface to specify a customization script that can be used to generate consistent images for many clouds. The service starts out with a set of consistent images uploaded to several clouds, applies them to those images, and creates a new VM image on each cloud.
We invite you to try our image generator by following our online tutorial, and please report any issue of request to nimbus-phantom@lists.mcs.anl.gov.
FutureGrid offers access to multiple clouds based on several different technologies (Nimbus, OpenStack, and Eucalyptus) using different hypervisors (Xen or KVM). Users can also supplement the use of FutureGrid resources by bursting out to commercial clouds such as Amazon EC2. While this allows users to use multiple clouds, such access is often hard to leverage as VM images are generally not portable across different formats and cloud providers.
This presents users with a few problems. First, moving from one cloud to another means creating a new image; this is time-consuming and error-prone. Second, users typically want the VM images to represent a consistent environment independently of what type of cloud the image is deployed on; this is hard to achieve using a manual configuration process as even small differences in configuration can have significant consequences. Third, even if the user does produce a set of images that are initially consistent, as images subsequently evolve it is hard to keep track of which changes were applied to which image. In short, the problem is the lack of traceability and repeatability of VM image customizations.
Our image generator aims to solve these problems by providing an interface to specify a customization script that can be used to generate consistent images for many clouds. The service starts out with a set of consistent images uploaded to several clouds, applies them to those images, and creates a new VM image on each cloud.
We invite you to try our image generator by following our online tutorial, and please report any issue of request to nimbus-phantom@lists.mcs.anl.gov.
Thursday, March 6, 2014
Nimbus users on Hotel and Sierra should now start migrating to KVM
If you are currently using Nimbus on Sierra or Hotel, or if your work relies on an existing virtual machine image hosted on those clouds, then you need to take action.
In a few days, the Nimbus cloud on Sierra will become unavailable. As a result, following the recent announcement of changes in Nimbus cloud allocations on FutureGrid, the Hotel cloud will be gradually converted from Xen to KVM virtualization. In addition to being compatible with the Alamo Nimbus cloud, this allows us to support recent Linux distributions and brings better compatibility with virtual machine images built using other virtualization platforms (VirtualBox for example).
We have now made available a Nimbus cloud on Hotel using KVM virtualization. The existing Xen cloud on Hotel will remain available until the end of March to allow users to migrate their environments. To start using the Nimbus Hotel KVM cloud, extract a fresh copy of your credentials and use the hotel-kvm.conf configuration file.
As soon as possible, you should migrate your Xen images from Sierra and Hotel to a KVM cloud: either to Alamo or to the new Hotel KVM cloud.
If your virtual machine image only contains small modifications from the base environment, we advise to create a new one using the base images on those clouds.
If your virtual machine image contains heavy modifications, you can follow our instructions to convert your Xen image to KVM.
If you need any assistance for this process, please contact us through the FutureGrid help system.
In a few days, the Nimbus cloud on Sierra will become unavailable. As a result, following the recent announcement of changes in Nimbus cloud allocations on FutureGrid, the Hotel cloud will be gradually converted from Xen to KVM virtualization. In addition to being compatible with the Alamo Nimbus cloud, this allows us to support recent Linux distributions and brings better compatibility with virtual machine images built using other virtualization platforms (VirtualBox for example).
We have now made available a Nimbus cloud on Hotel using KVM virtualization. The existing Xen cloud on Hotel will remain available until the end of March to allow users to migrate their environments. To start using the Nimbus Hotel KVM cloud, extract a fresh copy of your credentials and use the hotel-kvm.conf configuration file.
As soon as possible, you should migrate your Xen images from Sierra and Hotel to a KVM cloud: either to Alamo or to the new Hotel KVM cloud.
If your virtual machine image only contains small modifications from the base environment, we advise to create a new one using the base images on those clouds.
If your virtual machine image contains heavy modifications, you can follow our instructions to convert your Xen image to KVM.
If you need any assistance for this process, please contact us through the FutureGrid help system.
Tuesday, February 18, 2014
Changes in Nimbus Cloud Allocations in FutureGrid
Dear Nimbus Users,
FutureGrid has decided to decommission the Nimbus Cloud on Sierra at San Diego Supercomputing Center.
Over the last several years Sierra and Hotel have been the two most used FutureGrid clouds. Sierra has fulfilled an important role for many Nimbus-based projects as a complement to Hotel: both Sierra and Hotel are configured with the Xen hypervisor so it was easy for users to move their virtual machines between the clouds when one of them was down for maintenance or to configure distributed experiments. We will be sad to see Sierra go, but in the meantime we made plans to facilitate the transition for our users.
In order to provide the same level of service, i.e., provide two closely integrated clouds such that users can move easily from one to the other, we will reconfigure Hotel such that the Nimbus Alamo cloud at TACC and the Nimbus Hotel cloud at University of Chicago support the same configuration. Since Alamo is configured with KVM, this will mean that the Hotel cloud will now also support KVM.
What this means to you: If you are using Nimbus on Sierra or Hotel it means that you will need to convert your images from Xen to KVM. We will of course provide guides on how to make this conversion as well as base KVM images that can be configured with user software. To allow our users time to make the change we will also operate both the Nimbus-Xen and Nimbus-KVM clouds at University of Chicago side by side for a month.
Timetable: The Hotel Nimbus-KVM cloud will become available on March 3rd and the Hotel Nimbus-Xen cloud will shut down on March 31st. The Sierra Nimbus-Xen cloud will become unavailable after March 3rd.
Both Alamo and Hotel also support OpenStack KVM-based clouds with complementary configurations used by an increasing number of projects. As you are migrating your work from the Hotel and Sierra Nimbus-Xen clouds, please consider using one of those clouds as well. The amount of physical resources allocated to Nimbus and OpenStack will be based on cloud utilization.
FutureGrid has decided to decommission the Nimbus Cloud on Sierra at San Diego Supercomputing Center.
Over the last several years Sierra and Hotel have been the two most used FutureGrid clouds. Sierra has fulfilled an important role for many Nimbus-based projects as a complement to Hotel: both Sierra and Hotel are configured with the Xen hypervisor so it was easy for users to move their virtual machines between the clouds when one of them was down for maintenance or to configure distributed experiments. We will be sad to see Sierra go, but in the meantime we made plans to facilitate the transition for our users.
In order to provide the same level of service, i.e., provide two closely integrated clouds such that users can move easily from one to the other, we will reconfigure Hotel such that the Nimbus Alamo cloud at TACC and the Nimbus Hotel cloud at University of Chicago support the same configuration. Since Alamo is configured with KVM, this will mean that the Hotel cloud will now also support KVM.
What this means to you: If you are using Nimbus on Sierra or Hotel it means that you will need to convert your images from Xen to KVM. We will of course provide guides on how to make this conversion as well as base KVM images that can be configured with user software. To allow our users time to make the change we will also operate both the Nimbus-Xen and Nimbus-KVM clouds at University of Chicago side by side for a month.
Timetable: The Hotel Nimbus-KVM cloud will become available on March 3rd and the Hotel Nimbus-Xen cloud will shut down on March 31st. The Sierra Nimbus-Xen cloud will become unavailable after March 3rd.
Both Alamo and Hotel also support OpenStack KVM-based clouds with complementary configurations used by an increasing number of projects. As you are migrating your work from the Hotel and Sierra Nimbus-Xen clouds, please consider using one of those clouds as well. The amount of physical resources allocated to Nimbus and OpenStack will be based on cloud utilization.
Subscribe to:
Posts (Atom)