On 2014?01?16? 08:28, Ian Wells wrote:
To clarify a couple of Robert's points, since we had a conversation
earlier:
On 15 January 2014 23:47, Robert Li (baoli) <ba...@cisco.com
<mailto:ba...@cisco.com>> wrote:
--- do we agree that BDF address (or device id, whatever you call
it), and node id shouldn't be used as attributes in defining a PCI
flavor?
Note that the current spec doesn't actually exclude it as an option.
It's just an unwise thing to do. In theory, you could elect to define
your flavors using the BDF attribute but determining 'the card in this
slot is equivalent to all the other cards in the same slot in other
machines' is probably not the best idea... We could lock it out as an
option or we could just assume that administrators wouldn't be daft
enough to try.
* the compute node needs to know the PCI flavor. [...]
- to support live migration, we need to use it
to create network xml
I didn't understand this at first and it took me a while to get what
Robert meant here.
This is based on Robert's current code for macvtap based live
migration. The issue is that if you wish to migrate a VM and it's
tied to a physical interface, you can't guarantee that the same
physical interface is going to be used on the target machine, but at
the same time you can't change the libvirt.xml as it comes over with
the migrating machine. The answer is to define a network and refer
out to it from libvirt.xml. In Robert's current code he's using the
group name of the PCI devices to create a network containing the list
of equivalent devices (those in the group) that can be macvtapped.
Thus when the host migrates it will find another, equivalent,
interface. This falls over in the use case under
but, with flavor we defined, the group could be a tag for this purpose,
and all Robert's design still work, so it ok, right?
consideration where a device can be mapped using more than one flavor,
so we have to discard the use case or rethink the implementation.
There's a more complex solution - I think - where we create a
temporary network for each macvtap interface a machine's going to use,
with a name based on the instance UUID and port number, and containing
the device to map. Before starting the migration we would create a
replacement network containing only the new device on the target host;
migration would find the network from the name in the libvirt.xml, and
the content of that network would behave identically. We'd be
creating libvirt networks on the fly and a lot more of them, and we'd
need decent cleanup code too ('when freeing a PCI device, delete any
network it's a member of'), so it all becomes a lot more hairy.
--
Ian.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
