hi Sam/Alin,
This is a followup to the discussion we had over IRC this morning about adding
vports.
The question was about what should happen in the kernel if userspace tries to
add a VIF port that is not existent on the hyper-v switch. Should we support it?
In general, you cannot add a vport to the kernel from userspace that does not
exist in the system. Eg. if you try to add a vport (using ovs-vsctl add-port)
using its user friendly name that does not exist on the hyper-v switch,
vswitchd flags this as a failure. The reason for the failure is this piece of
code in bridge.c:
iface_do_create():
1698 error = netdev_open(iface_cfg->name,
1699 iface_get_type(iface_cfg, br->cfg), &netdev);
1700 if (error) {
1701 VLOG_WARN_BUF(errp, "could not open network device %s (%s)",
1702 iface_cfg->name, ovs_strerror(error));
1703 goto error;
1704 }
I understand that netdev_open() is not implemented on Windows. But, when it
does get implemented, it should be done in such a way that it return success
only if a VM's NIC (VIF) is connected to the hyper-v switch.
This way, we can make an assumption in the OVS kernel code that if there's a
request to add a vport that corresponds to a VIF, userspace had validated that
such an VIF exists on the system.
We still need to figure out a lot of things, but one thing for sure is that in
the kernel we won't have to store ports that are not non-existent on the
hyper-v switch.
Thanks,
-- Nithin
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
