On Wed, 2011-05-25 at 10:31 -0400, Chris Lalancette wrote:
(sorry if I'm re-hashing anything that has already been
discussed, but in
order for me to understand...)
On 05/25/11 - 02:39:33PM, Mark McLoughlin wrote:
> > A solution is needed for passing the Audrey Config Server contact
> > information (IP address:port/UUID) into an Audrey enabled instance on
> > RHEV-m. This is required so the IP address of the launching instance can
> > be picked up.
>
> Okay, the last time this was discussed, my understanding was that:
>
> - RHEV-M doesn't currently support injecting user data through
> SMBIOS, modifying COW images, or anything else
>
> - Before starting a RHEV-M instance, we would pass the config server
> the RHEV-M VM UUID, along with the config for the instance
I'm not quite sure about this sequence. How do we get the UUID that RHEV-M
is going to assign to a not-yet-started instance? Is there an API call that
we can use to pre-allocate a UUID? Is it up to us to generate the UUID
and then pass that into the create call? Do we get back the UUID *after* the
RHEV-M create call? Something else? The good news is that this detail
shouldn't matter too much to the config server, I'm just curious[1].
You know the UUID before you start the VM.
In RHEV-M, even if you want to launch a stateless VM, you first create
the VM and then start it.
> - On startup, the audrey script would connect to the config
server,
> supply its UUID and return the config
How does the audrey script get the UUID that it needs to supply to the config
server? Presumably it is available in the guest somewhere, but what are the
details?
Fair point. It should be available in SMBIOS. I haven't double checked
that, though.
> - The config server would record the IP address of the request
and
> report it back to conductor
>
> Now, there are two problems here:
>
> - This requires the config server IP address to be baked into the
> image
>
> - The VM UUID isn't some secret key that we can rely on for
> authentication to prevent other VMs from spoofing.
>
> AFAIK, there may have been some confusion that RHEV-M has OTP support,
> which would solve the latter problem. The only OTP in RHEV-M is for the
> display server, which the guest knows nothing about. So that doesn't
> help.
>
> I don't know if we ever thought we had a solution for the former
> problem.
So these last two are a real problem. As you said, we can bake the IP address
into the image for the short-term, though that is really inflexible.
Presumably we need to open a feature request for RHEV-M so that we can do
something else.
Yep.
Cheers,
Mark.