From Fedora Project Wiki

No edit summary
mNo edit summary
 
(25 intermediate revisions by 6 users not shown)
Line 2: Line 2:
|description=Launch an instance on OpenStack.
|description=Launch an instance on OpenStack.
|setup=Optionally include information on preparing the test environment
|setup=Optionally include information on preparing the test environment
# Follow [[QA:Testcase_download_and_register_tty_images_with_OpenStack]]
# Follow [[QA:Testcase_register_images_with_OpenStack]]
# Make sure the nbd kernel module is loaded so that injecting SSH key files into the filesystem on the qcow2 image works:
$> sudo modprobe nbd


'''OpenStack in a Virtual Machine'''


If you are ''not'' testing OpenStack in a virtual machine, you may skip this section of the setup.
|actions=


If you ''are'' testing OpenStack in a virtual machine, everything will have worked up to this point.  However, launching an instance will fail unless you set an additional configuration option.  Edit <code>/etc/nova/nova.conf</code> and add the following text to a new line in the configuration file:
--libvirt_type=qemu
After adding this item, you will need to restart the OpenStack services.
$> for svc in api objectstore compute network volume scheduler; do sudo service openstack-nova-$svc stop; done
$> for svc in api objectstore compute network volume scheduler; do sudo service openstack-nova-$svc start; done
$> for svc in api objectstore compute network volume scheduler; do sudo service openstack-nova-$svc status; done
|actions=
Launch an instance of one of the images downloaded and registered in the previous test case.
Launch an instance of one of the images downloaded and registered in the previous test case.
  $> cd ~/novacreds
  $> . ./keystonerc
  $> euca-run-instances ami-tty --kernel aki-tty --ramdisk ari-tty -k nova_key
  $> <nowiki>nova boot --image $(nova image-list | grep ami-tty | awk '{print $2}') --flavor 1 --key_name nova_key testvm</nowiki>


|results=
|results=
Line 26: Line 15:
Verify that the instance has started.
Verify that the instance has started.


  $> euca-describe-instances
 
  RESERVATION r-d8wpvydq rbryant default
  $> nova list
  INSTANCE i-00000003 ami-00000003 10.0.0.2 10.0.0.2 pending nova_key (rbryant, f16) 0 m1.small 2011-10-17T20:31:05Z nova aki-00000001 ari-00000002
+--------------------------------------+----------+--------+------------------+
  <nowiki>|                  ID                  |  Name  | Status |    Networks    |</nowiki>
+--------------------------------------+----------+--------+------------------+
  <nowiki>| a47a424a-014b-4b81-97e6-b34d31b5589d | Server 1 | ACTIVE | testnet=10.0.0.2 |</nowiki>
+--------------------------------------+----------+--------+------------------+
 
 
It may take a while to transition from the BUILD to the ACTIVE state, as reported by 'nova list'.  
 
If the instance goes into the ERROR state, then check the nova-compute logs for errors:
 
$> grep ERROR /var/log/nova/compute.log
 
What might help is to restart the nova scheduler with 'sudo systemctl restart openstack-nova-scheduler.service' and try again in case the scheduler reports an error in the logs.
 
Confirm the VM running with virsh:


  $> sudo virsh list
  $> sudo virsh list
   Id Name                State
   Id Name                State
  ----------------------------------
  ----------------------------------
   1 instance-00000003   running
   1 instance-00000001   running
 
Get console output and ensure instance is fully started
$> nova console-log --length 100 <instanceid>
 
Try SSH-ing into the instance:


Try SSHing into the instance:
  $> ssh -i nova_key.priv -o UserKnownHostsFile=/dev/null root@10.0.0.2
$> cd ~/novacreds
  $> ssh -i nova_key.priv root@10.0.0.2


Get conosle output:
Check for new errors in the logs:
  $> euca-get-console-output i-00000003
  $> grep -i error /var/log/nova/*.log


Finally, terminate the instance:
Notes:
  $> euca-terminate-instances i-00000003
* We use <code>/dev/null</code> for known hosts because the fingerprints associated with these IPs will change when you start over with your testing; updating known hosts gets annoying
* You've probably got a stale dnsmasq process around if you see:
  dnsmasq: failed to create listening socket for 10.0.0.1: Address already in use


}}
}}


[[Category:OpenStack Test Cases]]
[[Category:OpenStack Test Cases]]
[[Category:Cloud SIG]]

Latest revision as of 18:32, 25 October 2012

Description

Launch an instance on OpenStack.

Setup

Optionally include information on preparing the test environment

  1. Follow QA:Testcase_register_images_with_OpenStack

How to test

Launch an instance of one of the images downloaded and registered in the previous test case. 

$> . ./keystonerc
$> nova boot --image $(nova image-list | grep ami-tty | awk '{print $2}') --flavor 1 --key_name nova_key testvm

Expected Results

Verify that the instance has started. 


$> nova list
+--------------------------------------+----------+--------+------------------+
|                  ID                  |   Name   | Status |     Networks     |
+--------------------------------------+----------+--------+------------------+
| a47a424a-014b-4b81-97e6-b34d31b5589d | Server 1 | ACTIVE | testnet=10.0.0.2 |
+--------------------------------------+----------+--------+------------------+


It may take a while to transition from the BUILD to the ACTIVE state, as reported by 'nova list'.

If the instance goes into the ERROR state, then check the nova-compute logs for errors: 

$> grep ERROR /var/log/nova/compute.log

What might help is to restart the nova scheduler with 'sudo systemctl restart openstack-nova-scheduler.service' and try again in case the scheduler reports an error in the logs.

Confirm the VM running with virsh: 

$> sudo virsh list
 Id Name                 State
----------------------------------
 1 instance-00000001    running

Get console output and ensure instance is fully started 

$> nova console-log --length 100 <instanceid>

Try SSH-ing into the instance: 

$> ssh -i nova_key.priv -o UserKnownHostsFile=/dev/null root@10.0.0.2

Check for new errors in the logs: 

$> grep -i error /var/log/nova/*.log

Notes:

  • We use /dev/null for known hosts because the fingerprints associated with these IPs will change when you start over with your testing; updating known hosts gets annoying
  • You've probably got a stale dnsmasq process around if you see:
dnsmasq: failed to create listening socket for 10.0.0.1: Address already in use
Retrieved from "https://fedoraproject.org/w/index.php?title=QA:Testcase_launch_an_instance_on_OpenStack&oldid=308693"