Browse files

Merge remote branch 'upstream/master' into spotinstances

  • Loading branch information...
2 parents 4983ad3 + 5166907 commit 560002331ec4493c3ff78c893b57556401c36681 @pauloricardomg pauloricardomg committed Jul 27, 2010
@@ -44,8 +44,8 @@ if [ "X$2" == "X" ]; then
exit 1
- PYVEDIR=$installdir
+ PYVEDIR=$installdir
@@ -62,7 +62,24 @@ else
echo "ERROR: Your system must have Python version 2.5 or later."
exit 1
+source $PYVEDIR/bin/activate
+if [ ! -e $PIP ]; then
+ cd $source_dir/deps
+ tar -zxf pip-0.7.2.tar.gz
+ if [ $? -ne 0 ]; then
+ echo "unable to untar pip-0.7.2.tar.gz"
+ exit 1
+ fi
+ cd $source_dir/deps/pip-0.7.2
+ $PYVE install
+ if [ $? -ne 0 ]; then
+ echo "pip was not installed correctly"
+ exit 1
+ fi
cd $source_dir/deps
@@ -22,8 +22,8 @@
working cloud setup.
-<h3>Create nimbus user</h3>
+<a name="user"> </a>
+<h3>Create nimbus user _NAMELINK(user)</h3>
The first step is to create a separate unix account under which to
install and run the Nimbus services. It is not recommended to use
@@ -36,8 +36,8 @@
<tt class="literal">nimbus</tt>, but you can use anything you like.
-<h3>Download and install</h3>
+<a name="downloadinstall"> </a>
+<h3>Download and install _NAMELINK(downloadinstall)</h3>
As the new <tt class="literal">nimbus</tt> user, fetch and unpack
the latest service distribution.
@@ -126,8 +126,8 @@
-<h3>Start services</h3>
+<a name="start"> </a>
+<h3>Start services _NAMELINK(start)</h3>
Now that the services are installed, you can try to start them for the first
time. First, change to the installation directory and take a look at what is
@@ -160,7 +160,8 @@
For Cumulus, look in <tt class="literal">var/cumulus.log</tt>.
-<h3>Create first user</h3>
+<a name="nimbususer"> </a>
+<h3>Create first user _NAMELINK(nimbususer)</h3>
Now that Nimbus is installed and running, we can move on to testing with a real
client. But first, we need to create a user account to test with. We will do this
@@ -188,8 +189,8 @@
will need them momentarily, after you install the cloud client.
-<h3>Install cloud client and credentials</h3>
+<a name="clcl"> </a>
+<h3>Install cloud client and credentials _NAMELINK(clcl)</h3>
We will test our services using the Nimbus cloud client. You can do so from the same
system you are installing on, but you may want to use a separate system so you can
@@ -238,7 +239,8 @@
$ cp $NIMBUS_HOME/var/ca/trusted-certs/* nimbus-cloud-client/lib/certs/
-<h3>Try it out!</h3>
+<a name="try"> </a>
+<h3>Try it out! _NAMELINK(try)</h3>
First we will attempt to query the service. This command shows the running VMs that you own.
@@ -22,7 +22,8 @@
You should use one VMM node for this exercise. When things are working end to end, you can propagate the configuration and dependencies to all of the other nodes on your cluster (assuming that they are roughly homogeneous).
+<a name="deps"> </a>
+<h3>Dependencies _NAMELINK(deps)</h3>
Before automating a VMM node with Nimbus software, it needs to <b>be</b> a VMM node. So the first thing we need to do is make sure that all the virtualization and networking dependencies are present.
@@ -89,7 +90,8 @@
Our next step in this guide will be to create a unix account for workspace-control and then install it. This will give us access to some scripts we can use to further verify the system is ready to be automated with Nimbus.
-<h3>Choose/Create Privileged User Account</h3>
+<a name="accounts"> </a>
+<h3>Choose/Create Privileged User Account _NAMELINK(accounts)</h3>
There are two system accounts needed on the VMMs.
@@ -128,7 +130,8 @@
-<h3>Set up libvirt permissions</h3>
+<a name="libvirtperms"> </a>
+<h3>Set up libvirt permissions _NAMELINK(libvirtperms)</h3>
OK, you've got your non-root user <tt class="literal">nimbus</tt> created, now we need to allow it to control VMs using libvirt.
@@ -227,8 +230,8 @@
If you can still not do this basic list command as the nimbus user, look into your distribution's libvirt configurations and also don't hesitate to contact the <a href="_NIMBUS_WEBSITE/contact/">workspace-user</a> mailing list with problems.
-<h3>Install workspace-control</h3>
+<a name="installwc"> </a>
+<h3>Install workspace-control _NAMELINK(installwc)</h3>
We can now download the VMM control package to the machine.
@@ -287,7 +290,8 @@
-<h3>Pick the kernel to use</h3>
+<a name="kernel"> </a>
+<h3>Pick the kernel to use _NAMELINK(kernel)</h3>
Pick a kernel in /boot that was installed with Xen to use for guest VMs. Let's say for example you find <tt class="literal">/boot/vmlinuz-</tt> was installed along with Xen.
@@ -311,7 +315,8 @@
Now you have created a kernel called <tt class="literal">default</tt> that workspace-control will launch paravirtualized VMs with. The default kernel and initrd to use for VMs is controlled by the <tt class="literal">authz_kernels</tt> configuration in <tt class="literal">/opt/nimbus/etc/workspace-control/kernels.conf</tt> (by default the authorized kernel is "default").
-<h3>Obtain the sample image</h3>
+<a name="image"> </a>
+<h3>Obtain the sample image _NAMELINK(image)</h3>
A sample image has been prepared for testing. This is a basic VM that the Nimbus developers are familiar with, meaning it will be easier to get support help using this VM.
@@ -328,7 +333,8 @@
It also runs the Nimbus context agent on boot, so you can use it to test contextualization.
-<h3>Configure default bridge</h3>
+<a name="bridge"> </a>
+<h3>Configure default bridge _NAMELINK(bridge)</h3>
You set up Xen to use bridged networking, now it is time to check what the actual name of the bridge will be that the guest VM network card uses to get traffic to the LAN.
@@ -357,8 +363,8 @@
Notice <tt class="literal">default: xenbr0</tt> in the <tt class="literal">[defaultbridge]</tt> section of that configuration file. The value here needs to be the bridge that VM traffic will be bridged to. In this case, the <tt class="literal">xenbr0</tt> bridge.
-<h3>Configure sudo and ebtables script</h3>
+<a name="sudo"> </a>
+<h3>Configure sudo and ebtables script _NAMELINK(sudo)</h3>
Before we can do a live test, we need to configure workspace-control to use sudo privileged properly.
@@ -395,8 +401,8 @@
The commands run via sudo are not using a terminal and so if you have "requiretty" enabled, this can cause a failure.
-<h3>Obtain the workspace-control network sample</h3>
+<a name="netsample"> </a>
+<h3>Obtain the workspace-control network sample _NAMELINK(netsample)</h3>
In a previous section of this guide, you configured DHCPd and the network addresses to give to guest VMs.
@@ -414,7 +420,8 @@
We will use it in the next step. The example location on the VMM will be <tt class="literal">/tmp/control.netsample.txt</tt>.
-<h3>Test VM creation with a generated libvirt config</h3>
+<a name="libvirtxml"> </a>
+<h3>Test VM creation with a generated libvirt config _NAMELINK(libvirtxml)</h3>
Once you have obtained the <tt class="literal">control.netsample.txt</tt> file, have the kernel configured and have the default bridge configured, you are ready to try starting the test VM using a libvirt configuration file.
@@ -585,8 +592,8 @@
ssh root@
-<h3>Final test: VM creation using workspace-control</h3>
+<a name="controltest"> </a>
+<h3>Final test: VM creation using workspace-control _NAMELINK(controltest)</h3>
@@ -1,6 +1,6 @@
# Nimbus distribution properties
@@ -23,6 +23,9 @@
# [[ Has no default here ]]
+# CA hash of target cloud
+# [[ Has no default here ]]
# Default ms between polls
@@ -36,9 +39,6 @@ vws.memory.request=3584
# Image repository base directory
-# CA hash of target cloud
# propagation setup for cloud

0 comments on commit 5600023

Please sign in to comment.