Re: [openstack-dev] [nova] vif type libvirt-network
On 11 June 2015 at 02:37, Andreas Scheuring scheu...@linux.vnet.ibm.com wrote: Do you happen to know how data gets routed _to_ a VM, in the type='network' case? Neil, sorry no. Haven't played around with that, yet. But from reading the libvirt man, it looks good. It's saying Guest network traffic will be forwarded to the physical network via the host's IP routing stack - so I would assume this is L3. Maybe you should give it a quick try to figure out... You would at the least require a namespace to preserve network separation, I think. And in fact if you go this way the answer may be to set up a namespace in the same way that LB sets a bridge up. Nova or Neutron can create the NS whichever happens to need it first, and ignore the failure if it happens to get caught in the race. Some slight risk that a true failure is not spotted, though. Or you could have the Neutron agent wait for the appearance of the interface, which it could do with either polling or use of rt_netlink, offhand. And none of this appears to require a libvirt network, but I don't think a simple TAP plug exists either (something along the lines that Neil (?) proposed where Nova is simply told that if it creates a TAP with the right name then all will be well). (And I begin to remember why VIF plugging is horrible.) -- Ian. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] vif type libvirt-network
But I still need to figure out more details about device renaming and what other side effects might come with it. Device renaming might not be a good idea in the macvtap context, as the interface used could also be used with by other applications that might insist on a fixed device name. It's not like in the sriov case, where there's a pool of interfaces that is handled as Openstack resource. It's more like with ovs vxlan approach - the eth device used for tunneling could also be used by other apps and is not dedicated to Openstack I digged deeper into the Live Migration code. I wonder if before live migration, some checking is done if the target hypervisor could serve the same physical network with neutron as well? I haven't found something like that. The only thing I found is, that during pre_live_migration the nova plug code is being called. and some instance specific netork info is being gathered Are you aware of additional checkings? I also had the following other ideas: - use the libvirt network approach and have a api call to neutron-agent-show in our vendor specific plug/unplug code - if some other neutron pre_live_migration checkings exist, maybe I can enrich the data with some content... But I would need some more time for evaluation next week. Thanks so far! Andreas __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] vif type libvirt-network
Ian, Neil, thanks for your input! There may be a set of races you need to deal with, too - what happens if Nova starts a VM attached to a Neutron network binding that has yet to be set up? Neutron doesn't (well, technically, shouldn't be expected to) do things instantaneously on a call, even binding, or you get into the realm of distributed system failure case analysis. Good point. Andreas, how do you think the timing of the Nova and Neutron parts will work? Well, that's a good point where I based my design on wrong assumptions. I had a clear picture of separation in my mind, letting neutron serve all the base network (bridge or libvirt network) while nova will use this as base for plugging. But that's obviously not true - also for linuxbridge agent there is some plug code ensuring that the bridge is there. -- So plug is definitively required to work around potential timing issues! Another idea I just verified is, letting nova create the libvirt network, but without any interface definitions for it. Neutron then would add the corresponding interface asyncronously. Unfortunately this does not work too, as an instance can not be spawned on a libvirt network without any interface defined... So for my case this might be a showstopper. My original problem which I tried to solve with the network approach is, that nova does not need to know about the physical eth interface name used as source for a macvtap but rather just use the generic network name. So for it would be the same problem like with directly defining macvtap as interface type Do you happen to know how data gets routed _to_ a VM, in the type='network' case? Neil, sorry no. Haven't played around with that, yet. But from reading the libvirt man, it looks good. It's saying Guest network traffic will be forwarded to the physical network via the host's IP routing stack - so I would assume this is L3. Maybe you should give it a quick try to figure out... -- Andreas (irc: scheuran) On Wed, 2015-06-10 at 21:20 +0100, Neil Jerram wrote: Hi Ian, Thanks for your reply! On 10/06/15 21:07, Ian Wells wrote: I don't see a problem with this, though I think you do want plug/unplug calls to be passed on to Neutron so that has the opportunity to set up the binding from its side (usage 0) and tear it down when you're done with it (usage 1). There may be a set of races you need to deal with, too - what happens if Nova starts a VM attached to a Neutron network binding that has yet to be set up? Neutron doesn't (well, technically, shouldn't be expected to) do things instantaneously on a call, even binding, or you get into the realm of distributed system failure case analysis. Good point. Andreas, how do you think the timing of the Nova and Neutron parts will work? Neil, are you trying to route to the host - where this will work, because a libvirt network is L2 - or to the VM - where this won't, for the same reason? Consider data that's arriving at a local VM, and has come from a VM on another compute host. VM - Host A - Host B - VM 10.0.0.1 10.0.0.2 In Host B's routing table there is a rule like this: 10.0.0.2/32 dev tap12345-CD where tap12345-CD is the TAP interface towards the VM. Does that answer your question, and would that be possible with a libvirt network? Thanks, Neil -- Ian. On 10 June 2015 at 12:16, Neil Jerram neil.jer...@metaswitch.com mailto:neil.jer...@metaswitch.com wrote: On 10/06/15 15:47, Andreas Scheuring wrote: Hi Daniel, Neil and others, I was thinking about introducing libvirt-network as a new vif type to nova. It can be used when Neutron prepares a libvirt network for attaching guests. Would you see any general concerns with such an approach? Anything that I need to consider with libvirt networks in addition? Maybe I should mention one thing due to the discussion this morning: No plug/unplug behavior would required. Any feedback is welcome! I added a blueprint and wrote a spec with more details [1]. This blueprint would make the macvtap-vif blueprint [2] dispensable. The neutron code exploiting this libvirt network vif type will land on stackforge. It will manage macvtap backed libvirt networks -- offer guest attachments via macvtap. [3] [1] https://blueprints.launchpad.net/nova/+spec/libvirt-network-vif [2] https://blueprints.launchpad.net/nova/+spec/libvirt-macvtap-vif [3] https://launchpad.net/networking-macvtap (I'm still waiting for the repo to be approved, so for now I only have a launchpad project to ref to). Thanks, Andreas, this looks interesting. I wonder if network namexyz/name
Re: [openstack-dev] [nova] vif type libvirt-network
On Thu, 2015-06-11 at 09:30 +0100, Daniel P. Berrange wrote: It seems the main reason for your new proposal is to deal with the fact that on migration, you need to specify a different NIC name in the XML. This is not particularly difficult - Nova already has code for dealing with pdating the XML - the _update_xml method in nova.virt.libvirt.driver just needs extending to cover that. Right, that's why I considered the libvirt network vif type. I also considered to use direct macvtap attachments exploiting the xml-modify feature you just mentioned. My big problem in this case is, that the domain.xml contains the physical eth interface name which will be used as source for the macvtap. Only neutron agent knows about that. It's configured in his interface_mappings. On vif_binding, neutron serves nova the eth interface name via the vif data. That's working fine - I already implemented a prototype for that which was working greatly - as long you not do live Migration. During pre-livemigration on the target host I would need to figure out which interface should be used and give this information back to the source via the pre migration data. But therefore nova needs to talk to my new neutron agent. I don't think that such a shortcut is a good approach. I'm not aware of any similar thing from other drivers. The poor alternative I see would be to duplicate the interface_mapping config to nova, but that's also not a proper approach. I also had a look at the sriov macvtap live migration blueprint [4] but the situation there is slightly different, as nova knows about all pci devices that can be used. No interaction with neutron would be needed. I also thought on jumping on this boat somehow, but the sriov macvtap support is too tightly coupled to pci. I want a general purpose macvtap driver that doesn't care about vendor specifics, but working with any ethernet device... Do you have any ideas how to achieve this? The neutron code exploiting this libvirt network vif type will land on stackforge. It will manage macvtap backed libvirt networks -- offer guest attachments via macvtap. [3] Who / what will actally be talking to libvirt to create/update the network XML setup. Will that be part of the vif driver too. The plan was that the new macvtap-neutron agent will talk to libvirt and set up the network. My plan was not to include such function in the vif driver. But as I learned from Neil and Ian, this does not work, as there's no guarantee that neutron has set up the network before nova defined the instance. So I would need some pluging in the network-vif use case. And here I have the same problem, that nova needs to know the eth interface name for setting up the network... I also played around with just creating the network and adding an interface later on. But on a libvirt network without interfaces I cannot start a guest... Any input is welcome! Thanks! [1] https://blueprints.launchpad.net/nova/+spec/libvirt-network-vif [2] https://blueprints.launchpad.net/nova/+spec/libvirt-macvtap-vif [3] https://launchpad.net/networking-macvtap [4] https://blueprints.launchpad.net/nova/+spec/sriov-live-migration -- Andreas (irc: scheuran) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] vif type libvirt-network
On Thu, Jun 11, 2015 at 12:54:54PM +0200, Andreas Scheuring wrote: On Thu, 2015-06-11 at 09:30 +0100, Daniel P. Berrange wrote: It seems the main reason for your new proposal is to deal with the fact that on migration, you need to specify a different NIC name in the XML. This is not particularly difficult - Nova already has code for dealing with pdating the XML - the _update_xml method in nova.virt.libvirt.driver just needs extending to cover that. Right, that's why I considered the libvirt network vif type. I also considered to use direct macvtap attachments exploiting the xml-modify feature you just mentioned. My big problem in this case is, that the domain.xml contains the physical eth interface name which will be used as source for the macvtap. Only neutron agent knows about that. It's configured in his interface_mappings. On vif_binding, neutron serves nova the eth interface name via the vif data. That's working fine - I already implemented a prototype for that which was working greatly - as long you not do live Migration. During pre-livemigration on the target host I would need to figure out which interface should be used and give this information back to the source via the pre migration data. But therefore nova needs to talk to my new neutron agent. I don't think that such a shortcut is a good approach. I'm not aware of any similar thing from other drivers. The poor alternative I see would be to duplicate the interface_mapping config to nova, but that's also not a proper approach. I also had a look at the sriov macvtap live migration blueprint [4] but the situation there is slightly different, as nova knows about all pci devices that can be used. No interaction with neutron would be needed. I also thought on jumping on this boat somehow, but the sriov macvtap support is too tightly coupled to pci. I want a general purpose macvtap driver that doesn't care about vendor specifics, but working with any ethernet device... Do you have any ideas how to achieve this? I could have sworn I've previously reviewed patches which dealt with NIC device naming changes across migration, but I can't find them now. Did you ever submit patches which tried to fix this, or am I perhaps thinking of someone elses. I understand the difficulty in getting the information across to the right place, but I thought I remembered seeing a solution ot that. Failing that though, the other option is to rename the ethernet devices when assigning them to a guest, so they have a stable name across hosts. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] vif type libvirt-network
On Wed, Jun 10, 2015 at 04:47:41PM +0200, Andreas Scheuring wrote: Hi Daniel, Neil and others, I was thinking about introducing libvirt-network as a new vif type to nova. It can be used when Neutron prepares a libvirt network for attaching guests. Would you see any general concerns with such an approach? Anything that I need to consider with libvirt networks in addition? Maybe I should mention one thing due to the discussion this morning: No plug/unplug behavior would required. Any feedback is welcome! I added a blueprint and wrote a spec with more details [1]. This blueprint would make the macvtap-vif blueprint [2] dispensable. It seems the main reason for your new proposal is to deal with the fact that on migration, you need to specify a different NIC name in the XML. This is not particularly difficult - Nova already has code for dealing with pdating the XML - the _update_xml method in nova.virt.libvirt.driver just needs extending to cover that. The neutron code exploiting this libvirt network vif type will land on stackforge. It will manage macvtap backed libvirt networks -- offer guest attachments via macvtap. [3] Who / what will actally be talking to libvirt to create/update the network XML setup. Will that be part of the vif driver too. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] vif type libvirt-network
On Thu, Jun 11, 2015 at 03:02:13PM +0100, Daniel P. Berrange wrote: On Thu, Jun 11, 2015 at 12:54:54PM +0200, Andreas Scheuring wrote: On Thu, 2015-06-11 at 09:30 +0100, Daniel P. Berrange wrote: It seems the main reason for your new proposal is to deal with the fact that on migration, you need to specify a different NIC name in the XML. This is not particularly difficult - Nova already has code for dealing with pdating the XML - the _update_xml method in nova.virt.libvirt.driver just needs extending to cover that. Right, that's why I considered the libvirt network vif type. I also considered to use direct macvtap attachments exploiting the xml-modify feature you just mentioned. My big problem in this case is, that the domain.xml contains the physical eth interface name which will be used as source for the macvtap. Only neutron agent knows about that. It's configured in his interface_mappings. On vif_binding, neutron serves nova the eth interface name via the vif data. That's working fine - I already implemented a prototype for that which was working greatly - as long you not do live Migration. During pre-livemigration on the target host I would need to figure out which interface should be used and give this information back to the source via the pre migration data. But therefore nova needs to talk to my new neutron agent. I don't think that such a shortcut is a good approach. I'm not aware of any similar thing from other drivers. The poor alternative I see would be to duplicate the interface_mapping config to nova, but that's also not a proper approach. I also had a look at the sriov macvtap live migration blueprint [4] but the situation there is slightly different, as nova knows about all pci devices that can be used. No interaction with neutron would be needed. I also thought on jumping on this boat somehow, but the sriov macvtap support is too tightly coupled to pci. I want a general purpose macvtap driver that doesn't care about vendor specifics, but working with any ethernet device... Do you have any ideas how to achieve this? I could have sworn I've previously reviewed patches which dealt with NIC device naming changes across migration, but I can't find them now. Did you ever submit patches which tried to fix this, or am I perhaps thinking of someone elses. I understand the difficulty in getting the information across to the right place, but I thought I remembered seeing a solution ot that. Failing that though, the other option is to rename the ethernet devices when assigning them to a guest, so they have a stable name across hosts. I wasn't imaginging it - this spec about SRIOV live migration deals with exactly the scenario you describe with macvtap https://review.openstack.org/#/c/136077/9/specs/liberty/approved/sriov-live-migration.rst Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] vif type libvirt-network
Daniel, thanks a lot for your input! Please see my novel below ;) I could have sworn I've previously reviewed patches which dealt with NIC device naming changes across migration, but I can't find them now. Did you ever submit patches which tried to fix this, or am I perhaps thinking of someone elses. I understand the difficulty in getting the information across to the right place, but I thought I remembered seeing a solution ot that. Failing that though, the other option is to rename the ethernet devices when assigning them to a guest, so they have a stable name across hosts. This was in the spec of sriov-live-migration with macvtap [4] I already talked to Robert Li who is the main owner of this spec. What they are finally doing is to modify the xml with the new source device name during pre_live_migration. But as it's in the pci context, they can figure out the target interface name via the nova pci manager - I would need to talk to neutron. For Device renaming I would required another unique identifier which can be used for everlasting configuration on a host, as the device name is not stable anymore. The only thing that comes to my mind is the mac address. It could be used as identifier on all distros, regardless of the network adapter type used. Then on agent start, the neutron agent could rename the interface along a calculated pattern (e.g. net_physnet-name or whatever) The disadvantage would be, that the value of the interface_mappings parameter, that maps and interface to a physical network will look differently on every hypervisor (as there's another mac on each host). But that would be a compromise that would be ok I guess (maybe a little more difficult for chef deployment) These are the disadvantages Rob pointed out: The approach was initially chosen and implemented. One of the issues is how to revert the interface back to its original interface name once the interface is freed. In addition, changing the names back and forth is considered by some people as being a bit complicated. I will think about these concerns as well, but they seem not to be unsolvable! Anyhow this will be in the scope of neutron in my case, so nothing nova should worry about too much. So for now I see the following approaches: 1) Use the mac address as identifier in the interface_mappings configuration and rename the corresponding interface to a openstack global name (e.g net_physnet-name). This ensures that the device has the same name on each hypervisor 2) Document, that for Live Migration the admin has to ensure, that the eth devices use for a physical network, must have the same name over all nodes. 3) Duplicate the neutron config with the interface_mappings to nova.conf 4) Have a shortcut between nova and neutron to figure out the target device name before live migration In all 4 cases both vif_types would be thinkable: a) use macvtap vif_type (direct) in domain.xml [2] -- vif plug/unplug would be required for creating vlan/vxlan devices b) use libvirt network vif_type in domain.xml [1] -- vif plug/unplug has to create the libvirt network and vlan/vxlan devices -- no additional value add comes with the libvirt network approach The most promising solutions sound to be 1 a). But I still need to figure out more details about device renaming and what other side effects might come with it. At least it looks like that I can drawback my blueprint for a libvirt network vif type [1], as it does not bring any additional benefits... Or do you still see anything that might justify the libvirt-network type? Or would you prefer another option, or even have a better one? ;) Thanks! [1] https://blueprints.launchpad.net/nova/+spec/libvirt-network-vif [2] https://blueprints.launchpad.net/nova/+spec/libvirt-macvtap-vif [3] https://launchpad.net/networking-macvtap [4] https://blueprints.launchpad.net/nova/+spec/sriov-live-migration -- Andreas (irc: scheuran) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] vif type libvirt-network
On 10/06/15 15:47, Andreas Scheuring wrote: Hi Daniel, Neil and others, I was thinking about introducing libvirt-network as a new vif type to nova. It can be used when Neutron prepares a libvirt network for attaching guests. Would you see any general concerns with such an approach? Anything that I need to consider with libvirt networks in addition? Maybe I should mention one thing due to the discussion this morning: No plug/unplug behavior would required. Any feedback is welcome! I added a blueprint and wrote a spec with more details [1]. This blueprint would make the macvtap-vif blueprint [2] dispensable. The neutron code exploiting this libvirt network vif type will land on stackforge. It will manage macvtap backed libvirt networks -- offer guest attachments via macvtap. [3] [1] https://blueprints.launchpad.net/nova/+spec/libvirt-network-vif [2] https://blueprints.launchpad.net/nova/+spec/libvirt-macvtap-vif [3] https://launchpad.net/networking-macvtap (I'm still waiting for the repo to be approved, so for now I only have a launchpad project to ref to). Thanks, Andreas, this looks interesting. I wonder if network namexyz/name forward mode=route\ ... /network domain ... interface type='network' source network='xyx'/ /interface ... /domain would provide the connectivity that my Calico project wants to set up [1] - i.e. where all data to and from VMs is routed on the compute host - instead of domain ... interface type='ethernet' ... /interface ... /domain Do you happen to know how data gets routed _to_ a VM, in the type='network' case? Regards, Neil [1] http://docs.projectcalico.org/en/latest/home.html __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] vif type libvirt-network
Hi Ian, Thanks for your reply! On 10/06/15 21:07, Ian Wells wrote: I don't see a problem with this, though I think you do want plug/unplug calls to be passed on to Neutron so that has the opportunity to set up the binding from its side (usage 0) and tear it down when you're done with it (usage 1). There may be a set of races you need to deal with, too - what happens if Nova starts a VM attached to a Neutron network binding that has yet to be set up? Neutron doesn't (well, technically, shouldn't be expected to) do things instantaneously on a call, even binding, or you get into the realm of distributed system failure case analysis. Good point. Andreas, how do you think the timing of the Nova and Neutron parts will work? Neil, are you trying to route to the host - where this will work, because a libvirt network is L2 - or to the VM - where this won't, for the same reason? Consider data that's arriving at a local VM, and has come from a VM on another compute host. VM - Host A - Host B - VM 10.0.0.1 10.0.0.2 In Host B's routing table there is a rule like this: 10.0.0.2/32 dev tap12345-CD where tap12345-CD is the TAP interface towards the VM. Does that answer your question, and would that be possible with a libvirt network? Thanks, Neil -- Ian. On 10 June 2015 at 12:16, Neil Jerram neil.jer...@metaswitch.com mailto:neil.jer...@metaswitch.com wrote: On 10/06/15 15:47, Andreas Scheuring wrote: Hi Daniel, Neil and others, I was thinking about introducing libvirt-network as a new vif type to nova. It can be used when Neutron prepares a libvirt network for attaching guests. Would you see any general concerns with such an approach? Anything that I need to consider with libvirt networks in addition? Maybe I should mention one thing due to the discussion this morning: No plug/unplug behavior would required. Any feedback is welcome! I added a blueprint and wrote a spec with more details [1]. This blueprint would make the macvtap-vif blueprint [2] dispensable. The neutron code exploiting this libvirt network vif type will land on stackforge. It will manage macvtap backed libvirt networks -- offer guest attachments via macvtap. [3] [1] https://blueprints.launchpad.net/nova/+spec/libvirt-network-vif [2] https://blueprints.launchpad.net/nova/+spec/libvirt-macvtap-vif [3] https://launchpad.net/networking-macvtap (I'm still waiting for the repo to be approved, so for now I only have a launchpad project to ref to). Thanks, Andreas, this looks interesting. I wonder if network namexyz/name forward mode=route\ ... /network domain ... interface type='network' source network='xyx'/ /interface ... /domain would provide the connectivity that my Calico project wants to set up [1] - i.e. where all data to and from VMs is routed on the compute host - instead of domain ... interface type='ethernet' ... /interface ... /domain Do you happen to know how data gets routed _to_ a VM, in the type='network' case? Regards, Neil [1] http://docs.projectcalico.org/en/latest/home.html __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] vif type libvirt-network
I don't see a problem with this, though I think you do want plug/unplug calls to be passed on to Neutron so that has the opportunity to set up the binding from its side (usage 0) and tear it down when you're done with it (usage 1). There may be a set of races you need to deal with, too - what happens if Nova starts a VM attached to a Neutron network binding that has yet to be set up? Neutron doesn't (well, technically, shouldn't be expected to) do things instantaneously on a call, even binding, or you get into the realm of distributed system failure case analysis. Neil, are you trying to route to the host - where this will work, because a libvirt network is L2 - or to the VM - where this won't, for the same reason? -- Ian. On 10 June 2015 at 12:16, Neil Jerram neil.jer...@metaswitch.com wrote: On 10/06/15 15:47, Andreas Scheuring wrote: Hi Daniel, Neil and others, I was thinking about introducing libvirt-network as a new vif type to nova. It can be used when Neutron prepares a libvirt network for attaching guests. Would you see any general concerns with such an approach? Anything that I need to consider with libvirt networks in addition? Maybe I should mention one thing due to the discussion this morning: No plug/unplug behavior would required. Any feedback is welcome! I added a blueprint and wrote a spec with more details [1]. This blueprint would make the macvtap-vif blueprint [2] dispensable. The neutron code exploiting this libvirt network vif type will land on stackforge. It will manage macvtap backed libvirt networks -- offer guest attachments via macvtap. [3] [1] https://blueprints.launchpad.net/nova/+spec/libvirt-network-vif [2] https://blueprints.launchpad.net/nova/+spec/libvirt-macvtap-vif [3] https://launchpad.net/networking-macvtap (I'm still waiting for the repo to be approved, so for now I only have a launchpad project to ref to). Thanks, Andreas, this looks interesting. I wonder if network namexyz/name forward mode=route\ ... /network domain ... interface type='network' source network='xyx'/ /interface ... /domain would provide the connectivity that my Calico project wants to set up [1] - i.e. where all data to and from VMs is routed on the compute host - instead of domain ... interface type='ethernet' ... /interface ... /domain Do you happen to know how data gets routed _to_ a VM, in the type='network' case? Regards, Neil [1] http://docs.projectcalico.org/en/latest/home.html __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
