[Engine-devel] Requirements for Aeolus instance data injection.
Itamar Heim
iheim at redhat.com
Wed Jan 11 20:21:59 UTC 2012
On 01/11/2012 10:10 PM, David Lutterkort wrote:
> 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.
so you would provide the real IP of that web server, and oVirt would set
up a re-route/nat/whatever from 169.254.169.254 to the requested IP?
any details on how this is done at the technical level wrt iptables, etc.?
what parameter are you passing for this?
>
> 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
>
>
More information about the Engine-devel
mailing list