[Engine-devel] Network Wiring

[Alona Kaplan]

> > On 11/13/2012 07:58 PM, Simon Grinberg wrote:
> > > From the summary:
> > > "...It supports the following actions without unplugging the
> > > Vnic,
> > > and it maintains the device address of the Vnic ...."
> > > 
> > > But in the dialogue section:
> > > "If the Vnic is plugged there should be a message on top of the
> > > dialog "Please notice, changing Type or MAC will cause unplugging
> > > and plugging the Vnic"
> > > 
> > > Looking at the detailed design indeed any change indeed goes
> > > through plug/unplug.
> > > Please correct me if I got the above wrong.
> > 
> > Changing the network (rewiring network) is done using new API with
> > VDSM,
> > updateVmInteface.
> > 
> > Therefore plug/unplug won't be executed for any of:
> > 1. Changing the network to other network or disconnecting/unwiring
> > it).
> > 2. Update the name of the VM (db only).
> > 
> > Other changes to VM properties (i.e. MAC address, driver type) will
> > require the plug/unplug. Same goes to any explicit 'unplug'
> > command.
> > 
> > > 
> > > To support real live rewire == "Move a card from one network to
> > > another"
> > > The sequence should be for wired-plugged card:
> > > - Unwire
> > > - Change network
> > > - Rewire
> > > 
> > > I would argue that we should actually force the user to perform
> > > these steps, but we can do it in one go.
> > 
> > The intention is to use the new API VDSM.libvirtVm.updateVmInteface
> > for
> > performing the network rewire in a single command.
> 
> What does it do? I could not find updateVmInteface in vdsm git.
> Where is this defined?
The wiki was updated, you can find it there.
http://wiki.ovirt.org/wiki/Feature/DetailedNetworkWiring#VDSM_API
> 
> It's critical.
> 
> - You can change the interface directly by moving the VM from one
> network to another
> - You can do that but toggle the ling state so the VM will be aware.
> 
> Which if these two?
> If you do only the first then it's not the common use case. In most
> cases you must toggle the link status to the VM.
> This will cause:
> 1. Speed negotiation + arp request that also informs the switched
> about the change
> 2. In case it's DHCP (which most likely the case for guests) it will
> trigger new DHCP request.
> 
> If you don't baaad things will happen :)
> 
> > 
> > > 
> > > Any other state may change network freely.
> > > 
> > > To change name - it's just DB, so any state goes
> > > 
> > > To change type or MAC address (= property), must go through
> > > unplug
> > > regardless to the wired state
> > > So:
> > > - Unplug
> > > - Change property
> > > - Plug
> > > 
> > > Again should probably ask the user to do these 3 steps so he'll
> > > know what he is doing, but we can do it for him with proper
> > > warning.
> > > 
> > > I also wander I do we have to drop the PCI address in the
> > > persisted
> > > table in this case - loosing the PCI location is redundant and
> > > will cause a move to another eth0 number in the guest. On the
> > > other hand changing of MAC may break network scripts anyhow - so
> > > I
> > > don't have a strong argument to keep it.
> > > 
> > > 
> > > Another issue:
> > > If the nic is there to be use by a hook, then you probably want
> > > to
> > > allow 'none' network.
> > > This may also be useful when allowing to purge a network while it
> > > is connected to VMs: unwire on all nics and connect to the none
> > > network.
> > > 
> > > 
> > > Overall, looking great, and I like the wired vs unplugged that
> > > emulate real behavior.
> > > 
> > > Regards,
> > > Simon
> > > 
> > > 
> > >  
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > >> From: "Alona Kaplan" <alkaplan at redhat.com>
> > >> To: engine-devel at ovirt.org, "Simon Grinberg"
> > >> <sgrinber at redhat.com>, rhevm-qe-network at redhat.com
> > >> Sent: Tuesday, November 13, 2012 4:46:52 PM
> > >> Subject: Network Wiring
> > >>
> > >> Hi all,
> > >>
> > >> Please review the wiki and add your comments.
> > >>
> > >> http://wiki.ovirt.org/wiki/Feature/NetworkWiring
> > >>
> > >>
> > >> Thanks,
> > >> Alona.
> > >>
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>