Open Stack

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.

-- 
Ian.