Final Tests

On this page, you will remotely test the system with the cloud client like you did before. But this time, a virtual machine will be started for you as expected.

Back to the cloud client

Several pages ago, we set up and tested the cloud client against the service. Now we are ready to revisit that client installation and try again, but with a real VM. First off, run the status and list commands to ensure that the IaaS and repository services are still running correctly.

$ cd nimbus-cloud-client/

$ ./bin/cloud-client.sh --status

Querying for ALL instances.

There's nothing running on this cloud that you own.

$ bin/cloud-client.sh --list

No files.

If these commands succeeded, we can move on and attempt to upload a real VM image to the repository.

Upload image

It is recommended to start with the image that you used earlier to test the VMM. If you don't still have it, fetch it again. Remember that there is a different sample image for Xen vs. KVM.

$ curl -O https://www.nimbusproject.org/downloads/nimbus-z2c.gz
$ gunzip nimbus-z2c.gz

$ curl -O https://www.nimbusproject.org/downloads/ubuntu10.10.gz
$ gunzip ubuntu10.10.gz

Now use the cloud-client to upload the VM image to the Cumulus repository. For the following commands, replace image with the name of the image file you just unzipped. So nimbus-z2c or ubuntu10.10.

$ ./bin/cloud-client.sh --transfer --sourcefile image

Transferring
  - Source: image
  - Destination: cumulus://Repo/VMS/04NjWi75iz1TzNf4Y3zvU/image

Now the list operation should show the new image.

$ ./bin/cloud-client.sh --list

[Image] 'image'                     Read/write
        Modified: Jun 7 2010 @ 12:43   Size: 288358400 bytes (~275 MB)

Start VM

    vws.metadata.mountAs=hda
    

Now we are ready to boot this image and see if we can ssh into it.

$ ./bin/cloud-client.sh --run --name image --hours 1

Launching workspace.

Workspace Factory Service:
    https://nimbus.example.edu:8445/wsrf/services/WorkspaceFactoryService

Creating workspace "vm-001"... done.


       IP address: 128.135.125.25
         Hostname: x001.nimbus.example.edu
       Start time: Mon Jul 05 21:27:20 CDT 2010
    Shutdown time: Mon Jul 05 22:27:20 CDT 2010
 Termination time: Mon Jul 05 22:37:20 CDT 2010

Waiting for updates.

If all goes well, a VM should be booting and its IP should be printed to the screen. The client will not exit until the image is distributed and the VM is booting. When this happens, you can attempt to SSH into the new VM. SSH may not immediately work because the VM may take some time to boot and start its networking and daemons.

$ ssh [email protected]

Notice also that a "handle" was printed out to the screen for this launch. In the example above, this handle is "vm-001". When you are ready to destroy a running VM, you do so using this handle.

$ ./bin/cloud-client.sh --terminate --handle vm-001

The cloud client has many other options and features. For details, check --help and the client quickstart.

Once more, with contextualization

The cloud client also supports launching VMs with contextualization. The nimbus-z2c image has an agent installed that securely contacts a broker and exchanges information about itself and other nodes. This allows launching groups of nodes that are contextualized into clusters.

The nimbus-z2c image supports simple contextualization. Each VM's SSH public key will be retrieved by the cloud client and installed into your ~/.ssh/known_hosts file. If you launch multiple nimbus-z2c VMs, they will be contextualized and configured with host-based authentication.

Clusters are launched using a cluster document which describes the instances and their relationships. An example for nimbus-z2c is available here.

$ curl -O https://www.nimbusproject.org/downloads/nimbus-z2c.xml

<cluster>
  <workspace>
    <name>node1</name>
    <image>nimbus-z2c</image>
    <!-- How many to launch -->
    <quantity>1</quantity>

    <nic wantlogin="true">public</nic>

    <ctx>
      <provides>
          <identity />
          <role>testrole1</role>
      </provides>
      <requires>
          <identity />
          <role name="testrole2" hostname="true" pubkey="true" />
          <role name="testrole3" />
      </requires>
    </ctx>
  </workspace>
</cluster>

Run the cloud client again, specifying this file with the --cluster argument.

$ ./bin/cloud-client.sh --run --cluster nimbus-z2c.xml --hours 1

Requesting cluster.
  - node1: image 'nimbus-z2c', 1 instance

Context Broker:
    https://nimbus.example.edu:8445/wsrf/services/NimbusContextBroker

Created new context with broker.

Workspace Factory Service:
    https://nimbus.example.edu:8445/wsrf/services/WorkspaceFactoryService

Creating workspace "node1"... done.
  - 128.135.125.21 [ x001.nimbus.example.edu ]


Launching cluster-001... done.

Waiting for launch updates.
  - cluster-001: all members are Running

Waiting for context broker updates.
  - cluster-001: contextualized

SSH trusts new key for x001.nimbus.example.edu  [[ node1 ]]

If all went well, you should see output similar to the example. The VM was booted and its SSH key was sent back to the client via the Context Broker. If you want to try booting multiple VMs in a cluster, edit the XML file and adjust the quantity element then try again. You can also check out the cluster guide for more information.

If the VM successfully launches but the cloud client gets stuck with the message "Waiting for context broker updates", try logging into the VM with SSH and examining the context agent log file /opt/nimbus/ctxlog.txt. There may be a problem with the context broker or metadata server.

What's next?

Once all of these tests succeed, your cloud is up and running. At this point you probably want to configure more VMM nodes and add them to the resource pool. You may also want to check out the reference page sections for more a list of other configurations and information.

You can also now start enabling remote users. You should familiarize yourself with the user management tools, the web application that is available for securely distributing credentials, and look into configuring per-user rights and allocations.

Thanks for trying out Nimbus! If you have any questions or comments please contact our support lists.