[Ovirt-devel] Ovirt Host Tasks

[Daniel P. Berrange]

On Mon, Mar 17, 2008 at 03:13:20PM -0400, Perry N. Myers wrote:
> >>>>OEM Pre-Install (will always have flash/disk storage) DHCP
> >>>>Addressing Flash/Disk Storage/TPM Auth credentials can be stored
> >>>>in a file or in TPM Static Addressing Flash/Disk Storage/TPM Auth
> >>>>credentials/IP config/Server IPs can be stored in a file If TPM
> >>>>is present, can be used to store auth info IT Install (may not
> >>>>have flash or disk) DHCP Addressing Flash/Disk Storage/TPM Auth
> >>>>credentials can be stored in a file or in TPM No Persistent
> >>>>Storage (CD or PXE Boot) Auth can be stored in host image
> >>>>(separate image for each host) (NOTE: Not secure for PXE boot.
> >>>>Recommend that we only allow CD boot in this case) Static
> >>>>Addressing Flash/Disk Storage/TPM Auth credentials/IP
> >>>>config/Server IPs can be stored in a file If TPM is present, can
> >>>>be used to store auth info No Persistent Storage (CD or PXE Boot)
> >>>> Auth/IP config/Server IPs can be stored in host image (separate 
> >>>>image for each host) (NOTE: Not secure for PXE boot as above)
> >>>The 2 PXE boot methods can be secure given a deployment scenario
> >>>where the network admin has a dedicated PXE management LAN for
> >>>their hosts. So PXE traffic would be separated from general guest /
> >>>user traffic. Its probably not viable to mandate separate
> >>>'management network' but we should document it as a deployment
> >>>scenario.
> >
> >My only thought here is.. how do we implement all these options with a
> >single boot image?  Somehow we'd have to identify up front if
> >persistent storage is available and then allow other options to become
> >available for configuration (static ip etc).  I also think applications
> >should be given access to persistent storage if available.
> 
> applications?  There are no applications :)  This is just the embedded 
> hypervisor.  There will be services for Ovirt, but these will be written 
> to not need persistent storage, and we can assume a connected environment 

I agree - we're not supporting people installing 3rd party applications
into the oVirt host image. It is a black box providing the minimal support
layer to enable virtualizing guest OS for specific pre-defined use cases.

Clustering is a good example - we're not supporting clustering as something
you drop in as an add-on app to the base OS. Clustering is integrated into
the core oVirt host image out of the box. You loose some flexibility you'd
otherwise get if you deployed clustering as an addon, but that's fine becaue
we targetting a specific use case only - fencing of physical hosts only to
enable oVirt to safely do failover of VMs to an alternate host.

In the unlikely case that someone does want extra functionaly, then that
can be built into the master image by changing the kickstart & rebuilding
it.

Dan.
-- 
|: Red Hat, Engineering, Boston   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|