Bug 1034749

Summary:	[RFE] self-hosted engine should be a kind of thin system VM/blackbox
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Jiri Belka <jbelka>
Component:	ovirt-hosted-engine-setup	Assignee:	Sandro Bonazzola <sbonazzo>
Status:	CLOSED DUPLICATE	QA Contact:	Leonid Natapov <lnatapov>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	dfediuck, iheim, lyarwood, pablo.iranzo
Target Milestone:	---	Keywords:	FutureFeature, Improvement
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	integration
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-05-12 02:16:07 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Jiri Belka 2013-11-26 13:08:36 UTC

Description of problem:
self-hosted engine should be a kind of thin system VM/blackbox.

I don't understand why one should install, configure, maintain (keep updated) another guest OS for self-hosted engine.

Look what Cloudstack does with their System VMs. It's kind of blackbox VM.

I think self-hosted engine should be thin, minimal VM, well tuned.

What about something like this?

* self-hosted VM would start from a kernel/initrd (or PXE) located on hypervisor
* kernel for self-hosted VM would be separate rpm
* initrd would have whole thin OS, engine, postgreSQL DB, which would be used as loop device populating guest OS (see how SmartOS is it doing for /usr)
* self-hosted VM qemu image would be just to save config, keys, DB

Current design looks like one step forward, two steps back.

Cloud-init could be also used to push files inside the VM.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Itamar Heim 2013-11-26 14:31:22 UTC

the plan is to provide a virtual appliance of the engine for general use case, and specific hosted-engine use case.

Comment 2 Lee Yarwood 2013-11-27 11:08:28 UTC

I would really suggest we look at virt-builder [1] part of libguestfs to do this. The tool automates the provisioning of a guest, would allow us to set hostnames and even automate the installation of engine within the VM.

[1] http://libguestfs.org/virt-builder.1.html

Comment 3 Jiri Belka 2013-11-27 13:09:37 UTC

Modifying VM's image on host is maybe fun but one can see it as a security problem. I think that something inside VM (cloud-init) waiting for valid data format and knowing how to handle that is better choise. (This approach is not also dependent on specific filesystem inside VM, etc... Maybe once we would have some kind of blackbox system VM which would be NAT/VPN for RHEVM networks and such VM would not need any disk at all).

Comment 4 Itamar Heim 2014-05-10 11:43:32 UTC

isn't this redundant with the virtual appliance for engine work?

Comment 5 Doron Fediuck 2014-05-12 02:16:07 UTC

We should soon have ovirt as an appliance which will resolve this issue.

*** This bug has been marked as a duplicate of bug 1053435 ***