[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: [Ovirt-devel] Ovirt Host Tasks
- From: "Perry N. Myers" <pmyers redhat com>
- To: Ian Main <imain redhat com>
- Cc: ovirt-devel redhat com
- Subject: Re: [Ovirt-devel] Ovirt Host Tasks
- Date: Mon, 17 Mar 2008 15:13:20 -0400
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 &
That's what I was envisioning as well.
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
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.
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....
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
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
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.
[Date Prev][Date Next] [Thread Prev][Thread Next]