I would prefer to see _infrastructure_ elasticity rules included as they are directly related to a provisioning request (also helps a provider do some up front resource optimisation). OVF also follows this approach with their notion of "ranges". It makes sense as pushing infrastructure elasticity rule management off to another service only introduces another dependency that has to be managed/tracked. Placing elasticity rules upfront and in the context of the infrastructure request also aids in the creation of guarantees of infrastructure so clients requesting infrastructure can further rely on the offers given by providers (risk mitigation). I do however see that the elasticity of services (or scalability) running on infrastructure should be managed by a service management layer, possibly external, for example scalr - where it has application specific scaling strategies to deal with horizontal scaling based on infrastructural metrics. Speaking of horizontal scaling brings to mind vertical scaling. Vertical scaling is what infrastructure should support via elasticity. Horizontal scaling is what should and is be supported by the likes of rightscale and scalr. This makes for a very clear and clean separation of concerns and lessening of dependencies. By supporting the two we have in effect diagonal scaling. All scaling types can also, and in the case of cloud, be virtual and so by virtualisation's theoretical nature, infinite in capacity. With respect to infrastructure placement rules/policies, these approaches can still exist with vertical scaling and the clues (elasticity rules in this case) supplied at provisioning time, can, support runtime optimisation to some degrees. So what I suggest is differentiation between scaling on the cloud; horizontal and vertical, where horizontal remains in the domain of PaaS and vertical in the domain of IaaS. Andy -----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Ignacio Martin Llorente Sent: 30 April 2009 08:36 To: Krishna Sankar (ksankar) Cc: occi-wg@ogf.org Subject: Re: [occi-wg] Extraction of requirements Hi, In my view: - SERVICE ELASTICITY RULES are implemented by the service management layer on top of the infrastructure clouds. That is the case of RightScale or the RESERVOIR Service Manager (Nephele by Telefonica I +D), service management tools grow or shrink the service using the Cloud API to meet given SLOs. See use case http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/ServiceManage... by Telefonica I+D (RESERVOIR) - INFRASTRUCTURE PLACEMENT RULES/POLICIES, such as load balancing or VM consolidation, are executed internally by the cloud provider in order to optimize a given metric, and are not exposed to end users. The user can only define placement constraints as attributes in the VM definition, for example to specify a geographical location. Regarding storage management, I understand that is related to image management, that is the functionality that must be delivered for enabling cloud infrastructure services (methods to register, upload, update and download disk images). Cheers -- Ignacio M. Llorente, Full Professor (Catedratico): http://dsa-research.org/doku.php?id=people:llorente DSA Research Group: web http://dsa-research.org and blog http://blog.dsa-research.org Globus GridWay Metascheduler: http://www.GridWay.org OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org On 30/04/2009, at 2:15, Krishna Sankar (ksankar) wrote:

What about Elasticity rules, adjacency rules, processing rules et al ? Or Should we generically have a policy category ?

Also storage management might be another one.

Cheers <k/>

|-----Original Message----- |From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf |Of Ignacio Martin Llorente |Sent: Wednesday, April 29, 2009 9:33 AM |To: occi-wg@ogf.org |Subject: [occi-wg] Extraction of requirements | |Hi, | |We are going to start with the evaluation of the submitted use cases. |I am planing to create a table summarizing requirements for the |different use cases with the following entries: | |A. Functional Requirements |VM Description |VM Management |Network Management |Image Management | |B. Non-functional Requirements |Security |Quality of Service |Others | |Any suggestion? | |Ignacio |-- |Ignacio M. Llorente, Full Professor (Catedratico): http://dsa- |research.org/doku.php?id=people:llorente |DSA Research Group: web http://dsa-research.org and blog |http://blog.dsa-research.org |Globus GridWay Metascheduler: http://www.GridWay.org |OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org | | | | | | | | | | |_______________________________________________ |occi-wg mailing list |occi-wg@ogf.org |http://www.ogf.org/mailman/listinfo/occi-wg

_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

Hey Ignacio :-), Examples of elasticity: For a machine: - Set memory utilisation to 512MB but allow to grow to 1GB if demand exceeds minimum capacity - Set number of CPUs to 2 but allow to grow to 4 if demand exceeds minimum capacity - Set disk space to 5GB but allow to grow to 10GB if demand exceeds minimum capacity - Set network bandwidth to 10GB/s but allow to grow to 20GB/s if demand exceeds minimum capacity To each of these a policy can be applied that either seeks to minimise resource consumption (shrink; active) or the counter maintain current (keep expanded; passive) for a set period. There are also some examples of OVF ranges in section 8.4 of [1]. Regarding the state of current providers & vertical scaling; from what I seen so far are fix virtual hardware specifications offered to clients that cannot grow according to specified simple rules. The closest that I've seen is where a provider offers "burstable" capacity but this non-functional attribute (from the user's point of view) is not as fine-grained as the example rules above. If we take the example of Amazon EC2, to move from a small instance to a large instance means a re-provisioning AFAIK. Does anyone here have any examples where this is not the case? As for placement constraints, I would imagine, just like what you said, that many of such non-functional properties like this would be hidden from the users of an IaaS interface and are mostly internal concerns of providers. Again as you stated in your previous mail, the only "placement" constraint that would be of relevance to users would be geographic location of provisioned resources (legal compliance or performance considerations etc). Andy [1] http://www.dmtf.org/standards/published_documents/DSP0243_1.0.0.pdf -----Original Message----- From: Ignacio Martin Llorente [mailto:llorente@dacya.ucm.es] Sent: 30 April 2009 10:11 To: Edmonds, AndrewX Cc: Krishna Sankar (ksankar); occi-wg@ogf.org Subject: Re: [occi-wg] Extraction of requirements Hi

I would prefer to see _infrastructure_ elasticity rules included as they are directly related to a provisioning request (also helps a provider do some up front resource optimisation). OVF also follows this approach with their notion of "ranges". It makes sense as pushing infrastructure elasticity rule management off to another service only introduces another dependency that has to be managed/ tracked. Placing elasticity rules upfront and in the context of the infrastructure request also aids in the creation of guarantees of infrastructure so clients requesting infrastructure can further rely on the offers given by providers (risk mitigation).

Could you given an example of an infrastructure elasticity rule?, are they placement constraints?

I do however see that the elasticity of services (or scalability) running on infrastructure should be managed by a service management layer, possibly external, for example scalr - where it has application specific scaling strategies to deal with horizontal scaling based on infrastructural metrics.

Speaking of horizontal scaling brings to mind vertical scaling. Vertical scaling is what infrastructure should support via elasticity. Horizontal scaling is what should and is be supported by the likes of rightscale and scalr. This makes for a very clear and clean separation of concerns and lessening of dependencies. By supporting the two we have in effect diagonal scaling. All scaling types can also, and in the case of cloud, be virtual and so by virtualisation's theoretical nature, infinite in capacity.

With respect to infrastructure placement rules/policies, these approaches can still exist with vertical scaling and the clues (elasticity rules in this case) supplied at provisioning time, can, support runtime optimisation to some degrees.

So what I suggest is differentiation between scaling on the cloud; horizontal and vertical, where horizontal remains in the domain of PaaS and vertical in the domain of IaaS.

Agreed, in fact, if I am not wrong, infrastructure providers supports vertical scaling, this is support for dynamic changing the resource attributes of a running VM Regards

Andy

-----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Ignacio Martin Llorente Sent: 30 April 2009 08:36 To: Krishna Sankar (ksankar) Cc: occi-wg@ogf.org Subject: Re: [occi-wg] Extraction of requirements

Hi,

In my view:

- SERVICE ELASTICITY RULES are implemented by the service management layer on top of the infrastructure clouds. That is the case of RightScale or the RESERVOIR Service Manager (Nephele by Telefonica I +D), service management tools grow or shrink the service using the Cloud API to meet given SLOs. See use case http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/ServiceManage... by Telefonica I+D (RESERVOIR)

- INFRASTRUCTURE PLACEMENT RULES/POLICIES, such as load balancing or VM consolidation, are executed internally by the cloud provider in order to optimize a given metric, and are not exposed to end users. The user can only define placement constraints as attributes in the VM definition, for example to specify a geographical location.

Regarding storage management, I understand that is related to image management, that is the functionality that must be delivered for enabling cloud infrastructure services (methods to register, upload, update and download disk images).

Cheers -- Ignacio M. Llorente, Full Professor (Catedratico): http://dsa-research.org/doku.php?id=people:llorente DSA Research Group: web http://dsa-research.org and blog http://blog.dsa-research.org Globus GridWay Metascheduler: http://www.GridWay.org OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org

On 30/04/2009, at 2:15, Krishna Sankar (ksankar) wrote:

...

What about Elasticity rules, adjacency rules, processing rules et al ? Or Should we generically have a policy category ?

Also storage management might be another one.

Cheers <k/>

|-----Original Message----- |From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf |Of Ignacio Martin Llorente |Sent: Wednesday, April 29, 2009 9:33 AM |To: occi-wg@ogf.org |Subject: [occi-wg] Extraction of requirements | |Hi, | |We are going to start with the evaluation of the submitted use cases. |I am planing to create a table summarizing requirements for the |different use cases with the following entries: | |A. Functional Requirements |VM Description |VM Management |Network Management |Image Management | |B. Non-functional Requirements |Security |Quality of Service |Others | |Any suggestion? | |Ignacio |-- |Ignacio M. Llorente, Full Professor (Catedratico): http://dsa- |research.org/doku.php?id=people:llorente |DSA Research Group: web http://dsa-research.org and blog |http://blog.dsa-research.org |Globus GridWay Metascheduler: http://www.GridWay.org |OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org | | | | | | | | | | |_______________________________________________ |occi-wg mailing list |occi-wg@ogf.org |http://www.ogf.org/mailman/listinfo/occi-wg

_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

Ah excellent, good thing we have the elastichosts guys on board too! Would be interesting to hear from either Richard or Chris does it add value to be able to declare vertical scaling rules a priori as well as having the ability to change parameters at runtime - another valuable piece of functionality in any IaaS interface. Andy -----Original Message----- From: Ignacio Martin Llorente [mailto:llorente@dacya.ucm.es] Sent: 30 April 2009 12:53 To: Edmonds, AndrewX Cc: Krishna Sankar (ksankar); occi-wg@ogf.org Subject: Re: [occi-wg] Extraction of requirements Hi,

Examples of elasticity: For a machine: - Set memory utilisation to 512MB but allow to grow to 1GB if demand exceeds minimum capacity - Set number of CPUs to 2 but allow to grow to 4 if demand exceeds minimum capacity - Set disk space to 5GB but allow to grow to 10GB if demand exceeds minimum capacity - Set network bandwidth to 10GB/s but allow to grow to 20GB/s if demand exceeds minimum capacity To each of these a policy can be applied that either seeks to minimise resource consumption (shrink; active) or the counter maintain current (keep expanded; passive) for a set period. There are also some examples of OVF ranges in section 8.4 of [1].

Agreed

Regarding the state of current providers & vertical scaling; from what I seen so far are fix virtual hardware specifications offered to clients that cannot grow according to specified simple rules. The closest that I've seen is where a provider offers "burstable" capacity but this non-functional attribute (from the user's point of view) is not as fine-grained as the example rules above. If we take the example of Amazon EC2, to move from a small instance to a large instance means a re-provisioning AFAIK. Does anyone here have any examples where this is not the case?

ElasticHosts provide "instant flexibility" http://www.elastichosts.com/benefits/instant-flexibility

As for placement constraints, I would imagine, just like what you said, that many of such non-functional properties like this would be hidden from the users of an IaaS interface and are mostly internal concerns of providers. Again as you stated in your previous mail, the only "placement" constraint that would be of relevance to users would be geographic location of provisioned resources (legal compliance or performance considerations etc).

Cheers

Andy

[1] http://www.dmtf.org/standards/published_documents/ DSP0243_1.0.0.pdf

-----Original Message----- From: Ignacio Martin Llorente [mailto:llorente@dacya.ucm.es] Sent: 30 April 2009 10:11 To: Edmonds, AndrewX Cc: Krishna Sankar (ksankar); occi-wg@ogf.org Subject: Re: [occi-wg] Extraction of requirements

Hi

...

I would prefer to see _infrastructure_ elasticity rules included as they are directly related to a provisioning request (also helps a provider do some up front resource optimisation). OVF also follows this approach with their notion of "ranges". It makes sense as pushing infrastructure elasticity rule management off to another service only introduces another dependency that has to be managed/ tracked. Placing elasticity rules upfront and in the context of the infrastructure request also aids in the creation of guarantees of infrastructure so clients requesting infrastructure can further rely on the offers given by providers (risk mitigation).

Could you given an example of an infrastructure elasticity rule?, are they placement constraints?

...

I do however see that the elasticity of services (or scalability) running on infrastructure should be managed by a service management layer, possibly external, for example scalr - where it has application specific scaling strategies to deal with horizontal scaling based on infrastructural metrics.

Speaking of horizontal scaling brings to mind vertical scaling. Vertical scaling is what infrastructure should support via elasticity. Horizontal scaling is what should and is be supported by the likes of rightscale and scalr. This makes for a very clear and clean separation of concerns and lessening of dependencies. By supporting the two we have in effect diagonal scaling. All scaling types can also, and in the case of cloud, be virtual and so by virtualisation's theoretical nature, infinite in capacity.

With respect to infrastructure placement rules/policies, these approaches can still exist with vertical scaling and the clues (elasticity rules in this case) supplied at provisioning time, can, support runtime optimisation to some degrees.

So what I suggest is differentiation between scaling on the cloud; horizontal and vertical, where horizontal remains in the domain of PaaS and vertical in the domain of IaaS.

Agreed, in fact, if I am not wrong, infrastructure providers supports vertical scaling, this is support for dynamic changing the resource attributes of a running VM

Regards

...

Andy

-----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Ignacio Martin Llorente Sent: 30 April 2009 08:36 To: Krishna Sankar (ksankar) Cc: occi-wg@ogf.org Subject: Re: [occi-wg] Extraction of requirements

Hi,

In my view:

- SERVICE ELASTICITY RULES are implemented by the service management layer on top of the infrastructure clouds. That is the case of RightScale or the RESERVOIR Service Manager (Nephele by Telefonica I +D), service management tools grow or shrink the service using the Cloud API to meet given SLOs. See use case http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/ServiceManage... by Telefonica I+D (RESERVOIR)

- INFRASTRUCTURE PLACEMENT RULES/POLICIES, such as load balancing or VM consolidation, are executed internally by the cloud provider in order to optimize a given metric, and are not exposed to end users. The user can only define placement constraints as attributes in the VM definition, for example to specify a geographical location.

Regarding storage management, I understand that is related to image management, that is the functionality that must be delivered for enabling cloud infrastructure services (methods to register, upload, update and download disk images).

Cheers -- Ignacio M. Llorente, Full Professor (Catedratico): http://dsa-research.org/doku.php?id=people:llorente DSA Research Group: web http://dsa-research.org and blog http://blog.dsa-research.org Globus GridWay Metascheduler: http://www.GridWay.org OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org

On 30/04/2009, at 2:15, Krishna Sankar (ksankar) wrote:

...

What about Elasticity rules, adjacency rules, processing rules et al ? Or Should we generically have a policy category ?

Also storage management might be another one.

Cheers <k/>

|-----Original Message----- |From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf |Of Ignacio Martin Llorente |Sent: Wednesday, April 29, 2009 9:33 AM |To: occi-wg@ogf.org |Subject: [occi-wg] Extraction of requirements | |Hi, | |We are going to start with the evaluation of the submitted use cases. |I am planing to create a table summarizing requirements for the |different use cases with the following entries: | |A. Functional Requirements |VM Description |VM Management |Network Management |Image Management | |B. Non-functional Requirements |Security |Quality of Service |Others | |Any suggestion? | |Ignacio |-- |Ignacio M. Llorente, Full Professor (Catedratico): http://dsa- |research.org/doku.php?id=people:llorente |DSA Research Group: web http://dsa-research.org and blog |http://blog.dsa-research.org |Globus GridWay Metascheduler: http://www.GridWay.org |OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org | | | | | | | | | | |_______________________________________________ |occi-wg mailing list |occi-wg@ogf.org |http://www.ogf.org/mailman/listinfo/occi-wg

_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

Very interesting and a healthy dose of reality :-) A question - if VMs are just processes (yes KVM ;-)) then can't I get close to the 1st two rules noted using cpulimit* (for CPU) and ulimit (for memory)? Yes you are right these types of rules are quite dependent on hypervisor implementations, therefore as you say, vendor extensions could be the initial way to support such functionality. Nevertheless I think we should accommodate such scaling rules as I can only imagine the flexibility of hypervisors increasing and improving over time. Andy *cpulimit: at least on a linux type system, cores show themselves as CPUs therefore my maximum cpu utilisation on a machine with 4 cores is 400%. I can limit a KVM process to one cpu artificially by setting cpulimit to only allow 100% CPU utilisation (100/400 = 25%, 25% of a 4 core/cpu machine is 1). Now limited, I can rebind at runtime the cpulimit process to 200% (50%, 2 core/cpu) and in doing so artificially give another cpu to a VM. This approach is not "pure" but shows that runtime adjustment of CPU numbers is possible. -----Original Message----- From: Richard Davies [mailto:richard.davies@elastichosts.com] Sent: 30 April 2009 16:23 To: Edmonds, AndrewX Cc: Ignacio Martin Llorente; occi-wg@ogf.org Subject: Re: [occi-wg] Extraction of requirements

Would be interesting to hear from either Richard or Chris does it add value to be able to declare vertical scaling rules a priori as well as having the ability to change parameters at runtime - another valuable piece of functionality in any IaaS interface.

Short answer - fixed parameters are generally sufficient in an IaaS API: - For a single server, different technical aspects have very different scaling behaviours. With typical operating systems many of these changes (mem, cpu, disk) require a reboot, so there is no gain in defining scaling rules for those rather than having the user specify the new parameters when they reboot. Network is the exception, but is complex enough that I think we're looking at vendor extensions here. - For multiple servers, there is scope to define scaling rules for all dimensions in terms of when additional server instances should be added. However, this is typically done above the IaaS API by management software such as RightScale.

For a machine: - Set memory utilisation to 512MB but allow to grow to 1GB if demand exceeds minimum capacity

Very hard to implement with typical virtualization platforms and operating systems - e.g. Windows would require a reboot to notice that additional physical RAM is available. In theory this could be implemented on a running server with something like the KVM / VMware ESX balloon driver. In practise ElasticHosts and others do not do this - users reboot their servers to change their total RAM.

- Set number of CPUs to 2 but allow to grow to 4 if demand exceeds minimum capacity

Even harder to implement. I can't think of a common server OS which supports changing the number of CPU cores at runtime without a reboot. However, changing the priority of the virtual machine versus others on the same virtualization host is practical whilst it is running, without any modification or reboot of the contained OS.

- Set disk space to 5GB but allow to grow to 10GB if demand exceeds minimum capacity

This would make sense if storage were provided in terms of a quota for files, however we (and most other IaaS) provide "disks" - a block device which the customer partitions and formats. Here again, an increase in storage means repartitioning and hence typically a reboot.

- Set network bandwidth to 10GB/s but allow to grow to 20GB/s if demand exceeds minimum capacity

This is the case in which vertical scaling rules are useful - if a customer has bought a 10Mbps pipe with 50GB of transfer then what should happen when their website is slashdotted? ElasticHosts current algorithm is to always give all customers the maximum available burst capacity (typically 100Mbps shared pipe), but to email customers and then cut their link when they exceed their prepaid transfer quota. This isn't ideal, and I can easily imagine customers wanting to specify more complicated rules (e.g. email when they hit 90% of transfer quota, then throttle bandwidth for last 10%). Unfortunately the range of possible policies is so great that I think we'll looking at vendor extensions rather than the core API here. Cheers, Richard. ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

Richard Davies <richard.davies@elastichosts.com> writes:

...

and ulimit (for memory)?

Less interesting in this case, since the behaviour of the VM guest operating system is less linear. What should behaviour be if the operating system inside the VM believes it has 10GB of RAM, but the VM process has a ulimit of 2GB. What (should?) happen when the internal VM operating system allocates 2.1GB (as it believes it can!)?

In reality it's even worse than that. Something like kvm will just mmap an area of address space corresponding to the physical address space it intends to simulate. Consequently, if you ulimit the available virtual memory below the level specified for the vm, it will fail to start altogether. Perhaps one might think of a different mechanism from ulimit -v which instead restricts the number of pages you're allowed to dirty, but what should it do when a hypervisor process attempts to write to one page too many? It's not a case of returning an error from a system call: you actually have to refuse a write to memory that's already been malloced/mmaped, so about all you could do is kill the process---probably not very friendly behaviour to export to users! Cheers, Chris.

Sam Johnston <samj@samj.net> writes:

I thought there were some systems that could hotplug CPUs and in any case it's not something we need to care about-implementors can handle runtime updates or return a HTTP error at their discretion.

Hotplug CPUs and memory will eventually be sensibly supported by guest operating systems, whereupon a 'set memory' and a 'set cores' function becomes useful, yes. Best wishes, Chris.

Yes I would also support the inclusion of Monitoring. Although users can access monitoring data from within a VM these may not be accurate. It would be very useful if a provider would expose certain metrics about a VM or set of VMs that are obtained directly through the hypervisor. What this then might allow users to do it to confirm that what providers are giving them is in fact what they can see from metrics gathered from the VM. There was hints by guys in SAP (here [1]) about the formation of some working group/standard around this type of monitoring notion applied against IaaS. Andy [1] http://groups.google.com/group/cloudforum/browse_thread/thread/8ab6090fa0ec1... <- see Steve Winkler's post -----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Luis Rodero-Merino Sent: 30 April 2009 16:36 To: Ignacio Martin Llorente Cc: occi-wg@ogf.org Subject: Re: [occi-wg] Extraction of requirements We would add Identifications/References Monitoring The first would deal with the requirements regarding how elements are to be identified/referenced (which elements have an id? nets, images and VMs only? or also mems, disks...). Regarding 'Monitoring', we think that's an important aspect that also should be included in this specification. Regards, Luis On Wed, Apr 29, 2009 at 6:33 PM, Ignacio Martin Llorente <llorente@dacya.ucm.es> wrote:

Hi,

We are going to start with the evaluation of the submitted use cases. I am planing to create a table summarizing requirements for the different use cases with the following entries:

A. Functional Requirements VM Description VM Management Network Management Image Management

B. Non-functional Requirements Security Quality of Service Others

Any suggestion?

Ignacio -- Ignacio M. Llorente, Full Professor (Catedratico): http://dsa-research.org/doku.php?id=people:llorente DSA Research Group: web http://dsa-research.org and blog http://blog.dsa-research.org Globus GridWay Metascheduler: http://www.GridWay.org OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org

_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg

-- ----------------- Luis Rodero, PhD. Junior Researcher @ Telefónica I+D _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.