[Engine-devel] Network Wiring

[Simon Grinberg]

----- Original Message -----
> From: "Moti Asayag" <masayag at redhat.com>
> To: "Simon Grinberg" <simon at redhat.com>
> Cc: rhevm-qe-network at redhat.com, engine-devel at ovirt.org
> Sent: Tuesday, November 13, 2012 9:55:22 PM
> Subject: Re: [Engine-devel] Network Wiring
> 
> 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? 

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
>