Open Stack

On 10 January 2014 15:30, John Garbutt <john at johngarbutt.com> wrote:

> We seemed happy with the current system (roughly) around GPU passthrough:
> nova flavor-key <three_GPU_attached_30GB> set
> "pci_passthrough:alias"=" large_GPU:1,small_GPU:2"
> nova boot --image some_image --flavor <three_GPU_attached_30GB> <some_name>
>

Actually, I think we pretty solidly disagree on this point.  On the other
hand, Yongli's current patch (with pci_flavor in the whitelist) is pretty
OK.


> nova boot --flavor m1.large --image <image_id>
>   --nic net-id=<net-id-1>
>   --nic net-id=<net-id-2>,nic-type=fast

  --nic net-id=<net-id-3>,nic-type=fast <vm-name>
>

With flavor defined (wherever it's defined):

nova boot ..
   --nic net-id=<net-id-1>,pci-flavor=xxx    # ok, presumably defaults to
PCI passthrough
   --nic net-id=<net-id-1>,pci-flavor=xxx,vnic-attach=macvtap # ok
   --nic net-id=<net-id-1> # ok - no flavor = vnic
   --nic port-id=<net-id-1>,pci-flavor=xxx    # ok, gets vnic-attach from
port
   --nic port-id=<net-id-1> # ok - no flavor = vnic



> or
>
> neutron port-create
>   --fixed-ip subnet_id=<subnet-id>,ip_address=192.168.57.101
>   --nic-type=<slow | fast | foobar>
>   <net-id>
> nova boot --flavor m1.large --image <image_id> --nic port-id=<port-id>
>

No, I think not - specifically because flavors are a nova concept and not a
neutron one, so putting them on the port is inappropriate. Conversely,
vnic-attach is a Neutron concept (fine, nova implements it, but Neutron
tells it how) so I think it *is* a port field, and we'd just set it on the
newly created port when doing nova boot ..,vnic-attach=thing

2) Expand PCI alias information

{
>  "name":"NIC_fast",
>   sriov_info: {
>   "nic_type":"fast",
>
  "network_ids": ["net-id-1", "net-id-2"]
>

Why can't we use the flavor name in --nic (because multiple flavors might
be on one NIC type, I guess)?  Where does e.g. switch/port information go,
particularly since it's per-device (not per-group) and non-scheduling?

I think the issue here is that you assume we group by flavor, then add
extra info, then group into a NIC group.  But for a lot of use cases there
is information that differs on every NIC port, so it makes more sense to
add extra info to a device, then group into flavor and that can also be
used for the --nic.

network_ids is interesting, but this is a nova config file and network_ids
are (a) from Neutron (b) ephemeral, so we can't put them in config.  They
could be provider network names, but that's not the same thing as a neutron
network name and not easily discoverable, outside of Neutron i.e. before
scheduling.

Again, Yongli's current change with pci-flavor in the whitelist records
leads to a reasonable way to how to make this work here, I think;
straightforward extra_info would be fine (though perhaps nice if it's
easier to spot it as of a different type from the whitelist regex fields).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140110/61ed1cb2/attachment.html>