Open Stack

2012/11/1 Ian Wells <ijw.ubuntu at cack.org.uk>:
> Note that I'm fantasising a little here; these things would be
> awesome, but actually assigning a device to a VM would be a fine first
> step.
>
> On 1 November 2012 11:26, Jiang, Yunhong <yunhong.jiang at intel.com> wrote:
>>                 ResourceType:                   NIC_VF_1G
>>                 Resource Information:           PCI path: Bus:Device:vFunction
>>                 Resource Description:           SR-IOV NIC with 1G bandwidth
>>                 Resource Count:                 3
>>                 Resource handler class path: nova.virt.libvirt.pci
>
> NICs are not created equal. It's one thing to map in a NIC but you
> also have to know what it's attached to.  Some NICs in a system may be
> equivalent (e.g. attached to a single segment) but not all NICs in a
> system will necessarily be the same.  Also, it's that much cooler if
> you can tell Quantum 'add this NIC to a segment' and get it to program
> the main device of a virtualised NIC card to VLAN tag appropriately,
> and/or play with the config on the attached switch.  (The point here
> would be to define a Quantum API that would allow this to work, which
> would probably come up in relation to the current VIF plugging
> blueprint that's under discussion.)
>
>>         3) How user specifies a given instance needs hardware resource? As stated by Mate, it should be through extra specs like " hardware_resoruce:NIC_VF_1G=1".
>
> You could add specifications on the image ('I only support directmap
> devices of type <X>'; 'I am an image that requires a directmap device
> and will not run without'); on the flavour ('you pay this much and I
> will give you a directmap device'); or in the boot call ('Give this
> image a directmap device', 'use a directmap device for this network').
>
> You also need to know which devices in a class are directmapped once
> the VM starts - that is, the VM needs to know which they are, so NIC
> ordering must be predictable, for instance, if both virtual and
> physical interfaces are supplied.
>
>> We can provide a new filer to make sure the cloud can meet such requirement, or, we can extend current compute capability filter. Also such information will be kept in the instance entry, so that corresponding handler will be invoked when the instance created.
>
> There are other things that are related to this scheduling problem -
> there are unlimited resources that you might want to schedule for,
> too, such as the current patch that's being worked up for libvirt
> resource restrictions, where it must (at present) be scheduled on
> libvirt if you expect the resource restriction to actually occur.  But
> for the specific limited-resource case there's a question of
> enumeration - how many devices are in the system - and allocation -
> how many devices are free, and which devices become free when a VM
> terminates

should  we create  a new table to  manage all these  devices? or  each
nova-compute node
manage their own devices allocation,if there is no new table to record
this.  we need each
kind of passthrough  devices  has a driver to keep track of how many
resources is free and
how many is in use,  these info  is updated to schedule  by sending
capability info periodly.

> --
> Ian.



-- 
Yaguang Tang