8:46 a.m.
Hi all,
Please review the wiki and add your comments.
http://wiki.ovirt.org/wiki/Feature/NetworkWiring
Thanks,
Alona.
11:58 a.m.
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.
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.
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(a)redhat.com>
To: engine-devel(a)ovirt.org, "Simon Grinberg" <sgrinber(a)redhat.com>,
rhevm-qe-network(a)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.
1:55 p.m.
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.
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(a)redhat.com>
> To: engine-devel(a)ovirt.org, "Simon Grinberg" <sgrinber(a)redhat.com>,
rhevm-qe-network(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
1:12 p.m.
----- Original Message -----
From: "Moti Asayag" <masayag(a)redhat.com>
To: "Simon Grinberg" <simon(a)redhat.com>
Cc: rhevm-qe-network(a)redhat.com, engine-devel(a)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(a)redhat.com>
>> To: engine-devel(a)ovirt.org, "Simon Grinberg"
>> <sgrinber(a)redhat.com>, rhevm-qe-network(a)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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
6:29 a.m.
On Wed, Nov 14, 2012 at 02:12:07PM -0500, Simon Grinberg wrote:
>
> 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 :)
I think that baaaaad things are going to happen anyway. In "baaaaad
things", I mean "stuff that require guest intervension".
The guest may be moved from one subnet into another one, maybe on
different VLAN or physical LAN. We can not expect that the applications
running on it will be happy about these changes. A similar case appears
if we rewire the network while the VM is down (or hibernated). When the
VM is restarted, it is going to use mismatching IP addresses.
You are right that it may make sense to request an new IP address after
the rewiring, however, a little test I just did on my desktop showed that
dhclient does not initiate a new request just because the carrier
dropped for few seconds. So we should try harder if we want to refresh
dhcp after rewiring: I think that it would be cool to have a guest agent verb
that does it.
Dan.
6:33 a.m.
On 11/15/2012 02:29 PM, Dan Kenigsberg wrote:
On Wed, Nov 14, 2012 at 02:12:07PM -0500, Simon Grinberg wrote:
>>
>> 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 :)
I think that baaaaad things are going to happen anyway. In "baaaaad
things", I mean "stuff that require guest intervension".
The guest may be moved from one subnet into another one, maybe on
different VLAN or physical LAN. We can not expect that the applications
running on it will be happy about these changes. A similar case appears
if we rewire the network while the VM is down (or hibernated). When the
VM is restarted, it is going to use mismatching IP addresses.
You are right that it may make sense to request an new IP address after
the rewiring, however, a little test I just did on my desktop showed that
dhclient does not initiate a new request just because the carrier
dropped for few seconds. So we should try harder if we want to refresh
dhcp after rewiring: I think that it would be cool to have a guest agent verb
that does it.
shouldn't this simulate a link disconnect/connect event to the OS?
6:43 a.m.
On 11/15/2012 02:33 PM, Itamar Heim wrote:
On 11/15/2012 02:29 PM, Dan Kenigsberg wrote:
> On Wed, Nov 14, 2012 at 02:12:07PM -0500, Simon Grinberg wrote:
>>>
>>> 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 :)
>
> I think that baaaaad things are going to happen anyway. In "baaaaad
> things", I mean "stuff that require guest intervension".
>
> The guest may be moved from one subnet into another one, maybe on
> different VLAN or physical LAN. We can not expect that the applications
> running on it will be happy about these changes. A similar case appears
> if we rewire the network while the VM is down (or hibernated). When the
> VM is restarted, it is going to use mismatching IP addresses.
>
> You are right that it may make sense to request an new IP address after
> the rewiring, however, a little test I just did on my desktop showed
> that
> dhclient does not initiate a new request just because the carrier
> dropped for few seconds. So we should try harder if we want to refresh
> dhcp after rewiring: I think that it would be cool to have a guest
> agent verb
> that does it.
Blame your OS if it doesn't do media sensing at all (or correctly).
shouldn't this simulate a link disconnect/connect event to the OS?
I sincerely hope it does.
Y.
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
7:36 a.m.
On Thu, Nov 15, 2012 at 02:43:23PM +0200, Yaniv Kaul wrote:
On 11/15/2012 02:33 PM, Itamar Heim wrote:
>On 11/15/2012 02:29 PM, Dan Kenigsberg wrote:
>>On Wed, Nov 14, 2012 at 02:12:07PM -0500, Simon Grinberg wrote:
>>>>
>>>>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 :)
>>
>>I think that baaaaad things are going to happen anyway. In "baaaaad
>>things", I mean "stuff that require guest intervension".
>>
>>The guest may be moved from one subnet into another one, maybe on
>>different VLAN or physical LAN. We can not expect that the applications
>>running on it will be happy about these changes. A similar case appears
>>if we rewire the network while the VM is down (or hibernated). When the
>>VM is restarted, it is going to use mismatching IP addresses.
>>
>>You are right that it may make sense to request an new IP address after
>>the rewiring, however, a little test I just did on my desktop
>>showed that
>>dhclient does not initiate a new request just because the carrier
>>dropped for few seconds. So we should try harder if we want to refresh
>>dhcp after rewiring: I think that it would be cool to have a
>>guest agent verb
>>that does it.
Blame your OS if it doesn't do media sensing at all (or correctly).
Media is sensed:
Nov 15 14:15:46 kernel: [3379655.213183] e1000e: eth0 NIC Link is Down
Nov 15 14:15:52 kernel: [3379661.265946] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex,
Flow Control: None
Nov 15 14:15:52 kernel: [3379661.265951] e1000e 0000:00:19.0: eth0: 10/100 speed:
disabling TSO
but dhcp does not cancel its leases due to this. And I would not expect it to:
my dhcp server could change without carrier loss (e.g. vlan change on my
nearest switch, or dhcp reconfiguration)
>
>shouldn't this simulate a link disconnect/connect event to the OS?
I sincerely hope it does.
Itamar, what is "this"? Setting link state to down does just that.
I was suggesting a guest agent verb that clears all pending dhcp leases after
the guest is connected again.
Dan.
1:29 p.m.
----- Original Message -----
From: "Dan Kenigsberg" <danken(a)redhat.com>
To: "Yaniv Kaul" <ykaul(a)redhat.com>
Cc: "Simon Grinberg" <simon(a)redhat.com>, engine-devel(a)ovirt.org
Sent: Thursday, November 15, 2012 3:36:02 PM
Subject: Re: [Engine-devel] Network Wiring
On Thu, Nov 15, 2012 at 02:43:23PM +0200, Yaniv Kaul wrote:
> On 11/15/2012 02:33 PM, Itamar Heim wrote:
> >On 11/15/2012 02:29 PM, Dan Kenigsberg wrote:
> >>On Wed, Nov 14, 2012 at 02:12:07PM -0500, Simon Grinberg wrote:
> >>>>
> >>>>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 :)
> >>
> >>I think that baaaaad things are going to happen anyway. In
> >>"baaaaad
> >>things", I mean "stuff that require guest intervension".
> >>
> >>The guest may be moved from one subnet into another one, maybe on
> >>different VLAN or physical LAN. We can not expect that the
> >>applications
> >>running on it will be happy about these changes. A similar case
> >>appears
> >>if we rewire the network while the VM is down (or hibernated).
> >>When the
> >>VM is restarted, it is going to use mismatching IP addresses.
> >>
> >>You are right that it may make sense to request an new IP address
> >>after
> >>the rewiring, however, a little test I just did on my desktop
> >>showed that
> >>dhclient does not initiate a new request just because the carrier
> >>dropped for few seconds. So we should try harder if we want to
> >>refresh
> >>dhcp after rewiring: I think that it would be cool to have a
> >>guest agent verb
> >>that does it.
>
> Blame your OS if it doesn't do media sensing at all (or correctly).
Media is sensed:
Nov 15 14:15:46 kernel: [3379655.213183] e1000e: eth0 NIC Link is
Down
Nov 15 14:15:52 kernel: [3379661.265946] e1000e: eth0 NIC Link is Up
100 Mbps Full Duplex, Flow Control: None
Nov 15 14:15:52 kernel: [3379661.265951] e1000e 0000:00:19.0: eth0:
10/100 speed: disabling TSO
If you go trough link state toggle then I think it should be enough.
You are right, lot's of things get go wrong when you move a VM from network to
network, but at least we did inform the OS, and the switches in the new network will now
know there is a new MAC, the rest will have to wait until (and if) will support guest IP
stetting.
but dhcp does not cancel its leases due to this. And I would not
expect it to:
my dhcp server could change without carrier loss (e.g. vlan change on
my
nearest switch, or dhcp reconfiguration)
>
> >
> >shouldn't this simulate a link disconnect/connect event to the OS?
>
> I sincerely hope it does.
Itamar, what is "this"? Setting link state to down does just that.
I was suggesting a guest agent verb that clears all pending dhcp
leases after
the guest is connected again.
Dan.
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
7:32 a.m.
> 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(a)redhat.com>
> >> To: engine-devel(a)ovirt.org, "Simon Grinberg"
> >> <sgrinber(a)redhat.com>, rhevm-qe-network(a)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(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
9:34 a.m.
On 11/13/2012 04:46 PM, Alona Kaplan wrote:
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
The wording is wrong.
You PLUG/UNPLUG a cable.
You REMOVE/INSERT a card.
unwired means wireless.
Missing from the design is what actually happening. I assume you change
the link state. It might be worth while to just use 'link state:
up/down'. Anyone can understand that.
Y.
11:11 a.m.
----- Original Message -----
From: "Yaniv Kaul" <ykaul(a)redhat.com>
To: "Alona Kaplan" <alkaplan(a)redhat.com>
Cc: engine-devel(a)ovirt.org, "Simon Grinberg" <sgrinber(a)redhat.com>,
rhevm-qe-network(a)redhat.com
Sent: Wednesday, November 14, 2012 5:34:54 PM
Subject: Re: [Engine-devel] Network Wiring
On 11/13/2012 04:46 PM, Alona Kaplan wrote:
> 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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
The wording is wrong.
You PLUG/UNPLUG a cable.
You REMOVE/INSERT a card.
unwired means wireless.
Missing from the design is what actually happening. I assume you
change
the link state. It might be worth while to just use 'link state:
up/down'. Anyone can understand that.
You are right, however how do we avoid confusing with libvirt terminology having
REMOVE/INSERT as hot-plug/unplug?
However indeed wiring may still be changed to link state - need not confuse though with
internal OS terminology of interface up/down.
maybe on/off
Y.
9:57 p.m.
On 11/13/2012 04:46 PM, Alona Kaplan wrote:
Hi all,
Please review the wiki and add your comments.
http://wiki.ovirt.org/wiki/Feature/NetworkWiring
Dialog
If the VM status is 'UP'
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".
Port Mirroring - If the Vnic is plugged and the Vnic is
set for port mirroring - "network", "type", "mac" and
"port mirroring"
fields in the dialog will be disabled.
can user change the type if port mirroring isn't enabled? doesn't this
require unplug/plug back?
I assume all validations are at engine side to cover rest api as well?
REST API
NIC properties:
Changes:
Adding new properties under VM NIC:
plugged
wired
Deprecating the active property under VM NIC
Deprecating activate/deactivate actions
Plug/unplug and wire/unwire on a vnic, will be done via PUT
action on the VM
NIC
/api/vms/xxx/nics/yyy/
that's a lot of deprecation - you can mark them as deprecated, but they
still need to work over a period of time for backward compatibility, so
please explain what they will show/how they behave until they are
deprecated.
There is no reason to have dedicated actions for plug/unplug or
wire/unwire. The original reason for having them was that edit VM nic
while the VM was up used to be blocked and now we'll enable doing these
actions.
actually, some users may not want to make these config changes while the
VM is live, just to make them for the next boot. how will that work?
i agree with other comments that 'wired' is a bit confusing.
s/wired-unwired/connected-disconnected/?
1:36 a.m.
On 11/15/2012 05:57 AM, Itamar Heim wrote:
On 11/13/2012 04:46 PM, Alona Kaplan wrote:
> Hi all,
>
> Please review the wiki and add your comments.
>
> http://wiki.ovirt.org/wiki/Feature/NetworkWiring
> Dialog
>
> If the VM status is 'UP'
>
> 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".
> Port Mirroring - If the Vnic is plugged and the Vnic is set for port
mirroring - "network", "type", "mac" and "port
mirroring" fields in the dialog will be
disabled.
can user change the type if port mirroring isn't enabled? doesn't this require
unplug/plug back?
I assume all validations are at engine side to cover rest api as well?
> REST API
>
> NIC properties:
>
> Changes:
>
> Adding new properties under VM NIC:
>
> plugged
> wired
>
> Deprecating the active property under VM NIC
> Deprecating activate/deactivate actions
> Plug/unplug and wire/unwire on a vnic, will be done via PUT action on the VM NIC
> /api/vms/xxx/nics/yyy/
>
that's a lot of deprecation - you can mark them as deprecated, but they still need to
work over a period of time for backward compatibility, so please explain what they
will show/how they behave until they are deprecated.
> There is no reason to have dedicated actions for plug/unplug or wire/unwire. The
original reason for having them was that edit VM nic while the VM was up used to be
blocked and now we'll enable doing these actions.
actually, some users may not want to make these config changes while the VM is live, just
to make them for the next boot. how will that work?
i agree with other comments that 'wired' is a bit confusing.
s/wired-unwired/connected-disconnected/?
NX users may confuse between connected to vm or connected to the switch (despite of
<plugged>),
as they used to <link>=up|down<link/>
--
Michael Pasternak
RedHat, ENG-Virtualization R&D
2:04 p.m.
NX users may confuse between connected to vm or connected to the
switch (despite of <plugged>),
as they used to <link>=up|down<link/>
Yap, no convergence on terminology yet, right?
I think we need to keep the plugged/unplugged not to confuse libvirt users
however let's do wired/un-wired = link-up / link-down it's understood by everyone
and Michael pointed out
What about allowing a nic with the no-network? Did not see discussion on this.
It is useful as an interim state when changing networks or if the nic is there to be use
by a hook. This may also be useful when allowing to purge a network while it is connected
to VMs: Link-Down on all nics and connect to the empty/no network. (Yes I know, it's
not par of the feature, but you know someone will ask for it soon :))
The coupling between vNIC and LN should break - for this feature (that I hate to call it
wired) and for future to come.
Simon.
3:29 p.m.
On Thu, Nov 15, 2012 at 03:04:45PM -0500, Simon Grinberg wrote:
>
> NX users may confuse between connected to vm or connected to the
> switch (despite of <plugged>),
> as they used to <link>=up|down<link/>
>
Yap, no convergence on terminology yet, right?
I think we need to keep the plugged/unplugged not to confuse libvirt users
Yes, with real iron nics (and hard drives), the term
"hotplug" is widely understood as "shove a new device into a running
machine". So I see no reason to change anything.
But I do not see how this is related to libvirt (which does not have an
API call named *plug*).
however let's do wired/un-wired = link-up / link-down it's
understood by everyone and Michael pointed out
I'm fine with that.
What about allowing a nic with the no-network? Did not see discussion on this.
It is useful as an interim state when changing networks or if the
nic
is there to be use by a hook. This may also be useful when allowing to
purge a network while it is connected to VMs: Link-Down on all nics
and connect to the empty/no network. (Yes I know, it's not par of the
feature, but you know someone will ask for it soon :))
It should not be hard to implement; In
http://wiki.ovirt.org/wiki/Feature/DetailedNetworkWiring#New_API I suggest passing
no 'network' element to mean "connected to nothing".
The coupling between vNIC and LN should break - for this feature (that I hate to call it
wired) and for future to come.
Simon.
4:01 a.m.
> > NX users may confuse between connected to vm or connected
to the
> > switch (despite of <plugged>),
> > as they used to <link>=up|down<link/>
> >
>
> Yap, no convergence on terminology yet, right?
>
> I think we need to keep the plugged/unplugged not to confuse
> libvirt users
Yes, with real iron nics (and hard drives), the term
"hotplug" is widely understood as "shove a new device into a running
machine". So I see no reason to change anything.
But I do not see how this is related to libvirt (which does not have
an
API call named *plug*).
> however let's do wired/un-wired = link-up / link-down it's
> understood by everyone and Michael pointed out
I'm fine with that.
I"ve updated the wiki with the term "link
state" instead of "wired/unwired".
>
> What about allowing a nic with the no-network? Did not see
> discussion on this.
> It is useful as an interim state when changing networks or if the
> nic
> is there to be use by a hook. This may also be useful when allowing
> to
> purge a network while it is connected to VMs: Link-Down on all nics
> and connect to the empty/no network. (Yes I know, it's not par of
> the
> feature, but you know someone will ask for it soon :))
It should not be hard to implement; In
http://wiki.ovirt.org/wiki/Feature/DetailedNetworkWiring#New_API I
suggest passing
no 'network' element to mean "connected to nothing".
I don't really understand why changing the link state to down is not enough?
What is the added value of connecting "unwired" nic to a none network?
>
> The coupling between vNIC and LN should break - for this feature
> (that I hate to call it wired) and for future to come.
>
> Simon.
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
5:12 a.m.
On Sun, Nov 18, 2012 at 05:01:30AM -0500, Alona Kaplan wrote:
<snip>
> > > purge a network while it is connected to VMs: Link-Down on all nics
> > > and connect to the empty/no network. (Yes I know, it's not par of
> > > the
> > > feature, but you know someone will ask for it soon :))
> > > It should not be hard to implement; In
> > http://wiki.ovirt.org/wiki/Feature/DetailedNetworkWiring#New_API I
> > suggest passing
> > no 'network' element to mean "connected to nothing".
> >
> I don't really understand why changing the link state to down is not enough?
> What is the added value of connecting "unwired" nic to a none network?
It is not a big deal of a difference, but the semantics of having no
network is clear: you can run the VM if networks are missing, you can
remove a network when the VM is running. When a VM is associated to a
network, but its link state is down, the "right" semantics is more
vague.
5:28 a.m.
----- Original Message -----
From: "Dan Kenigsberg" <danken(a)redhat.com>
To: "Alona Kaplan" <alkaplan(a)redhat.com>
Cc: "Simon Grinberg" <simon(a)redhat.com>, engine-devel(a)ovirt.org
Sent: Sunday, November 18, 2012 1:12:05 PM
Subject: Re: [Engine-devel] Network Wiring
On Sun, Nov 18, 2012 at 05:01:30AM -0500, Alona Kaplan wrote:
>
<snip>
> > > purge a network while it is connected to VMs: Link-Down on all
> > > nics
> > > and connect to the empty/no network. (Yes I know, it's not par
> > > of
> > > the
> > > feature, but you know someone will ask for it soon :))
> >
> > It should not be hard to implement; In
> > http://wiki.ovirt.org/wiki/Feature/DetailedNetworkWiring#New_API
> > I
> > suggest passing
> > no 'network' element to mean "connected to nothing".
> >
> I don't really understand why changing the link state to down is
> not enough?
> What is the added value of connecting "unwired" nic to a none
> network?
It is not a big deal of a difference, but the semantics of having no
network is clear: you can run the VM if networks are missing, you can
remove a network when the VM is running. When a VM is associated to a
network, but its link state is down, the "right" semantics is more
vague.
Indeed :)
Plus consider the use case of hooks providing the networking - they still need the engine
to assign the MAC and type (like the CISCO hook).
If you force a logical network on each nic, it means you have to invent a dummy LN and
define it as non-required and set the global config to allow VMs to run on hosts that do
not have this networks - Too messy. Though sometimes desirable since the network name may
be a hint to the hook, there are cases it's not.
-> No LN means this VM can run on any host! with implicit assumption that someone else
takes care of connecting it to the proper network.
Note that in this case you may still want the network with link state up and be allowed to
bring the link up/down so it's for sure not the case as 'unwired/link down but
connected to arbitrary network'
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
9:06 a.m.
> <snip>
>
> > > > purge a network while it is connected to VMs: Link-Down on
> > > > all
> > > > nics
> > > > and connect to the empty/no network. (Yes I know, it's not
> > > > par
> > > > of
> > > > the
> > > > feature, but you know someone will ask for it soon :))
> > >
> > > It should not be hard to implement; In
> > > http://wiki.ovirt.org/wiki/Feature/DetailedNetworkWiring#New_API
> > > I
> > > suggest passing
> > > no 'network' element to mean "connected to nothing".
> > >
> > I don't really understand why changing the link state to down is
> > not enough?
> > What is the added value of connecting "unwired" nic to a none
> > network?
>
> It is not a big deal of a difference, but the semantics of having
> no
> network is clear: you can run the VM if networks are missing, you
> can
> remove a network when the VM is running. When a VM is associated to
> a
> network, but its link state is down, the "right" semantics is more
> vague.
Indeed :)
Plus consider the use case of hooks providing the networking - they
still need the engine to assign the MAC and type (like the CISCO
hook).
If you force a logical network on each nic, it means you have to
invent a dummy LN and define it as non-required and set the global
config to allow VMs to run on hosts that do not have this networks -
Too messy. Though sometimes desirable since the network name may be
a hint to the hook, there are cases it's not.
-> No LN means this VM can run on any host! with implicit assumption
that someone else takes care of connecting it to the proper network.
Note that in this case you may still want the network with link state
up and be allowed to bring the link up/down so it's for sure not the
case as 'unwired/link down but connected to arbitrary network'
I"ve added "none" network option to the wiki.
Any more comments? Do we have green light to start working on the feature?
12:57 a.m.
On 18/11/12 17:06, Alona Kaplan wrote:
>> <snip>
>>
>>>>> purge a network while it is connected to VMs: Link-Down on
>>>>> all
>>>>> nics
>>>>> and connect to the empty/no network. (Yes I know, it's not
>>>>> par
>>>>> of
>>>>> the
>>>>> feature, but you know someone will ask for it soon :))
>>>>
>>>> It should not be hard to implement; In
>>>> http://wiki.ovirt.org/wiki/Feature/DetailedNetworkWiring#New_API
>>>> I
>>>> suggest passing
>>>> no 'network' element to mean "connected to nothing".
>>>>
>>> I don't really understand why changing the link state to down is
>>> not enough?
>>> What is the added value of connecting "unwired" nic to a none
>>> network?
>>
>> It is not a big deal of a difference, but the semantics of having
>> no
>> network is clear: you can run the VM if networks are missing, you
>> can
>> remove a network when the VM is running. When a VM is associated to
>> a
>> network, but its link state is down, the "right" semantics is more
>> vague.
>
> Indeed :)
>
> Plus consider the use case of hooks providing the networking - they
> still need the engine to assign the MAC and type (like the CISCO
> hook).
> If you force a logical network on each nic, it means you have to
> invent a dummy LN and define it as non-required and set the global
> config to allow VMs to run on hosts that do not have this networks -
> Too messy. Though sometimes desirable since the network name may be
> a hint to the hook, there are cases it's not.
>
> -> No LN means this VM can run on any host! with implicit assumption
> that someone else takes care of connecting it to the proper network.
>
> Note that in this case you may still want the network with link state
> up and be allowed to bring the link up/down so it's for sure not the
> case as 'unwired/link down but connected to arbitrary network'
>
I"ve added "none" network option to the wiki.
Any more comments? Do we have green light to start working on the feature?
+1 for the high level design naming and behavior.
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
5:12 a.m.
----- Original Message -----
From: "Livnat Peer" <lpeer(a)redhat.com>
To: "Alona Kaplan" <alkaplan(a)redhat.com>
Cc: "Simon Grinberg" <simon(a)redhat.com>, engine-devel(a)ovirt.org
Sent: Tuesday, November 20, 2012 8:57:20 AM
Subject: Re: [Engine-devel] Network Wiring
On 18/11/12 17:06, Alona Kaplan wrote:
>
>>> <snip>
>>>
>>>>>> purge a network while it is connected to VMs: Link-Down on
>>>>>> all
>>>>>> nics
>>>>>> and connect to the empty/no network. (Yes I know, it's not
>>>>>> par
>>>>>> of
>>>>>> the
>>>>>> feature, but you know someone will ask for it soon :))
>>>>>
>>>>> It should not be hard to implement; In
>>>>> http://wiki.ovirt.org/wiki/Feature/DetailedNetworkWiring#New_API
>>>>> I
>>>>> suggest passing
>>>>> no 'network' element to mean "connected to
nothing".
>>>>>
>>>> I don't really understand why changing the link state to down is
>>>> not enough?
>>>> What is the added value of connecting "unwired" nic to a none
>>>> network?
>>>
>>> It is not a big deal of a difference, but the semantics of having
>>> no
>>> network is clear: you can run the VM if networks are missing, you
>>> can
>>> remove a network when the VM is running. When a VM is associated
>>> to
>>> a
>>> network, but its link state is down, the "right" semantics is
>>> more
>>> vague.
>>
>> Indeed :)
>>
>> Plus consider the use case of hooks providing the networking -
>> they
>> still need the engine to assign the MAC and type (like the CISCO
>> hook).
>> If you force a logical network on each nic, it means you have to
>> invent a dummy LN and define it as non-required and set the global
>> config to allow VMs to run on hosts that do not have this networks
>> -
>> Too messy. Though sometimes desirable since the network name may
>> be
>> a hint to the hook, there are cases it's not.
>>
>> -> No LN means this VM can run on any host! with implicit
>> assumption
>> that someone else takes care of connecting it to the proper
>> network.
>>
>> Note that in this case you may still want the network with link
>> state
>> up and be allowed to bring the link up/down so it's for sure not
>> the
>> case as 'unwired/link down but connected to arbitrary network'
>>
>
> I"ve added "none" network option to the wiki.
> Any more comments? Do we have green light to start working on the
> feature?
+1 for the high level design naming and behavior.
+1 as well, I think we've converged here.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
3:36 a.m.
New subject: [Engine-devel] OvfAutoUpdater
http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
Hi all, i'll be glad if you could review the wiki page of OvfAutoUpdater, if you have
any suggestions or ideas please let me know.
http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
short preview from the wiki:
vm/template configurations (including disks info) are stored on the master storage domain
for backup purposes, import/export and also to provide the abillity to run VMs without
having a running engine/db. Currently ovf update is done synchronously when performing
various operations on vms/templates - update, save, adding/removing a disk, etc.
What's more, currently updating the ovf (updateVM vdsm call) is usually done within a
transcation.
The idea behined OvfAutoUpdater is to perform batch ovf update operations that aggregate
all outstanding updates per data center. These updates will be done in specifed time
intervals which will reduce XML-RPC calls and will enable the removal of this syncronous
vdsm call from all over the code.
Thanks,
Liron Aravot.
5:13 a.m.
On 15/11/12 05:57, Itamar Heim wrote:
On 11/13/2012 04:46 PM, Alona Kaplan wrote:
> Hi all,
>
> Please review the wiki and add your comments.
>
> http://wiki.ovirt.org/wiki/Feature/NetworkWiring
> Dialog
>
> If the VM status is 'UP'
>
> 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".
> Port Mirroring - If the Vnic is plugged and the Vnic is
set for port mirroring - "network", "type", "mac" and
"port mirroring"
fields in the dialog will be disabled.
can user change the type if port mirroring isn't enabled? doesn't this
require unplug/plug back?
It does (see the first message written in the paragraph you copied, "if
changing type or MAC unplug and plug of the device is performed.") and
that's the action the engine will trigger.
I assume all validations are at engine side to cover rest api as
well?
of course
> REST API
>
> NIC properties:
>
> Changes:
>
> Adding new properties under VM NIC:
>
> plugged
> wired
>
> Deprecating the active property under VM NIC
> Deprecating activate/deactivate actions
> Plug/unplug and wire/unwire on a vnic, will be done via PUT action
on the VM NIC
> /api/vms/xxx/nics/yyy/
>
that's a lot of deprecation - you can mark them as deprecated, but they
still need to work over a period of time for backward compatibility, so
please explain what they will show/how they behave until they are
deprecated.
Same as today, they will perform plug and unplug , in the API you'll be
able to plug/unplug in two ways the deprecated one (use action) or via
edit vNic. the active property will be there as well, it will show the
same value a the plugged property.
> There is no reason to have dedicated actions for plug/unplug or
wire/unwire. The original reason for having them was that edit VM nic
while the VM was up used to be blocked and now we'll enable doing these
actions.
actually, some users may not want to make these config changes while the
VM is live, just to make them for the next boot. how will that work?
Well as long as we don't have separation for configuration and running
configuration it won't work. (same as changing the CPU or memory for
next VM run)
i agree with other comments that 'wired' is a bit confusing.
s/wired-unwired/connected-disconnected/?
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
4174
days inactive
4181
days old
23 comments
9 participants
participants (9)
-
Alona Kaplan -
Dan Kenigsberg -
Itamar Heim -
Liron Aravot -
Livnat Peer -
Michael Pasternak -
Moti Asayag -
Simon Grinberg -
Yaniv Kaul