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.

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.

_______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

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

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.

On Wed, Jan 11, 2012 at 12:10:04PM -0800, David Lutterkort wrote: > > > > > > 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) > encode6 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. But base64 is the additional encoding... I'm generally reluctant to intorduce an application-level encoding if the transport already has one. Does any REST serializer have a problem with natively chewing binary data (I really do not know)?

----- Original Message ----- > On Wed, 2012-01-11 at 22:35 +0200, Dan Kenigsberg wrote: > > On Wed, Jan 11, 2012 at 12:10:04PM -0800, David Lutterkort wrote: > > > > > > > > > > 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) > > > encode6 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. > > > > But base64 is the additional encoding... I'm generally reluctant to > > intorduce > > an application-level encoding if the transport already has one. > > Does any REST > > serializer have a problem with natively chewing binary data (I > > really do not > > know)? > > There's no such thing as a REST serializer; serialization is handled > by > whatever you use to process your payloads (XML, JSON, ...) and the > libraries people use for that have to handle serialization-specific > encodings; base64 is a little friendlier for really underpowered > clients, like shell scripts. > > Don't underestimate how much people automate armed with little more > than > bash and curl - making that easy is one of the big attractions of > REST. Still, if the data is already passed encoded to 'start vm' then the guest itself should decode it (encoding is done outside of the system and so should the decoding).

On Wed, 2012-01-11 at 12:10 -0800, David Lutterkort wrote: > On Wed, 2012-01-11 at 08:14 -0500, Ayal Baron wrote: > > > 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. To add more background^2: OVF has the notion of an 'activation engine', which includes passing some XML to the VM via a CD-ROM. Depending on where OVF support is on the ovirt roadmap, we could support user data injection that way.

David

-----Original Message----- From: David Lutterkort [mailto:lutter@redhat.com] Sent: Friday, January 13, 2012 0:43 AM To: Ayal Baron Cc: jvlcek(a)redhat.com; Michal Fojtik; engine-devel(a)ovirt.org; Itamar

Subject: Re: [Engine-devel] Requirements for Aeolus instance data

On Wed, 2012-01-11 at 12:10 -0800, David Lutterkort wrote: > On Wed, 2012-01-11 at 08:14 -0500, Ayal Baron wrote: > > > 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. To add more background^2: OVF has the notion of an 'activation engine', which includes passing some XML to the VM via a CD-ROM. Depending on where OVF support is on the ovirt roadmap, we could support user data injection that way.