<div dir="ltr"><p style>I like the idea of having a generic consumable resource on the hypervisor. You could use things other than PCI passthrough to pass disks or graphics cards to the host.</p><p style>Is there anything beyond extraspecs and the current resource allocator logic that is required here?</p>
<p style>Not sure about using it for resources you can over provision though, like CPU or Memory though. That seems to be a separate class of thing already handled quite well. Also leaving memory and CPU a special primary resource in the flavor seems good from an interop point of view.</p>
<p style>John</p>
<div class="gmail_quote">On May 30, 2013 12:01 PM, "Kaarle Ritvanen" <<a href="mailto:kaarle.ritvanen@nsn.com" target="_blank">kaarle.ritvanen@nsn.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Hello,<br>
<br>
I have an improvement proposal for this blueprint detailing how to allocate PCI devices to instances:<br>
<br>
<a href="https://blueprints.launchpad.net/nova/+spec/pci-passthrough-base" target="_blank">https://blueprints.launchpad.<u></u>net/nova/+spec/pci-<u></u>passthrough-base</a><br>
<br>
The blueprint proposes mechanisms to declare what kind of PCI devices are required in flavor definition, making scheduling decisions based on device availability, and attaching the device to the instance at hypervisor level.<br>


<br>
I feel this pattern is not specific to PCI devices in any way. In a generalized version, the flavor declares the instance requires X units of resources of type Y. The host would advertise to the scheduler how much of Y it currently has available, and use a hypervisor-specific mechanism to actually allocate X units of Y to the instance if deployed there. Y could be memory, CPU time, network bandwidth (to a given Quantum network), storage capacity or bandwith, PCI device or virtual function etc. In case of KVM, the hypervisor-specific mechanism could be based e.g. on cgroups or tc.<br>


<br>
I think we should consider making the API generic enough to cover all these use cases. We could also clean up the current flavor definitions by consolidating the memory and disk requirements under this generic API.<br>
<br>
BR,<br>
Kaarle<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></div>
</div>