-
Notifications
You must be signed in to change notification settings - Fork 0
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 (0.9-milestone9.5 or better). 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 (aka vdsm-node) 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 (and please report them ;-)
The data center you plan to use should use the NFS storage type. Create
an export domain and note the NFS server (Example:
your-nfs-server.somewhere.com) and directory (Example: /export/rhev).
Create an administrator level account: username (with FQDN, like
admin@somewhere.com) and password
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 rhevmnfssever:rhevmnfsexport will be mounted locally to rhevmnfsmountpoint. rhevmnfs_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).
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>
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.
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.
Here are some errors users have run into and their root causes:
/var/log/imagefactory.log shows:
20110701 13:41:23,352 DEBUG
imagefactory.builders.BaseBuilder.RHEL6Builder pid (31548) Message: Got
metadata
output of: {‘ami-id’: "failed Bad import status `FAILED‘“}
20110701 13:41:23,352 DEBUG
imagefactory.builders.BaseBuilder.RHEL6Builder pid (31548) Message:
Exception
caught in ImageFactory
20110701 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 pushimageupload
self.rhevmpushimageupload
File
“/usr/lib/python2.6/site-packages/imagefactory/builders/FedoraBuilder.py”,
line 947, in rhevmpushimageupload
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:
20110701 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.)