Creating Virtual Machines 3.2

In OpenNebula the Virtual Machines are defined with Template definition files. This guide explains **how to describe the wanted-to-be-ran Virtual Machine, and how users typically interact with the system**. The Template Repository system allows OpenNebula administrators and users to register Virtual Machine definitions in the system, to be instantiated later as Virtual Machine instances. These Templates can be instantiated several times, and also shared with other users. {{INLINETOC}} ====== Virtual Machine Model ====== A Virtual Machine within the OpenNebula system consists of: * A capacity in terms memory and CPU * A set of NICs attached to one or more virtual networks * A set of **disk images**. * A state file (optional) or **recovery file**, that contains the memory image of a running VM plus some hypervisor specific information. The above items, plus some additional VM attributes like the OS kernel and context information to be used inside the VM, are specified in a template file. ====== What Is a Template ====== An OpenNebula Template is a Virtual Machine definition. These definitions are stored in a Template repository, which can be seen as a text template files storage with owner and privileges management, as well as the option to share Templates. OpenNebula Templates are designed to be hypervisor-agnostic, but still there are some peculiarities to be taken into account, and mandatory attributes change depending on the target hypervisor. Hypervisor specific information for this attributes can be found in the drivers configuration guides: * [[.:xeng|Xen Adaptor]] * [[.:kvmg|KVM Adaptor]] * [[.:evmwareg|VMware Adaptor]] OpenNebula has been designed to be easily extended, so any attribute name can be defined for later use in any OpenNebula module. There are some pre-defined attributes, though. Please check the [[.:template|Virtual Machine definition file]] reference for details on all the sections. ===== A VM Template Example ===== For example, the following template defines a VM with 512MB of memory and one CPU. The VM has three disks: * An OS Image previously registered in the [[.:img_guide | Image Repository]]. * A DATABLOCK Image called "Testing results". * And a swap partition. This disk is not using any Image from the repository; an empty file will be generated instead. Only one NIC is defined, attached to a [[.:vgg | Virtual Network]]. The context section will generate a CDROM with the files specified, that will be run at startup. Please read the [[.:cong | contextualization guide]] if you want to learn more about this feature. In this case, between all the suitable Hosts (those that meet CPU and MEMORY requirements, and also CPUSPEED > 1000 requirement), OpenNebula will pick the Host with more free CPU. $ oneimage list m ID USER GROUP NAME SIZE TYPE REGTIME PER STAT RVMS 3 oneadmin oneadmin Debian 6.0 10G OS 09/27 06:24:55 No rdy 0 5 oneadmin oneadmin Testing results 35G DB 09/27 06:44:00 No rdy 0 $ onevnet list a ID USER GROUP NAME TYPE BRIDGE LEASES 2 oneadmin oneadmin Public F vbr1 3 3 oneadmin oneadmin Red LAN R vbr0 2 6 oneuser users Private lab 3 F vbr2 0 $ cat vm-example.txt #--------------------------------------- # VM definition example #--------------------------------------- NAME = vm-example CPU = 1 MEMORY = 512 # --- kernel & boot device --- OS = [ kernel = "/vmlinuz", initrd = "/initrd.img", root = "sda" ] # --- 3 disks --- DISK = [ IMAGE_ID = 3 ] DISK = [ IMAGE_ID = 5 ] DISK = [ type = swap, size = 1024, readonly = "no" ] # --- 1 NIC --- NIC = [ NETWORK_ID = 3 ] # --- Placement options --- REQUIREMENTS = "CPUSPEED > 1000" RANK = FREECPU # --- Contextualization --- CONTEXT = [ files = "/service/init.sh /service/certificates /service/service.conf" ] The disks will be mounted as sda for the OS, sdb for the generated context CDROM, sdd for the swap disk, and sde for the "Testing results". This assignment schema is fully documented in the [[.:template | Virtual Machine template]] reference.
:!: Note that you can add as many ''DISK'' and ''NIC'' attributes as you need
====== Managing Templates ====== Users can manage the Template Repository using the command ''[[.:cli | onetemplate]]'', or the graphical interface [[.:sunstone|Sunstone]]. ===== Listing Available Templates ===== You can use the ''[[.:cli | onetemplate list]]'' command to check the available Templates in the system. $ onetemplate list a ID USER GROUP NAME REGTIME 0 oneadmin oneadmin template-0 09/27 09:37:00 1 oneuser users template-1 09/27 09:37:19 2 oneadmin oneadmin Ubuntu_server 09/27 09:37:42 To get complete information about a Template, use ''[[.:cli | onetemplate show]]'', or list Templates continuously with ''[[.:cli | onetemplate top]]''. Here is a view of templates tab in Sunstone: {{ :documentation:rel3.2:sunstone:templates_view.png?700 |}} ===== Adding and Deleting Templates ===== Using ''[[.:cli | onetemplate create]]'', users can create new Templates for private or shared use. The ''[[.:cli | onetemplate delete]]'' command allows the Template owner -or the OpenNebula administrator- to delete it from the repository. For instance, if the previous example template is written in the vm-example.txt file: $ onetemplate create vm-example.txt ID: 6 Via Sunstone, you can easily add templates using the provided wizards (or copy/pasting a template file) and delete them clicking on the delete button: {{ :documentation:rel3.2:sunstone:create_template.png?700 |}} ===== Updating a template ===== It is possible to update a template by using the ''[[.:cli | onetemplate update]]''. This will launch the editor defined in the variable ''EDITOR'' and let you edit the template. $ onetemplate update 3 In Sunstone you can select a template and update it easily as well: {{ :documentation:rel3.2:sunstone:update_template.png?700 |}} ===== Publishing Templates ===== The users can share their Templates with other users in their group, or with all the users in OpenNebula. See the [[.:chmod|Managing Permissions documentation]] for more information. Let's see a quick example. To share the Template 0 with users in the group, the **USE** right bit for **GROUP** must be set with the **chmod** command: $ onetemplate show 0 ... PERMISSIONS OWNER : um- GROUP : --- OTHER : --- $ onetemplate chmod 0 640 $ onetemplate show 0 ... PERMISSIONS OWNER : um- GROUP : u-- OTHER : --- The following command allows users in the same group **USE** and **MANAGE** the Template, and the rest of the users **USE** it: $ onetemplate chmod 0 664 $ onetemplate show 0 ... PERMISSIONS OWNER : um- GROUP : um- OTHER : u--
The commands ''[[.:cli | onetemplate publish]]'' and ''[[.:cli | onetemplate unpublish]]'' are still present for compatibility with previous versions. These commands set/unset
====== Instantiating Templates ====== The ''[[.:cli | onetemplate instantiate]]'' command accepts a Template ID or name, and creates a VM instance (you can define the number of instances using the ''--multiple num_of_instances'' option) from the given template. $ onetemplate instantiate 6 VM ID: 0 $ onevm list ID USER GROUP NAME STAT CPU MEM HOSTNAME TIME 0 oneuser1 users one-0 pend 0 0K 00 00:00:16 Instantation can be done through Sunstone by selecting one or several templates and pressing the "Instantiate" button. The OpenNebula Scheduler will deploy automatically the VMs in one of the available Hosts, if they meet the requirements. The deployment can be forced using the ''[[.:cli | onevm deploy]]'' command. Use ''[[.:cli | onevm shutdown]]'' to shutdown a running VM. Continue to the [[.:vm_guide_2|Managing Virtual Machine Instances Guide]] to learn more about the VM Life Cycle, and the available operations that can be performed.