Chapter 7. Running Virtual Machine Instances
Contents
The Compute service uses the concept of security groups to control what network protocols (TCP, UDP, ICMP), ports, and IP addresses are permitted to access instances. Each tenant manages its own list of security groups and starts off with a security group called default. If no security group is specified upon boot, the virtual machine will be associated with the default security group.
Security groups can be listed by the nova secgroup-list command.
$ nova secgroup-list +---------+-------------+ | Name | Description | +---------+-------------+ | default | default | +---------+-------------+
In this example, we will use the nova secgroup-add-rule command to enable access to TCP port 22 (so we can SSH to instances) Allow access to port 22 from all IP addresses (specified in CIDR notation as 0.0.0.0/0) with the following command:
$ nova secgroup-add-rule default tcp 22 22 0.0.0.0/0
When specifying rules for TCP and UDP protocols, you may specify a range of port consecutive addresses in a single rule (e.g., from port 5901 to port 5999). In this case, only a single port is being enabled, so we specify the start port as 22 and the end port as 22.
To be able to ping virtual machine instances, you must specify a rule to allow ICMP traffic. When specifying ICMP rules, instead of specifying a begin and end port, you specify a pemitted ICMP code and ICMP type. You can also specify -1 for the code to enable all codes and -1 for the type to enable all ICMP types. Allow access to all codes and types of ICMP traffic from all IP addresses with the following command:
$ nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0
The Compute service can inject an SSH public key into an account on the instance, assuming the virtual machine image being used supports this. To add a keypair to the Compute service, use the nova keypair-add command. This command can be used to either generate a new keypair, or to upload an existing public key. The following example uploads an existing public key, located at ~/.ssh/id_rsa.pub, and gives the keypair the name mykey.
$ nova keypair-add --pub_key ~/.ssh/id_rsa.pub mykey
List the keypairs by doing:
$ nova keypair-list +-------+-------------------------------------------------+ | Name | Fingerprint | | mykey | c3:d2:b5:d3:ec:4a:29:b0:22:32:6e:34:dd:91:f9:cf | +-------+-------------------------------------------------+
Confirm that the uploaded keypair matches your local key by checking your key's fingerprint with the ssh-keygen command:
$ ssh-keygen -l -f ~/.ssh/id_rsa.pub 2048 c3:d2:b5:d3:ec:4a:29:b0:22:32:6e:34:dd:91:f9:cf /home/myaccount/.ssh/id_rsa.pub (RSA)
Before trying to start an instance, confirm that all of the necessary services are running, in particular:
-
nova-api -
The
nova-apiservice must be running to respond to the request to boot an instance, as well as to serve as the metadata server so that the instance can retrieve the public key uploaded i a previous section. If the nova commands in the previous section succeeded, then the service is running. -
nova-scheduler -
The
nova-schedulerservice must be running in order to dispatch requests for a new virtual machine instance to a host running thenova-computeservice that has sufficient resources. -
nova-compute -
The
nova-computeservice must be running in order to interact with the hypervisor to bring up a virtual machine instance. -
nova-network -
The
nova-networkservice must be running in order to perform networking tasks such as assigning an IP address to the virtual machine instance and implementing the security group rules.
The nova-manage service list command can be used to confirm that these services are running properly.
![[Note]](http://docs.openstack.org/trunk/openstack-compute/install/common/images/admon/note.png) |
Note |
|---|---|
| The nova-manage service list command does not indicate whether the |
As root:
# nova-manage service list Binary Host Zone Status State Updated_At nova-compute myhost-1 nova enabled :-) 2012-05-27 12:36:35 nova-network myhost-1 nova enabled :-) 2012-05-27 12:36:28 nova-scheduler myhost-1 nova enabled :-) 2012-05-27 12:36:33
If any of the services are missing in your configuration, or the State column does not show a smiley face, then your Compute service will not be able to launch an instance.
To start an instance, we need to specify a flavor, also known as an instance type, which indicates the size of an instance. Use the nova flavor-list command to view the list of available flavors:
$ nova flavor-list +----+-----------+-----------+------+-----------+------+-------+-------------+ | ID | Name | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | +----+-----------+-----------+------+-----------+------+-------+-------------+ | 1 | m1.tiny | 512 | 0 | 0 | | 1 | 1.0 | | 2 | m1.small | 2048 | 15 | 15 | | 1 | 1.0 | | 3 | m1.medium | 4096 | 25 | 25 | | 2 | 1.0 | | 4 | m1.large | 8192 | 45 | 45 | | 4 | 1.0 | | 5 | m1.xlarge | 16384 | 85 | 85 | | 8 | 1.0 | +----+-----------+-----------+------+-----------+------+-------+-------------+
We also need to specify the image. Use the nova image-list to retrieve the ID of the CirrOS image.
$ nova image-list +--------------------------------------+----------------------------------------+--------+--------------------------------------+ | ID | Name | Status | Server | +--------------------------------------+----------------------------------------+--------+--------------------------------------+ | f4addd24-4e8a-46bb-b15d-fae2591f1a35 | cirros-0.3.0-x86_64 | ACTIVE | | +--------------------------------------+----------------------------------------+--------+--------------------------------------+
Use the nova boot command to launch a new virtual machine instance. We'll use an m1.small instance in this example, using the CirrOS image, and the mykey keypair we added. We also need to give this virtual machine instance a name, we'll call it cirros. We will explicitly specify the default security group in this example, although this isn't strictly necessary since the default group will be used if no security group is specified.
$ nova boot --flavor 2 --image f4addd24-4e8a-46bb-b15d-fae2591f1a35 --key_name mykey --security_group default cirros
+-------------------------------------+----------------------------------------------------------+
| Property | Value |
+-------------------------------------+----------------------------------------------------------+
| OS-DCF:diskConfig | MANUAL |
| OS-EXT-SRV-ATTR:host | host-1 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | None |
| OS-EXT-SRV-ATTR:instance_name | instance-00000001 |
| OS-EXT-STS:power_state | 0 |
| OS-EXT-STS:task_state | scheduling |
| OS-EXT-STS:vm_state | building |
| accessIPv4 | |
| accessIPv6 | |
| adminPass | RG3W2bpZDbCo |
| config_drive | |
| created | 2012-05-27T13:00:33Z |
| flavor | m1.small |
| hostId | a2fd457e034c030506bac5c790c38d9519ea7a03b6861474a712c6b7 |
| id | c6bbbf26-b40a-47e7-8d5c-eb17bf65c485 |
| image | cirros-0.3.0-x86_64 |
| key_name | mykey |
| metadata | {} |
| name | cirros |
| progress | 0 |
| status | BUILD |
| tenant_id | b5815b046cfe47bb891a7b64119e7f80 |
| updated | 2012-05-27T13:00:33Z |
| user_id | a4c2d43f80a549a19864c89d759bb3fe |
+-------------------------------------+----------------------------------------------------------+
Check the progress of the instance with the nova list command. When the instance has booted, the command output will look something like:
$ nova list +--------------------------------------+-----------------------+--------+------------------------------------------+ | ID | Name | Status | Networks | +--------------------------------------+-----------------------+--------+------------------------------------------+ | c6bbbf26-b40a-47e7-8d5c-eb17bf65c485 | cirros | ACTIVE | private=192.168.100.5 | +--------------------------------------+-----------------------+--------+------------------------------------------+
You can view the boot messages of the instances using the nova console-log command:
$ nova console-log ... Starting network... udhcpc (v1.18.5) started Sending discover... Sending select for 192.168.100.5... Lease of 192.168.100.5 obtained, lease time 120 deleting routers route: SIOCDELRT: No such process adding dns 192.168.100.4 cloud-setup: checking http://169.254.169.254/2009-04-04/meta-data/instance-id cloud-setup: successful after 1/30 tries: up 1.45. iid=i-00000001 Starting dropbear sshd: generating rsa key... generating dsa key... OK ===== cloud-final: system completely up in 1.77 seconds ==== instance-id: i-00000001 public-ipv4: local-ipv4 : 192.168.100.5 cloud-userdata: user data not a script ____ ____ ____ / __/ __ ____ ____ / __ \/ __/ / /__ / // __// __// /_/ /\ \ \___//_//_/ /_/ \____/___/ http://launchpad.net/cirros login as 'cirros' user. default password: 'cubswin:)'. use 'sudo' for root. cirros login:
You should be able to ping your instance:
$ ping -c5 192.168.100.5 PING 192.168.100.5 (192.168.100.5) 56(84) bytes of data. 64 bytes from 192.168.100.5: icmp_req=1 ttl=64 time=0.270 ms 64 bytes from 192.168.100.5: icmp_req=2 ttl=64 time=0.228 ms 64 bytes from 192.168.100.5: icmp_req=3 ttl=64 time=0.244 ms 64 bytes from 192.168.100.5: icmp_req=4 ttl=64 time=0.203 ms 64 bytes from 192.168.100.5: icmp_req=5 ttl=64 time=0.210 ms --- 192.168.100.5 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 3999ms rtt min/avg/max/mdev = 0.203/0.231/0.270/0.024 ms
You should be able to ssh to your instance as the cirros user, using either the ssh keypair you uploaded or using the password cubswin:)
$ ssh [email protected] The authenticity of host '192.168.100.5 (192.168.100.5)' can't be established. RSA key fingerprint is c2:0a:95:d4:e7:e1:a6:a2:6a:99:4d:b8:f9:66:13:64. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.100.5' (RSA) to the list of known hosts. [email protected]'s password: cubswin:) $
转载于:https://www.cnblogs.com/licheng/archive/2012/06/05/2537303.html