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:
the plan is to provide a virtual appliance of the engine for general use case, and specific hosted-engine use case.
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
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).
isn't this redundant with the virtual appliance for engine work?
We should soon have ovirt as an appliance which will resolve this issue. *** This bug has been marked as a duplicate of bug 1053435 ***