-
Notifications
You must be signed in to change notification settings - Fork 6
RHEV M_Setup
If you intend to build images for this setup, you must be running Aeolus on bare metal with hardware virtualization capabilities. Image building is not possible within a virtual machine.
Only support for RHEV 3 is actively maintained. Before 3.0 was released, there was nominal support for RHEV 2.2 only with the Powershell API . While support for the Powershell API has not been explicitly removed from Aeolus, it is no longer maintained or tested, and is thus unsupported.
NOTE In order to install ‘floppyinject’ hook you need to setup RHEV using RHEL OS. The read-only version of RHEV does not support installation of floppy-inject hook. NOTE RHEV-M 3.1 and oVirt 3.1 has not been fully tested yet so expect bugs
The data center you plan to use should use the NFS storage type. Create an export domain and note the NFS server and directory . Create an administrator level account: username and password.
If you are using oVirt, you must create a “rhevm” logical network in oVirt for your virtual machines to use. Without it, instances won’t start. They’ll fail straight away at launch time. This is due to ImageFactory presently being hard coded to launch instances in a “rhevm” network, even when it’s not running on RHEV.
Update these parameters with values to match environment for the default instance. These parameters should be aligned two spaces to the right of “default:”. nfs_server: your-nfs-server.example.com nfs_export: /export/rhev nfs_mount_point: /mnt/rhevm-nfs deltacloud_username: admin@fqdn deltacloud_password: password deltacloud_api: https://rhevm.example.com:port/api deltacloud_data_center: your data center id push_timeout: 1800
A simple way to gather datacenter informations is to use curl in this way: curl -k -XGET -u[username]:[password] https://rhevm.example.com:port/api/datacenters
Note rhevm_nfs_server:rhevm_nfs_export will be mounted locally to rhevm_nfs_mount_point. rhevm_nfs_export ownership should be 36:36 (vdsm:kvm).
Run “aeolus-configure -p rhevm". Puppet will then add the provider, ensure /etc/imagefactory/rhevm.json and /etc/iwhd/conf.js are updated, and mount the NFS export.
Under Administer-> Providers, you should now see a”rhevm-default" provider. Add a provider account for it, using the credentials you created in (1).
- Build and push an image
Images can be built and pushed through Conductor. Go to Administer -> Environments-> New Image to start the process.
To build from the command line, use aeolus-image; an example is listed
below. Before you push, wait for the build to complete by monitoring
/var/log/imagefactory.log.
Building an image expects ‘rhevm’ as the target type, and pushing
expects the provider name you entered when creating the provider
account.
If you run into problems here, the Common Error Messages page may be helpful.
[root@example]# aeolus-image build --target rhevm --template ~/template.tpl --environment default
Target Image: decd1c78-2f4b-4281-a2e1-b899da2991ef
Image: 627c7e7e-df14-45b9-a1d6-4ebd70c4a417
Build: 20c1c4b3-8dad-40ca-9710-1dec244a7b9a
Status: BUILDING
Percent Complete: 0
[root@example]# aeolus-image push --account <rhevm provider account name in conductor> --image 627c7e7e-df14-45b9-a1d6-4ebd70c4a417
Provider Image: 0f72a62c-489d-4904-a837-23edaef16ec4
Image: 627c7e7e-df14-45b9-a1d6-4ebd70c4a417
Build: 20c1c4b3-8dad-40ca-9710-1dec244a7b9a
Status: PUSHING
Percent Complete: 0
<code class="xml">
<template>
<name>tmpl1</name>
<description>foo</description>
<os>
<name>Fedora</name>
<arch>x86_64</arch>
<version>14</version>
<install type="url">
<url>http://download.fedoraproject.org/pub/fedora/linux/releases/14/Fedora/x86_64/os/</url>
</install>
<rootpw>ChangeMe!</rootpw>
</os>
<repositories>
<repository name="custom">
<url>http://repos.fedorapeople.org/repos/aeolus/demo/webapp/</url>
<signed>false</signed>
</repository>
</repositories>
</template>
</code>
<code class="xml">
<template>
<name>rhel6_1_x86_64_with_rhev-agent</name>
<os>
<name>RHEL-6</name>
<version>1</version>
<arch>x86_64</arch>
<rootpw>password</rootpw>
<install type='url'>
<url>http://system/rhel61/</url>
</install>
</os>
<description>rhel 6.1 x86_64 template with rhev v3.0 agent pkg</description>
<repositories>
<repository name="rhev-agent">
<url>http://system/rhev-agent/</url>
<signed>false</signed>
</repository>
<repository name="rhel-6.2">
<url>http://system/rhel62/</url>
<signed>false</signed>
</repository>
</repositories>
<packages>
<package name='rhev-agent'/>
</packages>
</template>
</code>
- Create a deployable and start the VM
Go to Administer -> Environments-> Images, and select the image you would like the deploy. A deployable can be created by clicking on the “New Deployable from Image” button. You will then see a form where you enter a name, select the hardware profile, and the catalog. A deployable is created when you save.
You will then see the deployable page. Use the “Launch” button to start a VM. It is activated if the image has been built and pushed to a provider.
- RHEV/oVirt 3.0 host configuration for Audrey (Config Server)
To use Audrey in a RHEV 3.0 or oVirt 3.0 environment, the “vdsm-hook-floppyinject” package needs to be installed on each RHEV/oVirt host.
- For RHEV, the package is available through the normal RHN channels.
- For oVirt, the package can be downloaded here.
Once the package is installed, the RHEV/oVirt Engine configuration needs to be updated.
-
For RHEV, run this:
# rhevm-config -s UserDefinedVMProperties='floppyinject=.*:.*$' --cver=3.0
service jbossas restart -
For oVirt, run this:
# engine-config -s UserDefinedVMProperties='floppyinject=.*:.*$' --cver=3.0
# service jboss-as restart
When this is done, Audrey deployments should work fine. Without it, all Audrey deployments will fail immediately, having their instances go to “create_failed” status.
- Common Error Messages
Here are some errors users have run into and their root causes:
/var/log/imagefactory.log shows:
2011-07-01 13:41:23,352 DEBUG
imagefactory.builders.BaseBuilder.RHEL6Builder pid(31548) Message: Got
metadata
output of: {’ami-id’: “failed Bad import status \`FAILED’”}
2011-07-01 13:41:23,352 DEBUG
imagefactory.builders.BaseBuilder.RHEL6Builder pid(31548) Message:
Exception
caught in ImageFactory
2011-07-01 13:41:23,353 DEBUG
imagefactory.builders.BaseBuilder.RHEL6Builder pid(31548) Message:
Traceback
(most recent call last):
File
“/usr/lib/python2.6/site-packages/imagefactory/builders/FedoraBuilder.py”,
line 971, in push\_image\_upload
self.rhevm\_push\_image\_upload(target\_image\_id, provider,
credentials)
File
“/usr/lib/python2.6/site-packages/imagefactory/builders/FedoraBuilder.py”,
line 947, in rhevm\_push\_image\_upload
rhevm\_uuid = m.group(1)
AttributeError: ‘NoneType’ object has no attribute ‘group’
This error came up when RHEV’s export domain had gone inactive. Re-activating it fixed this error.
Here’s another:
2011-07-01 14:11:25,646 ERROR
imagefactory.qmfagent.ImageFactoryAgent.ImageFactoryAgent pid(31548)
Message:
‘template’ must be a UUID, URL, XML string or XML document path…
This can happen a few ways. The Common Error Messages page outlines one of the more common errors, in which there is a problem with the provider account, perhaps the name being mis-typed or specified incorrectly, which can cause us to fall back to the “condorcloud” provider erroneously. Other possible problems include a build that was deleted, a full disk, or attempting to push before the build has finished.
When executing aeolus-image build --target rhevm--template template.tpl if you encounter the following message in the
imagefactory.log you do not have a HVM capable operating system. This
can occur if you are running aeolus in a virtual machine or on hardware
that does not support Hardware-assisted virtualization.
libvirtError: unknown OS type hvm
- Using_the_RHEV-M_API to find other information (data center UUIDs, image template UUIDs, etc.)