X

Pat Shuff's Blog

  • Iaas
    August 17, 2016

uploading custom boot image for compute cloud

One of the things that we talked about yesterday was uploading an image for a bundled solution into the Oracle Cloud Marketplace. Partners can register to bundle and sell solutions on the Oracle Cloud by providing a bootable image and have that image run in the Oracle Compute Cloud. Some examples of this are
All of these solutions started with a base operating system and layered other products onto the operating system. They then took the resulting virtual machine configuration and bundled it into a tar.gz file and uploaded it to the Marketplace. Once this is done it can be offered as a product through the search engine and tracked, marketed, and sold by the partner. The resulting boot image is loaded into your private images and allows you to boot these instances as a compute service where you select the processor, memory, disk, and network configurations. The beauty of this interface is that it is the same that you would use if you wanted to create a custom boot image of your own. This enables features like snapshots of instances so that you can clone instances, replicate instances for scaling, and backup instances to a common storage location for fast disaster recovery.

Before we dive into how to create a bootable image for the Oracle Compute Cloud, let's review some basics so that we have the same terminology and a common language to discuss how to take an instance from your data center and run it in the Oracle Compute Cloud. We will also look at the steps needed for AWS and Azure and what it takes to upload an image to their compute clouds. Some of the different ways that you can run an application in your data center are

  • Bare Metal - load an operating system on a computer and load applications on the operating system. Backup the instance and restore into cloud
  • Oracle VirtualBox - create a virtual instance on your desktop/laptop/server and convert the resulting OVA/VDI into an uploadable format
  • VMWare ESX - create a virtual instance on your VMWare cluster and convert the resulting VMDK images into an uploadable format
  • Citrix or public domain Xen Server - create a virtual instance on your Xen server and convert the VMDK images into an uploadable format
  • Microsoft HyperV - create a virtual instance on your HyperV server and convert the VHD image into an uploadable format

The key difference between all of these steps are the conversion into an uploadable format for the target cloud provider. Oracle Compute Cloud currently requires that you create a tar.gz binary from a supported operating system and load it into your private image space. Documentation on creating your own image is available from Oracle and goes into detail on what operating systems are currently supported and references a Tutorial on building a LAMP Stack instance. In this example the tutorial uses VirtualBox to boot from an iso that is downloaded from edelivery.oracle.com which is the traditional way of building an image on bare metal or a virtual server.

We will not go through the installation process with images as we usually do because the tutorial does a very good job of showing you how to do this. The process takes a while (budget a half day) to setup VirtualBox, download the iso image, load and boot the Linux instance, patch the instance, install the Apache Web Server, MySQL, and PHP. The most difficult part of this is configuration of the network. The tutorial suggests that you turn off selinux and iptables. We suggest that you go to the extra effort to enable these services and open up the ports needed to communicate to your services. Leaving these services open inside any cloud providers internal network and relying upon the external firewall and routing rules is a slippery slope to insecurity. We suggest multiple layers of security at the cloud admin layer, at the network configuration layer with whitelist routing, and at the operating system layer. You might need to first allow connection to port 80 from anywhere at the operating system layer and tighten up these rules once you know where your clients are coming from but turning off security in the operating system is not recommended.

Microsoft provides a writeup on how to import a Linux image which could be configured with the LAMP stack. It is important to note that the article assumes that you are starting with a VHD file or have converted your existing file format into VHD for upload. The writeup also assumes that you have the Azure Command Line or PowerShell configured and installed which again assumes that you are starting with a Windows desktop to do the heavy lifting. There are few blogs that detail how to do this. Most recommend using Bitnami to load images or load a Linux image and rebuild the instance in Azure rather than building one of your own and uploading it. Most of the blog entries talk about having the para-virtual drivers installed to enable HyperV to properly work once the image is running.

Amazon provides a good documentation and tutorials on importing images from VMWare, Windows, and other formats. Their tools allow for either command line import or web based imports and converts them to Amazon AMI format. It is important to note that once you have imported the images you do need to reconfigure networking and security as must be done with almost all of the other cloud vendor solutions. The only true exception to this is Ravello Systems which is available in the Amazon, Google, Azure, and the Oracle Cloud. Ravello allows you to import your VMWare images unchanged and run them in all four cloud providers. Note that this is different from converting it to a runnable image in the cloud provider format. Ravello uses a hypervisor emulator that uploads a shim to translate VMWare calls into cloud provider calls and interfaces.

In summary, all of the cloud providers allow you to import existing in house images into their cloud. All use a format translator to translate the original format into the cloud provider format. The single exception is using the Ravello import utility that takes VMWare format and imports it unchanged and runs it in the cloud provider of your choice. The key difference between the different import mechanisms are what tools are needed. Do you need to start with a Windows desktop and use PowerShell to import the image? Do you need to install a command line utility that runs on most operating systems and convert your image to a custom image? Can you upload and download the image from the cloud provider to maintain version control in your data center? Does the cloud provider have the ability to run these images in your data center as if they were cloud services on a machine under your security umbrella? The more we dive into topics the less we seem to get answers but more and more questions. Hopefully today's blog gives you more insight into running existing applications on different cloud vendor platforms and what control you give up, what options you have, and what it takes to import virtual images from your data center into a cloud solution.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha