View source for Managing your cloud resources with OpenStack

<languages />
<translate>
<!--T:1-->
''Parent page: [[Cloud]]''

<!--T:2-->
OpenStack is the software suite used on Compute Canada clouds to control hardware resources such as computers, storage and networking. It allows the creation and management of virtual machines ("VMs", or "instances"), which act like separate individual machines, by emulation in software. This allows users complete control over their computing environment, from choosing an operating system to software installation and configuration. Diverse use cases are supported, from hosting websites to creating virtual clusters. More documentation on OpenStack can be found at the [http://docs.openstack.org/ OpenStack web site].

<!--T:63-->
This page describes how to perform common tasks encountered while working with OpenStack. It is assumed that you have already read [[Cloud Quick Start]] and understand the basic operations of launching and connecting to a VM. Most tasks can be performed using either the dashboard (as described below), [[OpenStack Command Line Clients|CLI]], or a tool called [[Terraform]]; however, some tasks require using command line tools, for example [[#Sharing_an_image_with_another_project|sharing an image with another project]].

=Projects= <!--T:64-->
OpenStack projects group VMs together and provide a quota out of which VMs and related resources can be created. A project is unique to a particular cloud. All accounts which are members of a project have the same level of permissions, meaning anyone can create or delete a VM within a project if they are a member. You can view the projects you are a member of by logging into an OpenStack dashboard for the clouds you have access to (see [[Cloud#Using_the_Cloud|using the cloud]] for a list of cloud URLs). The active '''project name''' will be displayed in the top left of the dashboard, to the right of the cloud logo. If you are a member of more than one project, you can switch between active projects by clicking on the dropdown menu and selecting the project's name.

<!--T:74-->
Depending on your allocation, your project may be limited to certain types of VM [[Virtual_machine_flavors|flavors]]. For example, compute allocations will generally only allow "c" flavors, while persistent allocations will generally only allow "p" flavors.

<!--T:75-->
Projects can be thought of as owned by primary investigators (PIs) and new projects and quota adjustments can only be requested by PIs. In addition, request for access to an existing project must be confirmed by the PI owning the project.

=Availability Zones= <!--T:72-->
Availability zones allow you to indicate what group of physical hardware you would like your VM to run on. On East and Graham clouds, there is only one availability zone, ''nova'', so there isn't any choice in the matter. However, on Arbutus there are three availability zones: ''Compute'', ''Persistent_01'', and ''Persistent_02''. The ''Compute'' and ''Persistent'' zones only run compute or persistent flavors respectively (see [[virtual machine flavors]]). Using two persistent zones can present an advantage; for example, two instances of a website can run in two different zones to ensure its continuous availability in the case where one of the sites goes down.

=Security Groups= <!--T:3-->
A security group is a set of rules to control network traffic into and out of your virtual machines. To manage security groups, go to ''Project->Network->Security Groups''. You will see a list of currently defined security groups. If you have not previously defined any security groups, there will be a single default security group. 

<!--T:4-->
To add or remove rules from a security group, click ''Manage Rules'' beside that group. When the group description is displayed, you can add or remove rules by clicking the ''+Add Rule'' and ''Delete Rule'' buttons. 

== Default security group == <!--T:5-->
[[File:Default_security_group_EN.png|400px|thumb| Default Security Group Rules (Click for larger image)]]
The '''default security group''' contains rules which allow a VM access out to the internet, for example to download operating system upgrades or package installations, but does not allow another machine to access it, except for other VMs belonging to the same default security group. We recommend you do not remove rules from the default security group as this may cause problems when creating new VMs. The image on the right shows the default security group rules that should be present:
* 2 Egress rules to allow your instance to access an outside network without any limitation; there is one rule for IPV4 and one for IPV6.
* 2 Ingress rules to allow communication for all the VMs that belong to that security group, for both IPV4 and IPV6.
It is safe to add rules to the default security group and you may recall that we did this in [[Cloud Quick Start]] by either adding security rules for [[Creating_a_Linux_VM#Firewall.2C_add_rules_to_allow_SSH|SSH]] or [[Creating_a_Windows_VM#Firewall.2C_add_rules_to_allow_RDP|RDP]] to your default security group so that you could connect to your VM.

== Managing security groups == <!--T:6-->
You can define multiple security groups and a VM can belong to more than one security group. When deciding on how to manage your security groups and rules, think carefully about what needs to be accessed and who needs to access it. Strive to minimize the IP addresses and ports in your Ingress rules. For example, if you will always be connecting to your VM via SSH from the same computer with a static IP, it makes sense to allow SSH access only from that IP. To specify the allowed IP or IP range, use the [[OpenStack#Using_CIDR_rules|CIDR]] box (use this web based tool for converting [http://www.ipaddressguide.com/cidr IP ranges to CIDR] rules). Further, if you only need to connect to one VM via SSH from the outside and then can use that as a gateway to any other cloud VMs, it makes sense to put the SSH rule in a separate security group and add that group only to the gateway VM. However, you will also need to ensure your SSH keys are configured correctly to allow you to use SSH between VMs (see [[SSH Keys]]). In addition to CIDR, security rules can be limited within a project using security groups. For example, you can configure a security rule for a VM in your project running a MySQL Database to be accessible from other VMs in the default security group.

<!--T:7-->
The security groups a VM belongs to can be chosen when it is created on the ''Launch Instance'' with the ''Security Groups'' option, or after the VM has been launched by selecting ''Edit Security Groups'' from the dropdown menu of actions for the VM on the ''Project->Compute->Instances'' page.

==Using CIDR rules== <!--T:67-->
CIDR stands for Classless Inter-Domain Routing and is a standardized way of defining IP ranges (see also this wikipedia page on [https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing CIDR]).

<!--T:68-->
An example of a CIDR rule is <code>192.168.1.1/24</code>. This looks just like a normal IP address with a <code>/24</code> appended to it. IP addresses are made up of 4, 1-byte (8 bit) numbers ranging from 0 to 255. What this <code>/24</code> means is that this CIDR rule will match the first left most 24 bits (3 bytes) of an IP address. In this case, any IP address starting with <code>192.168.1</code> will match this CIDR rule. If <code>/32</code> is appended, the full 32 bits of the IP address must match exactly; if <code>/0</code> is appended, no bits must match and therefore any IP address will match it.

=Working with Volumes= <!--T:8-->

<!--T:77-->
A volume provides storage which is not destroyed when a VM is terminated. On Compute Canada clouds, volumes use [https://en.wikipedia.org/wiki/Ceph_(software) Ceph] storage with either a 3-fold replication factor or [https://en.wikipedia.org/wiki/Erasure_code erasure codes] to provide safety against hardware failure. On arbutus the ''Default'' volume type uses erasure codes to provide data safety while reducing the extra storage costs of 3-fold replication while the ''OS or Database'' volume type still uses the 3-fold replication factor. The More documentation about OpenStack volumes can be found [https://docs.openstack.org/cinder/latest/cli/cli-manage-volumes.html here]

==Creating a Volume== <!--T:9-->

<!--T:76-->
[[File:Creating_a_volume_EN.png|300px|thumb| Create Volume dialog (Click for larger image)]]

<!--T:11-->
To create a volume click [[File:Create-Volume-Button.png]] and fill in the following fields:

<!--T:12-->
*Volume Name: <code>data</code>, for example<br/>
*Description: Optional text
*Volume Source: <code>No source, empty volume</code><br/>
*Type: <code>No volume type</code><br/>
*Size (GiB): <code>40</code>, or some suitable size for your data or operating system<br/>
*Availability Zone: On the East and Arbutus clouds, the only option is <code>nova</code><br/>

<!--T:13-->
Finally click the blue "Create Volume" button.

==Accessing a Volume from a VM== <!--T:14-->
[[File:Manage_attachments_EN.png|400px|thumb| Managing attachments command in Actions menu (Click for larger image)]]
To access the volume you must first '''attach''' it to a running VM. This is analogous to inserting a USB key or plugging an external drive into your personal computer. You can attach a volume from the Volumes page.
* At the right-hand end of the line describing the volume is the Actions column; from the dropdown menu, select "Manage Attachments".
* In the "Attach To Instance" dropdown menu, select a VM. 
* Click the blue "Attach Volume" button. 
The process should complete in a few seconds. Then the Volumes page will show the newly created volume attached to your selected VM on <code>/dev/vdb</code> or some similar location.

==Formatting and Mounting an Empty Volume== <!--T:15-->
Before a newly created and attached volume can be used it must be formatted and mounted. See instructions for doing this on a [[Using a new empty volume on a Linux VM|Linux]] or [[Using a new empty volume on a Windows VM|Windows]] VM.

==Booting from a Volume== <!--T:22-->
If you want to run a persistent machine, it is safest to boot from a volume. When you boot a VM from an image rather than a volume, the VM is stored on the local disk of the actual machine running the VM. If something goes wrong with that machine or its disk the VM may be lost. Volume storage has redundancy which protects the VM from hardware failure. Typically when booting from a volume VM flavors starting with a 'p' are used (see [[Virtual machine flavors]]).

<!--T:23-->
There are several ways to boot a VM from a volume. You can 
* boot from an image, creating a new volume, or 
* boot from a pre-existing volume, or
* boot from a volume snapshot, creating a new volume.

<!--T:24-->
If you have not done this before, then the first one is your only option. The other two are only possible if you have already created a bootable volume or a volume snapshot.

<!--T:25-->
If creating a volume as part of the process of launching the VM, select <code>Boot from image (creates a new volume)</code>, select the image to use, and the size of the volume. If this volume is something you would like to remain longer than the VM ensure that the "Delete on Terminate" box is unchecked. If you are unsure about this option, it is better to leave this box unchecked. You can manually delete the volume later.

==Creating an Image from a Volume== <!--T:26-->
[[File:Upload_volume_from_image_EN.png|400px|thumb| Upload to Image form (Click for larger image)]]<!--Note to translator: there is a FR version of this screen shot at [[File:Os-upload-volume-to-image-fr.png]]-->
Creating an image from a volume allows you to download the image. Do this if you want to save it as a backup, or to spin up a VM somewhere other than the CC Cloud, e.g. with [https://www.virtualbox.org/ VirtualBox]. If you want to copy a volume to a new volume within the same cloud see [[#Cloning a Volume|cloning a volume]] instead. To create an image of a volume, it must first be detached from a VM. If it is a boot volume, it can only be detached from a VM if the VM is terminated/deleted.

===Using the Dashboard=== <!--T:53-->
# Click on the ''Volumes'' left hand menu.
# Under the volume you wish to create an image of click on the drop down ''Actions'' menu and select ''Upload to Image''.
# Choose a name for your new image.
# Choose a ''Disk Format''. QCOW2 is recommended for using within the OpenStack cloud as it is relatively compact compared to Raw image format and works well with OpenStack. If you wish to use the image with Virtualbox the vmdk or vdi image formats might be better suited.
# Finally click ''Upload''.

===Using the Command Line Clients=== <!--T:27-->
The [[OpenStack Command Line Clients|command line client]] can do this:
{{Command|openstack image create --disk-format <format> --volume <volume_name> <image_name>}}
where 
* <format> is the disk format (two possible values are [https://en.wikipedia.org/wiki/Qcow qcow2] and [https://en.wikipedia.org/wiki/VMDK vmdk]),
* <volume_name> can be found from the OpenStack dashboard by clicking on the volume name, and
* <image_name> is a name you choose for the image.
You can then [[OpenStack#Downloading an image |download the image]] as described below. It is best to detach the volume from the VM before you create an image from the volume. If the volume is a boot volume you will likely need to delete your VM to detach it, however, make sure you have not checked "Delete Volume on Instance Delete" when creating the VM.

==Cloning a Volume== <!--T:73-->
Cloning is the recommended method for copying volumes. While it is possible to make an image of an existing volume and use it to create a new volume, cloning is much faster and requires less movement of data behind the scenes. This method is handy if you have a persistent VM and you want to test out something before doing it on your production site. It is highly recommended to shut down your VM before creating a clone of the volume as the newly created volume may be left in an inconsistent state if there was writing to the source volume during the time the clone was created. To create a clone you must use the [[OpenStack Command Line Clients|command line client]] with this command
{{Command|openstack volume create --source <source-volume-id> --size <size-of-new-volume> <name-of-new-volume>}}

==Detaching a Volume== <!--T:85-->
Before detaching a volume, it is important to make sure that the operating system and other programs running on your VM are not accessing files on this volume. If so, the detached volume can be left in a corrupted state or the programs could show unexpected behaviours. To avoid this, you can either shut down the VM before you detach the volume or [[Using_a_new_empty_volume_on_a_Linux_VM#Unmounting_a_volume_or_device|unmount the volume]].

<!--T:86-->
To detach a volume, log in to the OpenStack dashboard (see the [[Cloud#Using_the_Cloud|list of links]]) and select the project containing the volume you wish to detach. Selecting ''Volumes -> Volumes'' displays the project’s volumes. For each volume, the ''Attached to'' column indicates where the volume is attached. 

<!--T:87-->
*If attached to <code>/dev/vda</code>, it is a boot volume; you must delete the attached VM before the volume can be detached otherwise you will get the error message ''Unable to detach volume''.

<!--T:88-->
*With volumes attached to <code>/dev/vdb</code>, <code>/dev/vdc</code>, etc. you do not need to delete the VM it is attached to before proceeding. In the ''Actions'' column dropdown list, select ''Manage Attachments'', click on the ''Detach Volume'' button and again on the next ''Detach Volume'' button to confirm.

=Working with images= <!--T:42-->

<!--T:81-->
Images are files which contain the contents of a virtual disk. Often Images contain a base operating system used to create a volume or an ephemeral disk from which a virtual machine boots. An ephemeral disk is a virtual disk file which resides on the host (or hypervisor) where the virtual machine runs. Ephemeral disk files are destroyed when a VM is destroyed, in contrast to [[OpenStack#Working with Volumes|volumes]]. Images are portable in that they can be download from the cloud, used to create a virtual machine using virtual box or similar on your laptop, and uploaded to another cloud and used to create a new virtual machine. This is not the case with volumes or ephemeral disks. Images come in a variety of formats. Some commonly encountered formats are, raw, qcow2, vmdk, and vdi.

<!--T:82-->
If sharing your virtual machine images, be sure to remove sensitive information such as public/private keys, configuration files containing passwords etc. If uploading an image created from a virtual box virtual machine to the Compute Canada clouds it must have cloud-init installed and configured correctly (see openstack docs on [https://docs.openstack.org/image-guide/create-images-manually.html creating images manually] for more details).

<!--T:83-->
For a list of images provided by staff on Compute Canada clouds see [[Cloud resources#Images| images]].

==Creating an Image from a VM== <!--T:84-->
The procedure for creating an image of a VM depends on whether it is booting from a volume (typically "p" flavors), or from an ephemeral disk (typically "c" flavors).

===If booting from an ephemeral disk=== <!--T:79-->
the [[OpenStack Command Line Clients]] can be used with the command:
{{Command| openstack server image create <server-name>}}
where <code><server-name></code> should be replaced with the name of your server. This action will only include the VM's root drive (e.g. /dev/vda) in the image. Ephemeral drives and non-boot attached volumes will not be included in the image so additional measures should be taken to preserve this data. In addition, if the VM is writing to disk while the image is being created the filesystem may be captured in an inconsistent state. We recommend the VM be shut off (not deleted) before an image is created from it.

===If booting from a volume=== <!--T:80-->
see [[OpenStack#Creating_an_Image_from_a_Volume|Creating an Image from a Volume]]

==Sharing an image with another project== <!--T:54-->
Sharing an image with another project is a two step process.

<!--T:55-->
# A member of the project owning the image must share it with a second project.
# A member of the second project must accept the newly shared image.

<!--T:56-->
To share an image a member in the project owning the image uses the [[OpenStack Command Line Clients|OpenStack]] command below.
<source lang="console">
[name@server]$  glance member-create <IMAGE_ID> <MEMBER_ID>
+------------+-------------+---------+
| Image ID   | Member ID   | Status  |
+------------+-------------+---------+
| <IMAGE_ID> | <MEMBER_ID> | pending |
+------------+-------------+---------+
</source>
where
<code><IMAGE_ID></code> is the ID of image to be shared, and <code><MEMBER_ID></code> is the ID of project to share with. 

<!--T:57-->
To accept the shared image a member in the second project uses the [[OpenStack_Command_Line_Clients#Separate_Command-line_interfaces|OpenStack]] command below.
<source lang="console">
[name@server]$  glance member-update <IMAGE_ID> <MEMBER_ID> <MEMBER_STATUS>
+------------+-------------+----------+
| Image ID   | Member ID   | Status   |
+------------+-------------+----------+
| <IMAGE_ID> | <MEMBER_ID> | accepted |
+------------+-------------+----------+
</source>
where <code><IMAGE_ID></code> is ID of the image to update, <code><MEMBER_ID></code> is the ID of the second project, and <code><MEMBER_STATUS></code> is the new status of the image. Valid Values for status are <code>accepted</code>, <code>rejected</code>, and <code>pending</code>. The image will then be available for use and appear in the OpenStack dashboard's list of images in the second project.

<!--T:58-->
To check the status of image membership use the below command.
<source lang="console">
[name@server]$ glance member-list --image-id <IMAGE_ID>
+------------+-------------+----------+
| Image ID   | Member ID   | Status   |
+------------+-------------+----------+
| <IMAGE_ID> | <MEMBER_ID> | accepted |
+------------+-------------+----------+
</source>
where <code><IMAGE_ID></code> is the ID of the image to check the membership status of.

==Downloading an Image== <!--T:38-->
The first step is to install the OpenStack client and download the OpenStack RC file and source it (see [[OpenStack Command Line Clients]]).
The OpenStack client can list the available images on your OpenStack project with
{{Command|openstack image list}}
producing something like:

 <!--T:39-->
 +--------------------------------------+---------------------------------------+-------------+------------------+-------------+--------+
 | ID                                   | Name                                  | Disk Format | Container Format | Size        | Status |
 +--------------------------------------+---------------------------------------+-------------+------------------+-------------+--------+
 | 982761b2-c77b-4852-8ae3-bf98b32b8894 | Hadoop-2.2.4                          | qcow2       | bare             | 10253107200 | active |
 | b7bd3033-9836-406d-a8f2-2e91978026b4 | hadoopmaster                          | qcow2       | bare             | 3493527552  | active |
 | 2c751755-854d-49c3-af82-d501e51e7159 | hadoopmaster-active                   | qcow2       | bare             | 13134004224 | active |
 | c41012f4-ed82-4478-a81f-5efb96a31b1a | hadoopmaster-old                      | qcow2       | bare             | 3493527552  | active |
 | 78e61a3f-b546-441a-b476-a7077b04ca36 | hadoopslave                           | qcow2       | bare             | 3490971648  | active |
 | 516845c3-b256-4c6d-a2cb-e31e822c7e34 | hadoopslave1-active                   | qcow2       | bare             | 8345026560  | active |
 | 1546bd86-5314-4fce-9576-e2f6930dad30 | hadoopslave1-old                      | qcow2       | bare             | 3490971648  | active |
 | baf78e8d-8288-4854-a66b-812cdf3ccbca | TestVM                                | qcow2       | bare             | 13167616    | active |
 | 2faf97d7-5b0b-44ce-8024-3bef5a634570 | test_ubuntu_initial                   | qcow2       | bare             | 1799487488  | active |
 | 308b6614-396a-4360-9c33-4e86f41ea0ec | trusty                                | qcow2       | bare             | 256180736   | active |
 | 9b3c3fda-2aca-43b5-a3e7-662a94f5e7fb | Ubuntu_14.04_Trusty-amd64-20150708    | qcow2       | bare             | 257884672   | active |
 | f93e66cf-fec1-4460-8fc7-506e716fbf30 | ucernvm-prod.1.18-10                  | raw         | bare             | 20971520    | active |
 +--------------------------------------+---------------------------------------+-------------+------------------+-------------+--------+

<!--T:78-->
You may need an additional option(s), such as <code>--long</code>, to see all the columns above depending on the version of the client you are using.

<!--T:40-->
You can then download a particular image with
{{Command|openstack image save --file ./<file-name-for-image>.<format> <ID>}}
where <format> matches the value in the ''Disk format'' column and <ID> matches the value in the ''ID'' column.

==Uploading an Image== <!--T:50-->
The first step is to install the OpenStack client and download the OpenStack RC file and source it (see [[OpenStack Command Line Clients]]).
Then run the command
{{Command|openstack image create --file <path-to-local-file-image> --disk-format <format> <new-image-name>}}

<!--T:51-->
where
* <path-to-local-file-image> is the path to the file containing the image you wish to upload from your local machine,
* <format> is the disk format; if not specified, the raw format is assumed, which is incorrect since it can cause issues when using the image in OpenStack,
* <new-image-name> is the name of the image as it appears on the OpenStack dashboard.

==Creating a VirtualBox VM from a Cloud Image== <!--T:41-->
[https://www.virtualbox.org/ VirtualBox] is a software package which allows you to create and run virtual machines on your desktop or laptop. It can be run on many different operating systems (Windows, Linux, Mac) and the virtual machines it creates may run one of many different operating systems.

<!--T:52-->
To use a QCOW2 image downloaded from an OpenStack cloud, as shown above, with VirtualBox you will need to convert the image in the qcow2 format to the vmdk format. This can be done with the <code>qemu-img</code> tool. This can be installed with something like
{{Command|sudo apt-get install qemu-utils}}
(previously the package was called <code>qemu-img</code>) then do the conversion with
{{Command|qemu-img convert -f qcow2 vdisk.qcow2 -O vmdk vdisk.vmdk}}
Then you can create a new virtual machine and attach the vmdk image to it (see [http://techathlon.com/how-to-run-a-vmdk-file-in-oracle-virtualbox/ how to run a vmdk file in virtualbox] for detailed instructions on this).

= Working with VMs= <!--T:69-->
== Locking VMs ==
When working on a project with multiple people or to protect a VM from accidental deletion or shutdown, it can be useful to lock it.

<!--T:70-->
To '''lock''' a VM, click on the "Lock Instance" option from the Actions dropdown menu on the dashboard.<br/>
Once a vm is locked most of the Actions menu items will not be able to be executed until the instance is unlocked. There is an icon indicating the lock state for every instance. 

<!--T:71-->
To '''unlock''' a VM, select the "Unlock Instance" from the Actions dropdown menu on the dashboard.<br/>

==Resizing VMs== <!--T:59-->
It is possible to resize a VM by changing its flavor. However, there are some things to be aware of when choosing to resize a VM which depends on whether you have a "p" flavor or a "c" flavor VM (see [[Virtual machine flavors]]). Resizing a VM may involve some risk as it is similar to deleting and recreating your VM with a new flavor, if in doubt contact cloud [[technical support]].

===c flavors=== <!--T:60-->
"c" flavors often have extra ephemeral drives, which will be resized when you choose a new "c" flavor. These ephemeral drives can not become smaller, and as such "c" flavor VMs can only be resized to flavors with equal or larger ephemeral drives. After the resize however, you will not immediately see a larger ephemeral drive within your VM (e.g. the [https://en.wikipedia.org/wiki/Df_(Unix) <code>df -h</code>] command will not show the size increase). To see this extra space you will need to resize your filesystem (see the [https://linux.die.net/man/8/resize2fs <code>resize2fs</code>] command). However, filesystem resizes should be treated with caution and can take considerable time if the partitions are large. Before resizing a filesystem it is recommend to create backups of its contents (see [[backing up your VM]]).

===p flavors=== <!--T:61-->
Unlike "c" flavors, "p" flavors do not typically have extra ephemeral drives associated with them, so they can be resized to larger and smaller flavors.

=Linux VM User Management= <!--T:28-->
There are a number of ways to allow more than one person to log into a VM. We recommend creating new user accounts and adding public [[SSH Keys]] to these accounts.

==Creating an account and keys== <!--T:29-->
A new user account can be created on Ubuntu with the command {{Command|sudo adduser --disabled-password USERNAME}} To be able to connect, the new user will need to have a key pair, see [[Generating_SSH_keys_in_Windows|generating SSH keys in windows]] or [[Using_SSH_keys_in_Linux#Creating a Key Pair|creating a key pair in Linux or Mac]] depending on the operating system they will be connecting from. Then their public key must be added to <code>/home/USERNAME/.ssh/authorized_keys</code> on the VM, ensuring permissions and ownership are correct as described in steps 2 and 3 of [[Using_SSH_keys_in_Linux#Connecting using a Key Pair|connecting using a key pair]].

==Granting admin privileges== <!--T:44-->
In Ubuntu administrative, or root user privliges, can be given to a new user with the command
{{Command|sudo visudo -f /etc/sudoers.d/90-cloud-init-users}}
which opens an editor where a line like
 USERNAME ALL=(ALL) NOPASSWD:ALL
can be added. For more detailed information about the visudo command and how to edit this file see this [https://www.digitalocean.com/community/tutorials/how-to-edit-the-sudoers-file-on-ubuntu-and-centos#what-is-visudo digitalocean] tutorial on the topic.

==Add users with CloudInit during VM creation== <!--T:30-->
[[File:VM multi user cloud init.png|400px|thumb| Cloud init to add multiple users (Click for larger image)]]
Alternatively, you can do this during the creation of a VM using [http://cloudinit.readthedocs.org/en/latest/index.html# CloudInit]. The following CloudInit script adds two users <code>gretzky</code> and <code>lemieux</code> with and without sudo permissions respectively.

 <!--T:31-->
 #cloud-config
 users:
   - name: gretzky
     shell: /bin/bash
     sudo: ALL=(ALL) NOPASSWD:ALL
     ssh_authorized_keys:
       - <Gretzky's public key goes here>
   - name: lemieux
     shell: /bin/bash
     ssh_authorized_keys:
       - <Lemieux's public key goes here>

<!--T:32-->
For more about the YAML format used by CloudInit, see [http://www.yaml.org/spec/1.2/spec.html#Preview YAML Preview]. Note that YAML is very picky about white space formatting, so that there must be a space after the "-" before your public key string. Also, this configuration overwrites the default user that is added when no CloudInit script is specified, so the users listed in this configuration script will be the ''only'' users on the newly created VM. It is therefore vital to have at least one user with sudo permission. More users can be added by simply including more <code>- name: username</code> sections.

<!--T:33-->
If you wish to preserve the default user created by the distribution (users <code>debian, centos, ubuntu,</code> ''etc.''), use the following form:

 <!--T:34-->
 #cloud-config
 users:
   - default
   - name: gretzky
     shell: /bin/bash
     sudo: ALL=(ALL) NOPASSWD:ALL
     ssh_authorized_keys:
       - <Gretzky's public key goes here>
   - name: lemieux
     shell: /bin/bash
     ssh_authorized_keys:
       - <Lemieux's public key goes here>

<!--T:35-->
After the VM has finished spawning, look at the log to ensure that the public keys have been added correctly for those users. The log can be found by clicking on the name of the instance on the "Compute->Instances" panel and then selecting the "log" tab.  The log should show something like this:

<!--T:36-->
 ci-info: ++++++++Authorized keys from /home/gretzky/.ssh/authorized_keys for user gretzky++++++++
 ci-info: +---------+-------------------------------------------------+---------+------------------+
 ci-info: | Keytype |                Fingerprint (md5)                | Options |     Comment      |
 ci-info: +---------+-------------------------------------------------+---------+------------------+
 ci-info: | ssh-rsa | ad:a6:35:fc:2a:17:c9:02:cd:59:38:c9:18:dd:15:19 |    -    | rsa-key-20160229 |
 ci-info: +---------+-------------------------------------------------+---------+------------------+
 ci-info: ++++++++++++Authorized keys from /home/lemieux/.ssh/authorized_keys for user lemieux++++++++++++
 ci-info: +---------+-------------------------------------------------+---------+------------------+
 ci-info: | Keytype |                Fingerprint (md5)                | Options |     Comment      |
 ci-info: +---------+-------------------------------------------------+---------+------------------+
 ci-info: | ssh-rsa | ad:a6:35:fc:2a:17:c9:02:cd:59:38:c9:18:dd:15:19 |    -    | rsa-key-20160229 |
 ci-info: +---------+-------------------------------------------------+---------+------------------+

<!--T:37-->
Once this is done, users can log into the VM with their private keys as usual (see [[SSH Keys]]).

<!--T:49-->
[[Category:CC-Cloud]]
</translate>