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