Glossary

A short list of terms useful to understand the proposed service.

Cloud computing
an approach to share resources based on virtualization techniques.
Virtualization
the capability of a system (i. e., a physical machine, also called worker node or host, as detailed later) to deliver to the users full access to part of its resources.
Resources – also physical resources
Namely: CPU(s), RAM memory, network access, and disk space.
Virtual machine
a set of physical resources instantiated, that is delivered, and available to the end user. It is often shorted as VM. In our offer, the owner of the VM (the user who created it) is granted full access by means of a full operating system (OS) runnning on top of the resources. The user is asked to configure and customize the desired OS, while the service administrator will also provide all the needed support. In a service model oriented classification this is known as Infrastructure as a Service (IaaS).
Virtual resources
the subset of resources assigned to a VM, as seen from inside the VM. It is common to talk about virtual CPU(s), virtual RAM, virtual disk(s) and virtual network interface(s) to refer to the share of CPU(s) power, RAM, disk space, and network access assigned to a VM.
Quota
The amount of physical resources made available to a user or to a group to deploy one or more VMs. The concept of quota is related to how much of the total physical resources provided by LRZ a user or a group can use.
Guest
another way to refer to a VM. It stands for guest operating system since it runs on top of the operating system of the machine sharing the physical resources.
Worker node
a physical machine sharing its physical resources to one or more VM. The worker node hosts one or more guests (or virtual machines).
Host
an alternative term for a worker node.
Hypervisor
the software layer used to deliver and manage the virtualized resources, from the administrator's point of view. Our offer is based on the Kernel-based Virtual Machine (KVM) hypervisor.
Cloud middleware
a software layer intefacing in a friendly way the user to the hypervisor. In our view, this component performs the remote virtualization. We talk about virtualization since the user is capable of creating VMs and it is remote since the user accomplishes this task over the Internet, sitting in his/her location while the worker nodes are located at the LRZ. The cloud middleware we chose is OpenNebula.
Frontend
the machine hosting the user interface of the cloud middleware. The URL is www.cloud.mwn.de. It offers also a graphical GUI, via HTTPS as well.
Disk image
a file that is mounted by a VM as a disk or a CDROM. These are the available types:
OS
it contains the operating system, the kernel, the bootloader and all the files to start the operating system of the VM.
DATABLOCK
it is the equivalent of a spare data disk, attached on the fly to save files and data.
CDROM
it is the equivalent of an external CDROM (so, read-only), used especially for the installation of a guest OS on a DATABLOCK
Disk format
the structure of a disk image file. The only supported formats are:
raw
a plain binary file, obtained simply dumping the content of a disk. CDROM ISO images fall into this category.
qcow2
a more recent format, implementing features such as compression and copy-on-write (growing the image size on the fly till hitting the maximum assigned at creation time).
Volatile disk
swap or storage space attached to a VM, deployed directly on the worker node, without the possibility to take a disk snapshot.
Disk Snapshot
a copy of a disk image available for later use. It is available in two variants:
Hot snapshot
the disk image is dumped right away. The consistency of the disk is not guaranteed (i.e., a filesystem check could be needed after attaching the disk to the VM and before mounting it inside the guest OS). It is suitable for data partitions.
Deferred snapshot
the disk image is dumped at the end of the VM's lifetime (i.e., when it is shutdown via the ONE web interface; the "shut down" command from inside the guest OS is not enough). If the shutdown process is carried out correctly by the VM, then the disk image is consistent, that is, no filesystem check is required. For this reason, it is suitable for disk images used to boot the VMs.
VM Snapshot
it records the status and the content of a VM's memory and the VM's disk(s). It does not produce a new image (see Disk Snapshot) and its lifetime ends with the VM itself. It only works if all disk images attached to the VM are in qcow2 format.
Datastore
a component of the cloud middleware, it is a container for the disk images and the disk snapshots. There are two types:
Image datastore
it contains the disk images and the disk snapshots. It can be accessed directly by the users;
System datastore
it contains the volatile disks and the copy of the image disks of the running VMs. It is the workspace of the worker nodes and it is not directly accessible.
Template
it can be seen as the container holding together all the items (images, number of CPUs, memory allocation, virtual networks, ...) defining a VM.
virtio
a virtualization standard for disk and network interfaces. It is a guest feature, so it has to be supported by the operating system of the VM (e.g., Linux kernel greater or equal to 2.6.25). Usually the hypervisor emulates the disk interface (IDE or SCSI) and the network card (RTL8139), adding an additional overhead. The virtio is native, so the guest interfaces directly to the host. The LRZ OpenNebula instance sets virtio as the default interface for disks and networking devices. Please refer to the linked sections for more details.
State
It is the stage of a VM's life cycle. Please refer to the full documentationfor more details. The most relevant of these steps are:
Pending
the cloud middleware is looking for free and suitable resources.
Prolog
the cloud middleware is copying the disk images from the image datastore to the system datastore.
Booting
the hypervisor is deploying the VM.
Running
the VM is alive and available to the user(s).
Hotplug
a disk or a network card is being attached/detached.
Power off
result of a Power off operation: VM not available, all disks saved, content of the RAM not dumped, CPUs on the worker node not freed (keeping on charging for the usage).
Undeploy
result of a Undeploy operation: VM not available, all disks saved, content of the RAM not dumped, CPUs on the worker node freed.
Save
one or more disks being dumped or copied (i.e., snapshot).
Epilog
clean up of the worker node after the decommission of the VM.
Fail
irreversible error
Unknown
the cloud middleware can not monitor the VM.
Permissions
a user can trim the capability of him/her self (Owner), the members of his/her group (Group) and all other users (Others) to operate on the Templates, the Images, the Virtual networks and the VMs he/she owns. A full description is available here, however, like a Unix system, permissions can be granted on three different levels:
Use
access the item without modifying it;
Modify
change and update the item;
Admin
manage the item (reserved to the service administrator, not effective for regular users).
Service administrator
the team responsible for the infrastructure at the Leibniz Supercomputing Centre, reachable at cloud-support@lrz.de or by means of the LRZ Service Desk.
Budget
the total amount of CPU-hours a group is allowed to use for running VMs. Each physical core used in a VM counts as one CPU. For example, if the user asks for a VM with four cores, after one hour he/she will be charged for four CPU-hours. The concept of budget is a measure of how long a user or a group can use the assigned resources (quota).