10:10 p.m.
On Wed, 2012-01-11 at 08:14 -0500, Ayal Baron wrote:
----- Original Message -----
> Itamar,
>
> The below, provided by David Lutterkort, is a good description
> of the requirements for Aeolus instance data injection.
>
> Joe VLcek
>
> RHEV-M shall accept a small blob of data as part of the
> 'start
> VM' action. That data has to be placed somewhere where the
> VM
> can easily and securely access it. The data must only be
> visible
> to the VM it is intended for.
>
> Possibilities for where to put the data include placing it
> into
> a file on a virtual floppy or CD-ROM that the instance can
> mount, or posting it on a webserver that only the instance
> has
> access to (cf. EC2's handling of userData for the
> RunInstances
> call)
>
> The size limitation for the amount of data shouldn't be kept
> artificially low, but if there are important reasons to make
> it
> this small 1k would certainly suffice.
For the above we want to create an iso containing the data (floppy
seems too limiting) and pass as a cd to the guest
Just to provide some more background info: for DMTF CIMI, I will be
pusing to standardize the EC2 approach, since it is the only one that
properly decouples the VM from the infrastructure; IOW, the standard
will hopefully mandate that each instance can access a web server at
http://169.254.169.254/ from which it can get the user data.
One of the advantages of this aproach is that it makes it possible to
expose dynamic data to the VM, whereas the floppy injection approach is
limited to static data put together at instance launch.
OpenStack has code for this already (setting up iptables rules,
presenting the VM-specific data in responses, etc.) and it doesn't seem
like a huge undertaking.
I am not saying that oVirt has to adopt that approach, but it would
certainly simplify things for oVirt users, and might well be necessary
at some point when CIMI becomes an official standard.
>
> In practical terms, the blob of data should be passed to the
> 'start VM' call base64 encoded, and RHEV-M should decode it
> just
> before putting it into its proper place.
This requirement is not clear, why not just pass data as 'binary' to
'start vm' and vdsm would write as is into the file, REST already
knows how to encode/decode.
I mostly mentioned base64 because that's how other API's (EC2, RAX)
encode this data; to be pedantic, it's not REST that determines the
encoding, but how the request payload is serialized (XML, JSON,
application/x-www-form-urlencoded ..) The nice thing about base64 is
that it works with all of them, without requiring add'l encoding, but
ultimately anything works that allows passing arbitrary binary blobs as
user_data.
David