[Ovirt-devel] Ovirt Host Tasks

[Perry N. Myers]

Ian Main wrote:
> I think some thought needs to be given to being able to add to, or
> change the base os to allow debugging and other tools to be present in
> the image as well.  This can probably just be done with kickstart &
> white/black changes.

That's what I was envisioning as well.

> [snip]
> 
>>>> g. Construct a method for taking an image and adding site
>>>> specific configuration information to it (IP addresses of Ovirt
>>>> Mgmt Server and FreeIPA Server).  This is only necessary to
>>>> support hosts that require static IP configuration -and- do not
>>>> have persistent storage to store configuration information.  (If
>>>> we decide to support static IP config we could make presence of
>>>> persistent storage a requirement...)
>>>> 
>>>> The goal is to get disk footprint down to something like 32, 64
>>>> or 128MB. The base images we build will not be hardware platform
>>>> specific, so 32MB might be a long shot.  But after step e) above,
>>>> we should fit into 32MB.
>>> 64MB is probably a worthy immediate goal to aim for given that the
>>> current live image is about 85 MB & we know there's stuff that can
>>> be killed.
> 
> I wonder if we should create an API for persistent storage?  Given that
> it sounds like we'll have to support multiple options.  We'll have the
> ovirt DB storage, no storage, flash storage, maybe vsata etc.  All with
> its own setup and the operational difference between the DB and some
> kind of disk.

Since we're eliminating static IP addressing, and assuming dhcp fields or 
DNS aliases for critical hosts there no longer is a need for persistent 
storage except for storing the Kerberos keytab or SSL Cert.

Basically when the host boots it needs to find its key.  This could be:
1. Check for TPM and check for key in TPM NVRAM at predefined index
2. If no key in TPM, check local storage for a partition labeled OVIRT and
    get key from well known location there

That should be it.  So I don't think any need for an API to encapsulate that.

>> Agreed.
>> 
>>> Again, unless we have compelling hardware use case that requires 32
>>> MB, I'd not bother aiming for the 32MB mark in the short-medium
>>> term. There's other more broadly useful stuff we can do....
>> Agreed.
> 
> I agree as well.  For intitial devel purposes I'd just as soon see us
> develop the debug/tools image first, and then widdle it down from there
> as a second step.  This will give us the debug image right away which I
> think could be useful.

I think in parallel is better.  We start with a reasonably trimmed down 
kickstart/filelist and then create a debug kickstart/filelist that 
inherits all of the base OS files but overrides to add add'l packages/files.

>>>> 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.e. we're not trying to solve the problem of mobile disconnected 
datacenters<g>)

> One interesting thing would be to use a union filesystem with the os
> image mounted read only and a writeable fs underneath (maybe only where
> appropriate.. eg /etc) that would be stored on persistent storage.
> This lets you modify the image at runtime, have your changes saved
> while not changing the original image.. just a thought, not sure if
> it'd be useful.

I don't think this is necessary given that we're only using persistent 
storage to store a single item.

Perry