Open Stack

On 19 December 2013 15:15, John Garbutt <john at johngarbutt.com> wrote:

> > Note, I don't see the person who boots the server ever seeing the
> pci-flavor, only understanding the server flavor.
>  > [IrenaB] I am not sure that elaborating PCI device request into server
> flavor is the right approach for the PCI pass-through network case. vNIC by
> its nature is something dynamic that can be plugged or unplugged after VM
> boot. server flavor is  quite static.
>
> I was really just meaning the server flavor specify the type of NIC to
> attach.
>
> The existing port specs, etc, define how many nics, and you can hot
> plug as normal, just the VIF plugger code is told by the server flavor
> if it is able to PCI passthrough, and which devices it can pick from.
> The idea being combined with the neturon network-id you know what to
> plug.
>
> The more I talk about this approach the more I hate it :(
>

The thinking we had here is that nova would provide a VIF or a physical NIC
for each attachment.  Precisely what goes on here is a bit up for grabs,
but I would think:

Nova specifiies the type at port-update, making it obvious to Neutron it's
getting a virtual interface or a passthrough NIC (and the type of that NIC,
probably, and likely also the path so that Neutron can distinguish between
NICs if it needs to know the specific attachment port)
Neutron does its magic on the network if it has any to do, like faffing(*)
with switches
Neutron selects the VIF/NIC plugging type that Nova should use, and in the
case that the NIC is a VF and it wants to set an encap, returns that encap
back to Nova
Nova plugs it in and sets it up (in libvirt, this is generally in the XML;
XenAPI and others are up for grabs).

 > We might also want a "nic-flavor" that tells neutron information it
> requires, but lets get to that later...
> > [IrenaB] nic flavor is definitely something that we need in order to
> choose if  high performance (PCI pass-through) or virtio (i.e. OVS) nic
> will be created.
>
> Well, I think its the right way go. Rather than overloading the server
> flavor with hints about which PCI devices you could use.
>

The issue here is that additional attach.  Since for passthrough that isn't
NICs (like crypto cards) you would almost certainly specify it in the
flavor, if you did the same for NICs then you would have a preallocated
pool of NICs from which to draw.  The flavor is also all you need to know
for billing, and the flavor lets you schedule.  If you have it on the list
of NICs, you have to work out how many physical NICs you need before you
schedule (admittedly not hard, but not in keeping) and if you then did a
subsequent attach it could fail because you have no more NICs on the
machine you scheduled to - and at this point you're kind of stuck.

Also with the former, if you've run out of NICs, the already-extant resize
call would allow you to pick a flavor with more NICs and you can then
reschedule the subsequent VM to wherever resources are available to fulfil
the new request.

One question here is whether Neutron should become a provider of billed
resources (specifically passthrough NICs) in the same way as Cinder is of
volumes - something we'd not discussed to date; we've largely worked on the
assumption that NICs are like any other passthrough resource, just one
where, once it's allocated out, Neutron can work magic with it.
-- 
Ian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131220/a47cf488/attachment.html>