[Engine-devel] Requirements for Aeolus instance data injection.
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.
----- 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
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.
_______________________________________________ Engine-devel mailing list Engine-devel@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
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
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.py#L... ... 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
On Wed, Jan 11, 2012 at 12:10:04PM -0800, David Lutterkort 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.
I trust you will also push to get an IPv6 address standarized, probably something from the unique local address block: https://en.wikipedia.org/wiki/Unique_local_address Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
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)? Dan.
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. David
----- 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).
David
On Thu, 2012-01-12 at 16:45 -0500, Ayal Baron wrote:
----- 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).
Both EC2 and RAX (and Deltacloud) ask for base64 encoded data, and decode it before presenting it to the instance. Why introduce a difference for such a minor point ? David
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 -----
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.
Unfortunately oVirt modified ovirt in ways that make it not really usable as an API for passing to the hypervisor.
David
On Fri, 2012-01-13 at 04:07 -0500, Ayal Baron wrote:
----- Original Message -----
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.
Unfortunately oVirt modified ovirt in ways that make it not really usable as an API for passing to the hypervisor.
I don't understand. David
-----Original Message----- From: David Lutterkort [mailto:lutter@redhat.com] Sent: Friday, January 13, 2012 0:43 AM To: Ayal Baron Cc: jvlcek@redhat.com; Michal Fojtik; engine-devel@ovirt.org; Itamar Heim; Shahar Havivi; Dan Kenigsberg Subject: Re: [Engine-devel] Requirements for Aeolus instance data injection.
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.
So iiuc, there are two common methods: 1. accept data via the OVF 'activation engine' field to pass XML via a CD-ROM (also via a specific field of the VM or Run Once verb I guess, so no real need to pass it via the OVF). Though I must say I think it is not the best name for such a field? 2. configure a known IP that the guest can communicate with the engine to get the activation data from (engine will need to identify the calling guest uniquely, etc.). Obviously, #1 is easier to implement and has less security considerations. I assume it is satisfactory as well?
participants (6)
-
Ayal Baron -
Dan Kenigsberg -
Daniel P. Berrange -
David Lutterkort -
Itamar Heim -
jvlcek