From: Mark McLoughlin <markmc(a)redhat.com>
Date: Wed, 25 May 2011 16:35:51 +0100
On Wed, 2011-05-25 at 11:00 -0400, John R. Dunning wrote:
> > From: Mark McLoughlin <markmc(a)redhat.com>
> > Date: Wed, 25 May 2011 15:34:59 +0100
> >
> > >
> > > > One way of implementing this might be to use RHEV-M's
new "custom hook"
> > > > support. You can install scripts on RHEV hosts which can
hook into
> > > > various parts of the VM lifecycle.
> > > >
> > >
> > > Does this exist in rhev-m 2.2?
> >
> > Nope.
>
> Ok, figured.
>
> The marching orders I've got are that we need a solution for rhev-m
> 2.2. It's sounding to me like we ought to just bite the bullet and
> build the mechanism to at-launch-time copy the image and use
> libguestfs to jam in our bits. It's a kludge, but it would work.
Do you have any ideas on how you'll implement that for 2.2? I don't see
any obviously sane way of doing it
You're correct, I see no obviously sane way of doing it either :-(
Our plan of record has always been "if there's no other way to do it,
we'll resort to the kludge of copying the base image and adding our
special sauce". So far, we haven't had to resort to that, but it
looks now like we will.
We already have the machinery for prying open an image and jamming
stuff into it (libguestfs, for example). We have the ability to shove
images around and register them with backends, so as to make them
launchable. From the generic infrastructure point of view, we'll need
to work out how to map the image id for which a launch was requested
to the actual (temp) image, so that for tracking purposes, we can
maintain the illusion that you launched what you asked for. We need
to talk through where in the flow the magic happens. Current
candidates, I think, are condor, DC api, possible a sidecar script
which gets invoked by conductor or one of the above. There are
probably some more details which I haven't thought of.
More news as it happens...