The basic premise here is that we want to make it easier for people with limited
amounts of hardware to get up and running with oVirt, and hopefully build a
bigger community around oVirt. We've come a long way with the developer
appliance + the fake managed nodes, but that only gets you so far. In
particular, you can't really start guests (you can, but they are extremely
slow), and the appliance is quite big to download (especially in far-away
places, or with slower internet connections).
To make the initial experience with oVirt more lightweight, we should drop the
"fake managed nodes" and instead have the oVirt stuff be able to
manage the
underlying physical hardware it is running on. Not only does it give you the
ability to run *real* KVM guests (assuming appropriate hardware, of course), it
also gets us closer to being able to manage something other than dedicated oVirt
nodes. There are two ways we can approach this; both have their pros and cons:
1. Still have an oVirt appliance that has everything installed inside of it.
Then, this appliance "manages" the host that it is actually running
on, and can
install additional guests alongside the appliance. You need to protect the
oVirt appliance a little bit so you don't accidentally destroy itself, but
otherwise you can treat the underlying hardware just like any other node.
Pros: Continued isolation of the oVirt configuration from the rest of the
system. Similar to what we have today, so not a huge amount of configuration
churn. Probably pretty quick to implement.
Cons: Heavyweight solution, particularly for those with slow connections for
downloading the appliance image, or without huge amounts of memory (if you only
have a 2GB box, you end up sucking down almost half of your memory just for the
appliance).
2. Get rid of the oVirt appliance completely, and just provide
instructions/better scripts for installing all of the oVirt software directly on
the host. Then the host runs the WUI, and you don't need to protect any
"special" guests.
Pros: Much more lightweight solution; you really only need to download and
install a handful of RPMS, and configure everything correctly. Gets us much
closer to the "production-style" install that we will eventually need.
Cons: Much harder to integrate well with the rest of the system. Kerberos will
be a problem in particular. Needs a *lot* of documentation. Is fairly
different from what we are doing now in terms of scripting, so will probably
take longer to get done.
After thinking about it a little bit, I actually think we should implement both
solutions. In the short term, we should definitely do solution 1, since I think
we can get it done fairly easily and it's very compelling. In the slightly
longer term, I think we should do solution 2, since we will have to for
production anyway.
There are two problems I can think of with either solution; both need to be
addressed:
a. DNS for kerberos. In solution 1, we can actually just continue to run
dnsmasq on a secondary interface and make sure all guests get hooked up to that
secondary interface. In solution 2, it becomes harder because we no longer have
control of DNS. For home users, in particular, this may be an issue, since they
may not be running *any* DNS server that they have control over. Perry has
suggested that we could run the equivalent of a caching DNS server on the host,
that would resolve internal names for us and forward everything else to an
upstream DNS. This solution would probably work, we just have to work out the
details.
b. Announcing the host machine to the WUI. Right now, we expect the managed
nodes to announce themselves to the WUI via a somewhat complicated dance. We
can't reboot the host machine here, so we need some alternative mechanism to
do
this announcement, and pull the keytab from the WUI. Needs a little bit of
thought, but we can probably run "ovirt-identify-node" (maybe slightly
modified)
to send information to the server and grab a keytab.
Thoughts about this? Would this make oVirt easier for people to setup and use?
Chris Lalancette