On Wed, 2012-01-11 at 22:21 +0200, Itamar Heim wrote:
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?
No, the web server is provided by the cloud/virt infrastructure; the
user_data that comes in from the 'start VM' request is put onto that web
server by the infrastructure, and the infrastructure sets up a route for
the VM so that 169.254.169.254[1] goes to the infrastructure's web
server.
As an example how this can be done (quoting apevec):
...
remote IP is used to figure out which instance requested its metadata:
https://github.com/openstack/nova/blob/master/nova/api/metadata/handler.p...
...
openstack sets iptables rules to forward metadata requests from compute node to
the node running openstack-api service:
https://github.com/openstack/nova/blob/master/nova/network/linux_net.py#L384
David
[1] link local address, see
http://www.rfc-editor.org/rfc/rfc5735.txt