We intend to migrate off our small Openstack/Ceph cluster to oVirt as it is a
better fit for our organisation.
We wanted to run oVirt backed on to Ceph storage for quite some time. We waited
for the 3.6 development to take it's course and started testing last year.
The kolla cinder container implementation changed fundamentally in the middle
of the oVirt release process which broke the oVirt 'official' cinder
implementation.
We had tested oVirt using our Openstack cinder so we knew it basically worked
but we didn't want to mix the oVirt and Openstack volumes, ie put oVirt into
it's own ceph pool.
We waited and waited for the Kolla container ...
There didn't seem to be any end in sight, so we chose the following
configuration:
- Hosted engine on Centos 7.2 with gluster storage
- Cinder/Keystone VM on Centos 7.2 using RDO and cinder 'liberty' kept in the
same gluster store as the engine and managed by the engine.
- Used the oVirt engine Postgres database as the Cinder/Keystone store so we
didn't introduce more dependencies with MySQL that Kolla required.
(New user and database for the cinder store. Backups exported separate
to the engine backups)
It's early days yet but here are some observations:
- It works very well integrated with oVirt from the point of view of building
and managing new VM's
- Snapshots and cloning use ceph's features
- No simple means to move Vm disks to and from other storage domains.
- Not impossible though, it means that you have to delete and import ceph RBD's
behind both oVirt and Cinder. It is fairly dangerous as I haven't found a
simple way to get the rbd volume name with vdsClient other than 'vdsClient
list' running VM's. Openstack at least publishes the volume name (UUID) in the
gui, oVirt does not.
- Successfully imported VM images from both Openstack and VMWare.
- There is a hard dependency between oVirt and Cinder when starting VM's but
does not require Cinder to run VMs. Strange really, when the volume name could
be stored in oVirt when the volume is created rather than query cinder for each
start.
Where to from here.
Hosting Cinder/Keystone in containers on the engine VM makes sense.
We are going to roll our own container(s), given the data will be in the engine
Postgres database it should be possible to transition in a clean fassion.
Darryl
________________________________
The contents of this electronic message and any attachments are intended only
for the addressee and may contain legally privileged, personal, sensitive or
confidential information. If you are not the intended addressee, and have
received this email, any transmission, distribution, downloading, printing or
photocopying of the contents of this message or attachments is strictly
prohibited. Any legal privilege or confidentiality attached to this message and
attachments is not waived, lost or destroyed by reason of delivery to any
person other than intended addressee. If you have received this message and are
not the intended addressee you should notify the sender by return email and
destroy all copies of the message and any attachments. Unless expressly
attributed, the views expressed in this email do not necessarily represent the
views of the company.
_______________________________________________
Users mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/users
