Creating a VM template#
In OpenNebula the virtual machines are defined with VM templates.
VM Templates allow OpenNebula users to register virtual machine definitions in the system, to be instantiated later as virtual machine instances. These templates can be re-used, and also shared with other users.
Defining a VM#
A virtual machine within OpenNebula 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
Optional attributes like VNC graphics, the booting order, context information, etc.
Step by step guide#
To create a VM template click on the Templates > VM in the menu on the left of the screen
This screen displays a list of the templates you currently have access to
To create a new template click the green plus button > create.
This will open a new blank template
The general tab#
The first screen you need to complete is the “General” screen. In the above screenshot I have completed all of the fields with examples.
Name: Name of the template
Hypervisor: This is normally KVM There is on LXD host that can be used to run LXD based VM’s (nebulalxd01)
Description: Some kind of description of the VM. Very useful to put credentials required to access the machine here if necessary.
Logo: The logo of the OS
Memory: Default amount of RAM for the VM
CPU: Default number of CPU’s for the VM
VCPU: Default Number or Virtual CPU’s for the VM Memory / CPU / VCPU modification: You can use these drop down lists to control if, and how, these template values can be customised when creating an Instance using this template.
You can set it to “fixed” if you do not want to allow these values to be changed, or in the example above I have set them to “list” and provided a list of acceptable customisable values for this template.
Do not allow to modify network configuration: Tick this box if you want to “lock in” the network config you set on this template (under the network tab) so it cannot be changed when creating VM’s with this template.
When you have finished completing all the information on the General screen click on the storage tab
The Storage tab#
This screen is very important. It allows you to select the image you want to use for your VM’s disk. In this example I am using the custom image I created earlier.
Once you have selected the image you want to use click on the network tab
The Network tab#
The network tab is entirely optional. If you don’t want the VM to connect to any virtual networks you can skip it.
This screen allows to add virtual NIC’s or Network interfaces to your VM and assign each of them to a virtual network. You can add as many or few as you like.
Unless you ticked the “Do not allow to modify network configuration” box on the general tab, any network config you create here will only be a default config for the template. It will not be “locked in” and it will be possible to change it when instantiating an image.
Warning
If you want the VM to connect to a virtual network then it is important that you put “virtio” in the “default hardware model to emulate for all NIC’s” field, as shown in the image above
The next tab is OS & CPU
The OS & CPU tab#
This tab is optional and you can skip it. However, there are many settings here that can help you optimise the performance of your VM.
As a minimum we recommend you set the CPU model to “host-passthrough” this will pass the actual CPU model of the host system through to the guest VM’s operating system.
Note
If you would like an explanation of any of the fields in the OS & CPU screen you can mouseover the small question mark symbol next to the fields name
The next tab is Input/Output
The Input/Output tab#
This screen allows you to configure how you will interact with your VM once its instantiated.
We recommend using SPICE to connect to your VM as it performs better than VNC in our experience (if you are using a SPICE client). It also gives you full clipboard support for copy paste and it does USB device pass through. More details can be found on the page on connecting to an instance.
You can use VNC if you prefer, it will work and might give slightly better performance if you only intend on interacting with your VM via the browser interface in OpenNebula.
Its recommended that you leave the fields “Listen on IP”, “Server port” and “Keymap” at their default values. OpenNebula will automatically generate a port for SPICE/VNC for you when the VM is instantiated.
You can tick the box “Generate random password” if you want to password protect your VNC / SPICE session. To be clear this does not set a password on the VM itself. This just prevents others from connecting to your VNC / SPICE session without a password. You can define this password manually by completing the “password” field.
If you are creating an LXD virtual machine you can use the “Command” field to set the login command when viewing the machine via VNC (this defaults to /bin/login).
The Context tab#
Note
OpenNebula uses a method called contextualization to send information to the VM at boot time. Its most basic usage is to share networking configuration and login credentials with the VM so it can be configured. This section does not include a detailed explanation of contextualisation, if you would like more information on this topic please see the documentation ?
We recommend you ensure that the “add SSH contextualization” and “add Network contextualisation” fields are checked. This will allow OpenNebula to inject ssh keys at boot and dynamically configure network at boot.
You can provide an SSH public key if there is one you would like to be on every instance created from this template. If you do not provide a key OpenNebula will add the users associated ssh key by default.
Context, Custom Variables#
Also on the context tab is the “Custom vars” screen which allows you to add your own custom contextualisation variables. If you want to create a custom user or set a password this where you do it.
If you do not provide a USERNAME variable then the root user will be assumed.
Note
For other supported contextualisation variables please see the OpenNebula context documentation.
Warning
In order for any of the “context” configuration to work the VM images must have the OpenNebula contextualisation package installed. All of the base images provided by IT Services will have this installed. This is something to be aware of in case you are working with images from other sources or perhaps your own custom images.
Scheduling#
This page allows you to tell OpenNebula on which nodes your VM is allowed to run. Use the expression box under the Host Placement section with the below options:
Note
For KVM based VMs use: ID="2" | ID="3" | ID="4" | ID="5" | ID="6" | ID="7" | ID="8"
Note
For LXD based VMs use: ID="11"
Attention
Please make sure you enter an expression! Otherwise your machines might try to start on an incompatible host
Permissions#
Note
The VM template you have created is currently owned by your user, and by default you are the only user permitted to use it.
If you would like to “publish” your template to allow others to create VM’s with it then you will need to edit the permissions of the template.
On the template screen you should now see your new template in the list of templates.
VM templates#
Click on your template and it will open the template info screen.
On this screen you can see the set permissions on the right-hand side.
Template Info screen#
To make your template public so others can use it, tick the “use” box on the row for “others”
Your template is now publicly available for use by other OpenNebula users.
Warning
You need to make sure the permissions are correct on the VM template and the VM image. If other users don’t have permission to use BOTH then they will receive an error message when trying to create an instance. Likewise, If you have created a virtual network for others to use you will need to make sure you have granted USE permissions on the virtual network too.