The first step would be to create a qcow2 image. This will represent the main HDD of the virtual machine, so make sure to give it as much space as you will need.

kvm-img create -f qcow2 centos.img 5G

Boot Virtual Machine from the CD.

kvm -m 1024 -cdrom CentOS-6.0-i386-bin-DVD.iso -drive file=centos.img,if=virtio,index=0 -boot d -net nic -net user -nographic -vnc :1

Connect to the Virtual Machine through VNC (use display number :1).For Example, where 10.10.10.1 is the IP address of the host machine.

vncviewer 10.10.10.1 :1

Boot the Virtual Machine

kvm -m 1024 -drive file=centos.img,if=virtio,index=0,boot=on -boot c -net nic -net user -nographic -vnc :1

Install VNC server and perform the following steps.

yum install vnc-server
chkconfig vncserver off
service vncserver stop
yum install xinetd

Edit /etc/gdm/custom.conf and add the following lines

[xdmcp]
Enable=true
[security]
DisallowTCP=false

Edit the file /etc/services and comment the following lines

vnc-server 5900/tcp # VNC Server
vnc-server 5900/udp # VNC Server

and add the following line

vnc1024 5900/tcp # VNC and GDM

create a file /etc/xinetd.d/vnc1024 and add the following lines

service vnc1024
{
disable = no

socket_type = stream
protocol = tcp
group = tty
wait = no
user = nobody
server = /usr/bin/Xvnc
server_args = -inetd -query localhost -geometry 1024×768 -depth 16 -once -fp
/usr/share/X11/fonts/misc -securitytypes=none
}

Run the following command to check whether VNC is accessible.

service xinetd restart

Shutdown the Virtual Machine. Upload the image to OpenStack using the following command

cloud-publish-image amd64 centos.img centosbucket

The following output shows that the image has been successfully uploaded.

ami-00000001 centosbucket/centos.img.manifest.xml

Verify whether the instance boots from the uploaded image.

euca-run-instances ami-00000001 -k mykey -t m1.small

kvm-img create -f qcow2 opensuse.img 5G

Start the Virtual Machine booting from the CD.

kvm -m 512 -cdrom openSUSE-11.4-DVD-x86_64.iso -drive file=opensuse.img,if=virtio,index=0 -boot d -net nic -net user -nographic -vnc :1

Connect to the Virtual Machine through VNC (use display number :1).For Example, where 10.10.10.1 is the IP address of the host machine.

vncviewer 10.10.10.1 :1

Select SSH server, Curl and other packages needed. Once the installation is over shutdown the Virtual Machine and boot the  Virtual Machine from Hard Drive using the following command.

kvm -m 512 -drive file=opensuse.img,if=virtio,index=0,boot=on -boot c -net nic -net user -nographic -vnc :1

Install SSH server

zypper install openssh

Install curl

zypper install curl

For SSH Key injection into the instance use the following steps:

Create a file /etc/init.d/sshkey and add the following lines

echo >> /root/.ssh/authorized_keys
curl -m 10 -s http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key | grep 'ssh-rsa' >> /root/.ssh/authorized_keys
echo "AUTHORIZED_KEYS:"
echo "************************"
cat /root/.ssh/authorized_keys
echo "************************"

Change the permissions for the file

chmod 755 /etc/init.d/sshkey

Configure the service to start automatically while booting

chkconfig sshkey on

Configure the firewall (Not iptables) using the following command and allow ssh service

yast2

Also remove the network persistence rules from /etc/udev/rules.d as their presence will result in the network interface in the instance coming up as an interface other than eth0.

rm -rf /etc/udev/rules.d/70-persistent-net.rules

Shutdown the Virtual Machine. Upload the image to OpenStack using the following command

cloud-publish-image amd64 opensuse.img opensusebucket

The following output shows that the image has been successfully uploaded.

ami-00000001 opensusebucket/opensuse.img.manifest.xml

Verify whether the instance boots from the uploaded image.

euca-run-instances ami-00000001 -k mykey -t m1.tiny

The first step would be to create a qcow2 image. This will represent the main HDD of the virtual machine, so make sure to give it as much space as you will need.

kvm-img create -f qcow2 debian.img 5G

Start the Virtual Machine booting from the CD using the following command.

kvm -m 512 -cdrom debian-6.0.1a-amd64-CD-1.iso -drive file=debian.img,if=virtio,index=0 -boot d -net nic -net user -nographic -vnc :1

Connect to the Virtual Machine through VNC (use display number :1).For Example, where 10.10.10.1 is the IP address of the host machine.

vncviewer 10.10.10.1 :1

Select SSH server, Curl and other packages needed. Once the installation is over shutdown the Virtual Machine and boot the Virtual Machine  from  Hard Drive.

kvm -m 512 -drive file=debian.img,if=virtio,index=0,boot=on -boot c -net nic -net user -nographic -vnc :1

Do the necessary changes needed for the image. For key injection add the following lines in the file /etc/rc.local.

mkdir -p /root/.ssh
echo >> /root/.ssh/authorized_keys
curl -m 10 -s http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key | grep 'ssh-rsa' >> /root/.ssh/authorized_keys
echo "AUTHORIZED_KEYS:"
echo "************************"
cat /root/.ssh/authorized_keys
echo "************************"

Also remove the network persistence rules from /etc/udev/rules.d as their presence will result in the network interface in the instance coming up as an interface other than eth0.

rm -rf /etc/udev/rules.d/70-persistent-net.rules

Shutdown the Virtual Machine. Upload the image to OpenStack using the following command

cloud-publish-image amd64 debian.img debianbucket

The following output shows that the image has been successfully uploaded.

ami-00000001 debianbucket/debian.img.manifest.xml

Verify whether the instance boots from the uploaded image.

euca-run-instances ami-00000001 -k mykey -t m1.tiny

The first step would be to create a qcow2 image. This will represent the main HDD of the virtual machine, so make sure to give it as much space as you will need.

kvm-img create -f qcow2 centos.img 5G

Start the Virtual Machine booting from the CD using the following command.

kvm -m 1024 -cdrom CentOS-6.0-i386-bin-DVD.iso -drive file=centos.img,if=virtio,index=0 -boot d -net nic -net user -nographic -vnc :1

Connect to the Virtual Machine through VNC (use display number :1).For Example, where 10.10.10.1 is the IP address of the host machine.

vncviewer 10.10.10.1 :1

Select SSH server  and curl from the package list. Also select the other packages needed, during the  installation. Once the installation is over shutdown and boot the Virtual Machine  from Hard Drive.

kvm -m 1024 -drive file=centos.img,if=virtio,index=0,boot=on -boot c -net nic -net user -nographic -vnc :1

Do the necessary changes needed for the image.

For SSH key injection add the following lines before ‘exit 0′ in the file /etc/rc.local.

mkdir -p /root/.ssh
echo >> /root/.ssh/authorized_keys
curl -m 10 -s http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key | grep 'ssh-rsa' >> /root/.ssh/authorized_keys
echo "AUTHORIZED_KEYS:"
echo "************************"
cat /root/.ssh/authorized_keys
echo "************************"

Edit the file /etc/sysconfig/network-scripts/ifcfg-eth0 and remove the line that contains “HWADDR=”

Remove the network persistence rules from /etc/udev/rules.d as their presence will result in the network interface in the instance coming up as an interface other than eth0.

rm -rf /etc/udev/rules.d/70-persistent-net.rules

Shutdown the Virtual Machine. Upload the image to OpenStack using the following command

cloud-publish-image amd64 centos.img centosbucket

The following output shows that the image has been successfully uploaded.

ami-00000001 centosbucket/centos.img.manifest.xml

Verify whether the instance boots from the uploaded image.

euca-run-instances ami-00000001 -k mykey -t m1.tiny

The first step would be to create a qcow2 image. This will represent the main HDD of the virtual machine, so make sure to give it as much space as you will need

kvm-img create -f qcow2 freebsd.img 5G

Start the Virtual Machine and boot from the CD.

kvm -m 256 -cdrom FreeBSD-8.2-RELEASE-i386-disc1.iso -drive file=freebsd.img,if=scsi,index=0 -boot d -net nic -net user -nographic -vnc :1

Connect to the Virtual Machine through VNC (use display number :1) where 10.10.10.1 is the IP address of the host machine.

vncviewer 10.10.10.1 :1

During the post-installation configuration, enable SSH server. Also enable dhcp for the interface re0.

Shutdown the Virtual Machine and  power it on to boot from the Hard Drive using the following command.

kvm -m 256 -drive file=freebsd.img,if=scsi,index=0,boot=on -boot c -net nic -net user -nographic -vnc :1

We need to install the Virtio driver for the image to work with OpenStack. For installing the Virtio driver perform the following steps.

Download the compressed snapshot of the ports collection.

portsnap fetch

Extract the snapshot into /usr/ports.

portsnap extract

Download the kernel source using the following steps.

sysinstall

Select Configure -> Distributions which will give you many components that it can install. Select “src”. It will in turn show you some sub components. Select “sys”. Install the components. This will download the kernel source which is needed for the compiling the drivers.
In order to install the Virtio driver, we need to install Subversion and download the source for the driver.

cd /usr/ports/devel/subversion
make install
make clean
cd /usr/src/sys/dev
svn co http://svn.freebsd.org/base/projects/virtio/sys/dev/virtio
cd /usr/src/sys/modules
svn co http://svn.freebsd.org/base/projects/virtio/sys/modules/virtio
cd /usr/src/sys/modules/virtio
make
make install

Add the following lines to /boot/loader.conf to load Virtio drivers on boot.

virtio_load="YES"
virtio_pci_load="YES"
virtio_blk_load="YES"
if_vtnet_load="YES"
virtio_balloon_load="YES"

Now the installation and configuration of the virtio driver is over. Make any other changes needed for the image.

Edit the file /etc/fstab to boot from the original drive with Virtio interface.

cp /etc/fstab /etc/fstab.bak
cat /etc/fstab.bak | perl -pe "s/da/vtbd/g;" > /etc/fstab

SSH access for root and password authentication is disabled by default.  Edit /etc/ssh/sshd_config to enable these.

PermitRootLogin yes
PasswordAuthentication yes

TODO: key injection

Shutdown the Virtual Machine and upload the image to OpenStack using the following command.

cloud-publish-image amd64 freebsd.img freebsdbucket

The following output shows that the image has been successfully uploaded.

ami-00000001 freebsdbucket/freebsd.img.manifest.xml

Verify whether the instance boots from the uploaded image.

euca-run-instances ami-00000001 -t m1.tiny

References:
1 http://viktorpetersson.com/2011/10/20/how-to-use-virtio-on-freebsd-8-2/
2 http://www.cyberciti.biz/faq/freebsd-install-kernel-source-code/

We would like to thank  Anne Gentle and  all participants of DocBlitz sessions and several others who have given feedback on these pages, on the documentation pages of OpenStack and offline through emails.

What’s new in V2.0:

1. Procedure for using PostgreSQL for Nova added
2. Swift added to Installation & Configuration chapter and Storage Management chapter
3. Revised the commands line options to be in sync with Diablo
4. Dropped Dashboard section, for now, as the new version of Dashboard relies on Key Stone. We will include them back once the key issues releated to Keystone/Dashboard on Ubuntu get resolved.
5. Dropped Role Based Access Control Chapter. This is undergoing rewrite and we will add it soon.
6. Some language errors fixed
7. Some errors in the architecture diagrams fixed

http://cssoss.files.wordpress.com/2011/08/openstackbookv1-0_csscorp.pdf

Follow us on Twitter https://twitter.com/#!/cssoss

Nova-volume provides persistent block storage compatible with Amazon’s Elastic Block Store. The storage on the instances is non persistent in nature and hence any data that you generate and store on the file system on the first disk of the instance gets lost when the instance is terminated. You will need to use persistent volumes provided by nova-volume if you want any data generated during the life of the instance to persist after the instance is terminated.

Commands from euca2ools package can be used to manage these volumes.

Here are a few examples:

Interacting with Storage Controller

Make sure that you have sourced novarc before running any of the following commands. The following commands refer to a zone called ‘nova’, which we created in the chapter on “Installation and Configuration”. The project is ‘proj’ as referred to in the other chapters.

Create a 10 GB volume

euca-create-volume -s 10 -z nova

You should see an output like:

VOLUME    vol-00000002    1    creating (proj, None, None, None)    2011-04-21T07:19:52Z

List the volumes

euca-describe-volumes

You should see an output like this:

VOLUME    vol-00000001     1        nova    available (proj, server1, None, None)    2011-04-21T05:11:22Z
VOLUME    vol-00000002     1        nova    available (proj, server1, None, None)    2011-04-21T07:19:52Z

Attach a volume to a running instance

euca-attach-volume -i i-00000009 -d /dev/vdb vol-00000002

A volume can only be attached to one instance at a time. When euca-describe-volumes shows the status of a volume as ‘available’, it means it is not attached to any instance and ready to be used. If you run euca-describe-volumes, you can see that the status changes from “available” to “in-use” if it is attached to an  instance successfully.

When a volume is attached to an instance, it shows up as an additional SCSI disk on the instance. You can login to the instance and mount the disk, format it and use it.

Detach a volume from an instance.

euca-detach-volume vol-00000002

The data on the volume persists even after the volume is detached from an instance. You can see the data on reattaching the volume to another instance.

Even though you have indicated /dev/vdb as the device on the instance, the actual device name created by the OS running inside the instance may differ. You can find the name of the device by looking at the device nodes in /dev or by watching the syslog when the volume is being attached.

OpenStack provides commands for administrative tasks such as user/role management,  network management etc. In all the examples we will use username as “novadmin” and project name as “proj”. All the nova-manage commands will need to be run as “root”. Either run them as root or run them under sudo.

User/Role Management

Add a new user

nova-manage user create  novaadmin

Add a user with admin privileges

nova-manage user admin  novaadmin

List existing users

nova-manage user list

Delete an existing user

nova-manage user delete  novaadmin

Associate a user to a specific existing project

nova-manage project add proj  novaadmin

Remove a  user from a specific existing project.

nova-manage project remove proj  novaadmin

View access key and secret keys of particular user.

nova-manage user exports  novaadmin

Add a role to a particular user. Please refer to the chapter on “Role  Based Access Controls” for more details on role management

nova-manage role add  novaadmin netadmin

Remove a role from a particular user

nova-manage role remove  novaadmin netadmin

With the command below, you can change any or all of access key, secret key and admin role flag for a particular user.

Syntax:

nova-manage user modify   <username> <new access key> <new secret key> <admin flag - T or F>

nova-manage user modify   novaadmin mygreatnewaccesskey  ""  ""

nova-manage user modify   novaadmin "" mygreatsecretkey    ""

nova-manage user modify   novaadmin "" ""  T

Check if a particular user has a specific role or not. The role can be either local or global. The output of the command will be True or False

nova-manage role has  novaadmin cloudadmin
 True

nova-manage role has  novaadmin netadmin proj

 False

Project Management

The following commands help you create and manage projects.  “nova-manage account” command is an alias to “nova-manage project” and you can use them interchangeably.

Create a project. It requires you to mention name of the project admin as well. css1 is the name of the project and user5 is the name of the project admin here.

nova-manage project create css1 user5

List the registered projects.

nova-manage project list

Download the credentials and associated file for a specific project. Please refer to the chapter on “Installation & Configuration” for more details.

nova-manage project zipfile csscorp user5 /home/user5/mysec.zip

delete an existing project

nova-manage project delete css1

Check the project wise resource allocation. The output will look like this:

nova-manage project quota css1

metadata_items: 128
 gigabytes: 1000
 floating_ips: 10
 instances: 10
 volumes: 10
 cores: 20

Database Management

Nova stores the data related to the projects, users, resources etc. in a database, by default in a MySQL database.

Print the current database version.

nova-manage db version

Sync the DB schema to be in sync with the current configuration.

nova-manage db sync

Instance Type Management

Nova has the concept of instance types. Each instance type is defined with certain amount of RAM and certain size of the hard disk. When an instance is launched with a particular instance type, Nova resizes the disk image to suit the instance type and allocates the RAM as defined for the instance type chosen. Nova calls instance types as ‘flavors’ and lets you add to the list of flavors. By default Nova has 5 types – m1.tiny, m1.small, m1.medium, m1.large and m1.xlarge.

List the current instance types

nova-manage flavor list
 m1.medium: Memory: 4096MB, VCPUS: 2, Storage: 40GB, FlavorID: 3, Swap: 0GB, RXTX Quota: 0GB, RXTX Cap: 0MB
 m1.large: Memory: 8192MB, VCPUS: 4, Storage: 80GB, FlavorID: 4, Swap: 0GB, RXTX Quota: 0GB, RXTX Cap: 0MB
 m1.tiny: Memory: 512MB, VCPUS: 1, Storage: 0GB, FlavorID: 1, Swap: 0GB, RXTX Quota: 0GB, RXTX Cap: 0MB
 m1.xlarge: Memory: 16384MB, VCPUS: 8, Storage: 160GB, FlavorID: 5, Swap: 0GB, RXTX Quota: 0GB, RXTX Cap: 0MB
 m1.small: Memory: 2048MB, VCPUS: 1, Storage: 20GB, FlavorID: 2, Swap: 0GB, RXTX Quota: 0GB, RXTX Cap: 0MB

Define a new instance type

nova-manage flavor create m1.verytiny 256 2 20 6 0 0 0

Remove an existing instance type.

 nova-manage flavor delete m1.verytiny
 m1.verytiny deleted

Service Management

Check state of available services.

nova-manage service list
 server1 nova-scheduler enabled  :- ) 2011-04-06 17:01:21
server1 nova-network enabled  :- ) 2011-04-06 17:01:30
 server1  nova-compute enabled  :- ) 2011-04-06 17:01:22
 server2 nova-compute enabled  :- ) 2011-04-06 17:01:28

Disable a running service

nova-manage service disable <hostname> <service>
 nova-manage service disable server2 nova-compute

nova-manage service list
 server1 nova-network enabled  :- ) 2011-04-06 17:05:11
 server1 nova-compute enabled  :- ) 2011-04-06 17:05:13
 server1 nova-scheduler enabled :- ) 2011-04-06 17:05:17
server2 nova-compute disabled  :- ) 2011-04-06 17:05:19

Re-enable a service that is currently disabled

Syntax: nova-manage service enable <hostname> <service>
 nova-manage service enable server2 nova-compute

nova-manage service list
 server1 nova-scheduler enabled  :- ) 2011-04-06 17:08:23
 server1 nova-network enabled  :- ) 2011-04-06 17:08:22
 server1 nova-compute enabled  :- ) 2011-04-06 17:08:23
 server2 nova-compute enabled  :- ) 2011-04-06 17:08:19

Get Information about resource utlization of the OpenStack components

Syntax: nova-manage service describe_resource <hostname>

 nova-manage service describe_resource server1

HOST                    PROJECT         cpu     mem(mb) disk(gb)
 server1(total)                                    2       3961           224
 server1(used)                                   1        654                30
 server1                    proj                   2       1024                0

Euca2ools Commands

euca2ools provide a set of commands to communicate with the cloud. All these commands require you to authenticate and this is done by sourcing novarc file as detailed in the chapter on “Installation & Configuration”

Most of the euca2ools command line utilities work with OpenStack, just as they work with EC2 of AWS.  There may be some differences due to some of the functionality that is yet to be implemented in OpenStack. Help is available for each of these commands  with the switch –help.

• euca-add-group
• euca-delete-bundle
• euca-describe-instances
• euca-register
• euca-add-keypair
• euca-delete-group
• euca-describe-keypairs
• euca-release-address
• euca-allocate-address
• euca-delete-keypair
• euca-describe-regions
• euca-reset-image-attribute
• euca-associate-address
• euca-delete-snapshot
• euca-describe-snapshots
• euca-revoke
• euca-attach-volume
• euca-delete-volume
• euca-describe-volumes
• euca-run-instances
• euca-authorize
• euca-deregister
• euca-detach-volume
• euca-terminate-instances
• euca-bundle-image
• euca-describe-addresses
• euca-disassociate-address
• euca-unbundle
• euca-bundle-vol
• euca-describe-availabity-zones
• euca-download-bundle
• euca-upload-bundle
• euca-confirm-product-instance
• euca-describe-groups
• euca-get-console-output
• euca-version
• euca-create-snapshot
• euca-describe-image-attribute
• euca-modify-image-attribute
• euca-create-volume
• euca-describe-images
• euca-reboot-instances

Administrator (admin)

This is a project based role. Users who are created with admin roles at time of creation. They enjoy the rights as a administrator for carrying out tasks such as

• adding an instance
• removing an instance
• removing an image
• adding a key

IT security (itsec)

This is a global role. It permits role holders to quarantine instances.

Project Manager (projectmanager)

This is the default role for project owners. It permits the following tasks:

• adding available roles to user associated in project
• revoking provided roles to a specific user in the project.
• adding an instance
• removing an instance
• removing an image
• adding a key
• managing network related operations

Network Administrator (netadmin)

A role which allows particular user to carry out network related operations such as:

• allocate publicly accessible IP addresses
• assign publicly accessible IP addresses
• create firewall rules
• modify firewall rules

Developer (developer)

This is a general purpose role that is assigned to users by default. This role can create and download keys.

Summary of role and permitted tasks for each role:

Role Management is done using “nova-manage role” command. Please refer to the section on OpenStack Commands for more details.

Examples:

Add role to a user

nova-manage role add user1 netadmin

Remove a role from a particular user

nova-manage role remove user1 netadmin