It omits later stages including the network setup and eventual connectivity to services exposed by the VM instance. It takes into account the image format (raw disk file with or without partitions, VDI, VMDK wrapped into OVA) and the early boot stages: bootloader, init process. The categorisation of decisions to be taken by the application developer (more appropriately, packager) which triggers the associated limitations and faults is shown in the following table. This means that despite being assumed to be one of the most seasoned and reliable cloud computing services, EC2 still suffers from unnecessary limitations and runtime bugs. In particular, endless loops should never happen, and failure sources should be identified more clearly so that internal errors are not propagated to EC2 clients. Some failures can be assumed to be implementation bugs within EC2. non-bootable images) or caused by limitations of EC2’s hypervisor setup (using Xen and PV-Grub) compared to local hypervisors. Most failures are deterministic, either caused by issues already present in the VM image (e.g. IMPORTIMAGETASKS MyVM import-ami-xxxxxxxx active booting IMPORTIMAGETASKS MyVM import-ami-xxxxxxxx active ServerError: an internal error has occurred during conversion. IMPORTIMAGETASKS MyVM import-ami-xxxxxxxx deleted ClientError: Disk validation failed IMPORTIMAGETASKS MyVM import-ami-xxxxxxxx deleted ClientError: Unsupported kernel version 3.16.0-4-686-pae IMPORTIMAGETASKS MyVM import-ami-xxxxxxxx deleted ClientError: No valid partitions. The failures manifest as follows in human-readable text format: IMPORTIMAGETASKS MyVM import-ami-xxxxxxxx deleted ClientError: Unknown OS / Missing OS files.
Using the command-line tool aws ec2 describe-import-image-tasks The estimation for converting is clearly too conservative using a value of 20 instead of 28 would be more appropriate. Some of the values are hard-coded estimations. Timed state transitions of a virtual machine imported into AWS EC2. In the following figure, which represents measurements with a typical small image file of about 500 MiB, success is measured by a north-bound transition, failure by a south-bound one, and an endless loop by an east-bound one. The transitions can be divided into success, failure and endless loops. a few more which are probably not by design, as shown below.However, by experimental use of the service, logging the (sub-)state every second, and extracting the timed state transitions, we found out that at least 12 distinct states exist. According to the states documentation, there would be four states: active, deleting, deleted, completed. The first step towards explaining the EC2 import process is to represent it as abstract state machine with transitions. Hence, this blog post offers a detailed walk-through and points out common pitfalls. This import process is not well-documented and regularly causes high effort with application providers. This involves creating the machine image, testing it on a local hypervisor (KVM, Xen, VirtualBox, …) or in a local cloud stack (OpenStack, CloudStack, OpenNebula, …), then copying the image into the Simple Storage Service (S3) (in a reliable manner), initiating the import process, and waiting for the VM image called Amazon Machine Image (AMI) to become available.
Ultimately, for custom applications, it also possible to import custom VM images. From an application perspective, hosting in EC2 means wrapping the application into one of the provided virtual machine (VM) images and instantiating it in sufficient numbers (e.g. The Elastic Compute Cloud (EC2) offered by AWS as public commercial service has been one of the first and probably the seminal service for the research on cloud applications and infrastructure.
0 kommentar(er)
