11:36 a.m.
Hi all,
This is a proposal for reporting the vNic implementation details as
reported by the guest agent per each vNic.
Please review the wiki and add your comments.
http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
Thanks,
Moti
2:53 p.m.
----- Original Message -----
From: "Moti Asayag" <masayag(a)redhat.com>
To: engine-devel(a)ovirt.org
Sent: Wednesday, November 21, 2012 12:36:58 PM
Subject: [Engine-devel] Report vNic Implementation Details
Hi all,
This is a proposal for reporting the vNic implementation details as
reported by the guest agent per each vNic.
Please review the wiki and add your comments.
While we're making the change is there anything else we'd want to report - MTU,
MAC (since a user might try to override), etc ?
http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
Thanks,
Moti
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
4:02 p.m.
On 11/21/2012 10:53 PM, Andrew Cathrow wrote:
----- Original Message -----
> From: "Moti Asayag" <masayag(a)redhat.com>
> To: engine-devel(a)ovirt.org
> Sent: Wednesday, November 21, 2012 12:36:58 PM
> Subject: [Engine-devel] Report vNic Implementation Details
>
> Hi all,
>
> This is a proposal for reporting the vNic implementation details as
> reported by the guest agent per each vNic.
>
> Please review the wiki and add your comments.
While we're making the change is there anything else we'd want to report - MTU,
MAC (since a user might try to override), etc ?
>
> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
iirc, the fact ip addresses appear under guest info in the api and not
under the vnic was a modeling decision.
for example, what if guest is using a bridge, or a bond (yes, sounds
unlikely, but the point is it may be incorrect to assume ip-vnic relation.
michael - do you remember the details of that discussion?
1:55 a.m.
On 22/11/12 00:02, Itamar Heim wrote:
On 11/21/2012 10:53 PM, Andrew Cathrow wrote:
>
>
> ----- Original Message -----
>> From: "Moti Asayag" <masayag(a)redhat.com>
>> To: engine-devel(a)ovirt.org
>> Sent: Wednesday, November 21, 2012 12:36:58 PM
>> Subject: [Engine-devel] Report vNic Implementation Details
>>
>> Hi all,
>>
>> This is a proposal for reporting the vNic implementation details as
>> reported by the guest agent per each vNic.
>>
>> Please review the wiki and add your comments.
>
>
> While we're making the change is there anything else we'd want to
> report - MTU, MAC (since a user might try to override), etc ?
>>
>> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
iirc, the fact ip addresses appear under guest info in the api and not
under the vnic was a modeling decision.
for example, what if guest is using a bridge, or a bond (yes, sounds
unlikely, but the point is it may be incorrect to assume ip-vnic relation.
michael - do you remember the details of that discussion?
I'd love to know what drove this modeling decision.
The use case above is not a typical use case.
We know we won't be able to present the guest internal network
configuration accurately in some scenarios but if we cover 90% of the
use cases correctly I think we should not let perfect be the enemy of
(very) good ;)
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
5:59 a.m.
On Thu, Nov 22, 2012 at 09:55:43AM +0200, Livnat Peer wrote:
On 22/11/12 00:02, Itamar Heim wrote:
> On 11/21/2012 10:53 PM, Andrew Cathrow wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Moti Asayag" <masayag(a)redhat.com>
>>> To: engine-devel(a)ovirt.org
>>> Sent: Wednesday, November 21, 2012 12:36:58 PM
>>> Subject: [Engine-devel] Report vNic Implementation Details
>>>
>>> Hi all,
>>>
>>> This is a proposal for reporting the vNic implementation details as
>>> reported by the guest agent per each vNic.
>>>
>>> Please review the wiki and add your comments.
>>
>>
>> While we're making the change is there anything else we'd want to
>> report - MTU, MAC (since a user might try to override), etc ?
>>>
>>> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
>
> iirc, the fact ip addresses appear under guest info in the api and not
> under the vnic was a modeling decision.
> for example, what if guest is using a bridge, or a bond (yes, sounds
> unlikely, but the point is it may be incorrect to assume ip-vnic relation.
> michael - do you remember the details of that discussion?
I'd love to know what drove this modeling decision.
The use case above is not a typical use case.
We know we won't be able to present the guest internal network
configuration accurately in some scenarios but if we cover 90% of the
use cases correctly I think we should not let perfect be the enemy of
(very) good ;)
We do not support this yet, but once we have nested virtualization, it
won't be that odd to have a bridge or bond in the guest. I know that we
already have users with in-guest vlan devices.
I think that the api should accomodate these configurations - even if we
do not report them right away. The guest agent already reports (some) of
the information:
The Guest Agent reports the vNic details:
IP addresses (both IPv4 and IPv6).
vNic internal name
Actually, the guest agent reports all in-guest network device. vNics (and bonds
and vlans) included.
The retrieved information by the Guest Agent should be reported to the ovirt-engine and
to be viewed by its client
Today only the IPv4 addresses are reported to the User, kept on VM level. This feature
will maintain the information on vNic level.
I think we should report the information on the vNic level only when we
can. If we have a vlan device, which we do not know how tie to a
specific vNic, we'd better report its IP address on the VM level.
It might be worthwhile to note that we should (try to) correlate Engine
idea of a vNic with the guest agent report, according to the mac address.
The guest can try to fool us by changing the mac address, but that's
true for every bit of info coming from the agent.
Dan.
1:02 a.m.
On 22/11/12 13:59, Dan Kenigsberg wrote:
On Thu, Nov 22, 2012 at 09:55:43AM +0200, Livnat Peer wrote:
> On 22/11/12 00:02, Itamar Heim wrote:
>> On 11/21/2012 10:53 PM, Andrew Cathrow wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Moti Asayag" <masayag(a)redhat.com>
>>>> To: engine-devel(a)ovirt.org
>>>> Sent: Wednesday, November 21, 2012 12:36:58 PM
>>>> Subject: [Engine-devel] Report vNic Implementation Details
>>>>
>>>> Hi all,
>>>>
>>>> This is a proposal for reporting the vNic implementation details as
>>>> reported by the guest agent per each vNic.
>>>>
>>>> Please review the wiki and add your comments.
>>>
>>>
>>> While we're making the change is there anything else we'd want to
>>> report - MTU, MAC (since a user might try to override), etc ?
>>>>
>>>> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
>>
>> iirc, the fact ip addresses appear under guest info in the api and not
>> under the vnic was a modeling decision.
>> for example, what if guest is using a bridge, or a bond (yes, sounds
>> unlikely, but the point is it may be incorrect to assume ip-vnic relation.
>> michael - do you remember the details of that discussion?
>
> I'd love to know what drove this modeling decision.
> The use case above is not a typical use case.
> We know we won't be able to present the guest internal network
> configuration accurately in some scenarios but if we cover 90% of the
> use cases correctly I think we should not let perfect be the enemy of
> (very) good ;)
We do not support this yet, but once we have nested virtualization, it
won't be that odd to have a bridge or bond in the guest. I know that we
already have users with in-guest vlan devices.
The fact that it's not odd does not mean it is common.., which was the
point I was trying to make.
I agree that we should be able to accommodate such info, not sure that
it is required at this point.
I think that the api should accomodate these configurations - even if
we
do not report them right away. The guest agent already reports (some) of
the information:
Which API are you referring to? if you are talking about VDSM-Engine API
we do not change it, only use what is already reported by the GA. I
don't think we should change the API for future support...
> The Guest Agent reports the vNic details:
>
> IP addresses (both IPv4 and IPv6).
> vNic internal name
Actually, the guest agent reports all in-guest network device. vNics (and bonds
and vlans) included.
true, but AFAIU we won't be able to build the networking topology of the
guest from this report. For example if the guest agent reports a bridge
it does not say to which interface it is connected to etc.
>
> The retrieved information by the Guest Agent should be reported to the ovirt-engine
and to be viewed by its client
> Today only the IPv4 addresses are reported to the User, kept on VM level. This
feature will maintain the information on vNic level.
I think we should report the information on the vNic level only when we
can. If we have a vlan device, which we do not know how tie to a
specific vNic, we'd better report its IP address on the VM level.
If I understand you correctly you are suggesting to keep the IP address
property also on the VM level and for devices with reported IP-address
which the engine can not correlate to a VNIC hold it on this VM-level
property.
My concern is that in the UI we are currently displaying in the main
greed the VM IP and on the network sub-tab the IP per vNIC.
If we choose to hold the IP addresses the engine does not correlate on
the VM level they become the more visible addresses for the users which
I am not sure is what we want.
What I suggest is to add a property to VM that says network devices and
hold the GA report as a 'blob'. we can display this info in the API on
the VM level and in the UI maybe display it on the general sub-tab or
add a dialog on the network subtab.
It might be worthwhile to note that we should (try to) correlate Engine
idea of a vNic with the guest agent report, according to the mac address.
The guest can try to fool us by changing the mac address, but that's
true for every bit of info coming from the agent.
Dan.
11:34 a.m.
----- Original Message -----
From: "Livnat Peer" <lpeer(a)redhat.com>
To: "Dan Kenigsberg" <danken(a)redhat.com>
Cc: "Itamar Heim" <iheim(a)redhat.com>, "Simon Grinberg"
<simon(a)redhat.com>, engine-devel(a)ovirt.org
Sent: Friday, November 23, 2012 9:02:09 AM
Subject: Re: [Engine-devel] Report vNic Implementation Details
On 22/11/12 13:59, Dan Kenigsberg wrote:
> On Thu, Nov 22, 2012 at 09:55:43AM +0200, Livnat Peer wrote:
>> On 22/11/12 00:02, Itamar Heim wrote:
>>> On 11/21/2012 10:53 PM, Andrew Cathrow wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Moti Asayag" <masayag(a)redhat.com>
>>>>> To: engine-devel(a)ovirt.org
>>>>> Sent: Wednesday, November 21, 2012 12:36:58 PM
>>>>> Subject: [Engine-devel] Report vNic Implementation Details
>>>>>
>>>>> Hi all,
>>>>>
>>>>> This is a proposal for reporting the vNic implementation
>>>>> details as
>>>>> reported by the guest agent per each vNic.
>>>>>
>>>>> Please review the wiki and add your comments.
>>>>
>>>>
>>>> While we're making the change is there anything else we'd want
>>>> to
>>>> report - MTU, MAC (since a user might try to override), etc ?
>>>>>
>>>>> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
>>>
>>> iirc, the fact ip addresses appear under guest info in the api
>>> and not
>>> under the vnic was a modeling decision.
>>> for example, what if guest is using a bridge, or a bond (yes,
>>> sounds
>>> unlikely, but the point is it may be incorrect to assume ip-vnic
>>> relation.
>>> michael - do you remember the details of that discussion?
>>
>> I'd love to know what drove this modeling decision.
>> The use case above is not a typical use case.
>> We know we won't be able to present the guest internal network
>> configuration accurately in some scenarios but if we cover 90% of
>> the
>> use cases correctly I think we should not let perfect be the enemy
>> of
>> (very) good ;)
>
> We do not support this yet, but once we have nested virtualization,
> it
> won't be that odd to have a bridge or bond in the guest. I know
> that we
> already have users with in-guest vlan devices.
>
The fact that it's not odd does not mean it is common.., which was
the
point I was trying to make.
I agree that we should be able to accommodate such info, not sure
that
it is required at this point.
At this point what you need to make sure is that if it does exit you do not crash due to
unexpected data.
Don't forget that using a hook you may create nested virtualization today.
> I think that the api should accomodate these configurations - even
> if we
> do not report them right away. The guest agent already reports
> (some) of
> the information:
>
Which API are you referring to? if you are talking about VDSM-Engine
API
we do not change it, only use what is already reported by the GA. I
don't think we should change the API for future support...
>> The Guest Agent reports the vNic details:
>>
>> IP addresses (both IPv4 and IPv6).
>> vNic internal name
>
> Actually, the guest agent reports all in-guest network device.
> vNics (and bonds
> and vlans) included.
true, but AFAIU we won't be able to build the networking topology of
the
guest from this report. For example if the guest agent reports a
bridge
it does not say to which interface it is connected to etc.
Actually in most cased it does since by default the bridge will get the interface IP.
Well not that accurate, the bridge gets the lowest IP the of all the devices it is
connected to, however there was a fix in libvirt some time back to make sure the external
interface IP will be the one the bride gets by providing the tap/tun devices connected to
the bridge a MAC address starting with 'FE'
>>
>> The retrieved information by the Guest Agent should be reported to
>> the ovirt-engine and to be viewed by its client
>> Today only the IPv4 addresses are reported to the User, kept on VM
>> level. This feature will maintain the information on vNic level.
>
> I think we should report the information on the vNic level only
> when we
> can. If we have a vlan device, which we do not know how tie to a
> specific vNic, we'd better report its IP address on the VM level.
If I understand you correctly you are suggesting to keep the IP
address
property also on the VM level and for devices with reported
IP-address
which the engine can not correlate to a VNIC hold it on this VM-level
property.
My concern is that in the UI we are currently displaying in the main
greed the VM IP and on the network sub-tab the IP per vNIC.
If we choose to hold the IP addresses the engine does not correlate
on
the VM level they become the more visible addresses for the users
which
I am not sure is what we want.
What I suggest is to add a property to VM that says network devices
and
hold the GA report as a 'blob'. we can display this info in the API
on
the VM level and in the UI maybe display it on the general sub-tab or
add a dialog on the network subtab.
I think you should display it as correlated as possible - since I agree with you that the
common case is an IP set directly on the VNIC, it means in most cases you'll present
the right info in the right place. let's not allow 10% of the cases block us then
doing the right thing for the other 90.
Try to correlate based on MAC and present the internal name and IP as the guest info on
the same line with the Defined nic (In API they can (and should as Itamar noted) be
separated and probably held as a blob per your suggestion.
Now your problematic scenarios:
1. You have a single VLAN, bridge etc -> It translates to many entries with the same
MAC but only one has IP -> collapse all to 'Select to present the one that has
IP'.
2. You have a MAC that does not match -> Present this as a guest only device (IE new
line - instead of name say guest only), let the user see and correlate if he wants - it is
his network, if he did crazy things it's his problem)
3. Multiple bridges and Vlans -> Collect all IPs per MAC and collapse, then present as
above
From the 3 above I expect only the first to be found ATM and even that
is rare.
In the future we can work on what I've suggested in a previous email on this thread,
present a guest network topology same as you do for the host.
>
> It might be worthwhile to note that we should (try to) correlate
> Engine
> idea of a vNic with the guest agent report, according to the mac
> address.
> The guest can try to fool us by changing the mac address, but
> that's
> true for every bit of info coming from the agent.
>
> Dan.
>
12:11 a.m.
On Fri, Nov 23, 2012 at 09:02:09AM +0200, Livnat Peer wrote:
On 22/11/12 13:59, Dan Kenigsberg wrote:
> On Thu, Nov 22, 2012 at 09:55:43AM +0200, Livnat Peer wrote:
>> On 22/11/12 00:02, Itamar Heim wrote:
>>> On 11/21/2012 10:53 PM, Andrew Cathrow wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Moti Asayag" <masayag(a)redhat.com>
>>>>> To: engine-devel(a)ovirt.org
>>>>> Sent: Wednesday, November 21, 2012 12:36:58 PM
>>>>> Subject: [Engine-devel] Report vNic Implementation Details
>>>>>
>>>>> Hi all,
>>>>>
>>>>> This is a proposal for reporting the vNic implementation details as
>>>>> reported by the guest agent per each vNic.
>>>>>
>>>>> Please review the wiki and add your comments.
>>>>
>>>>
>>>> While we're making the change is there anything else we'd want
to
>>>> report - MTU, MAC (since a user might try to override), etc ?
>>>>>
>>>>> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
>>>
>>> iirc, the fact ip addresses appear under guest info in the api and not
>>> under the vnic was a modeling decision.
>>> for example, what if guest is using a bridge, or a bond (yes, sounds
>>> unlikely, but the point is it may be incorrect to assume ip-vnic relation.
>>> michael - do you remember the details of that discussion?
>>
>> I'd love to know what drove this modeling decision.
>> The use case above is not a typical use case.
>> We know we won't be able to present the guest internal network
>> configuration accurately in some scenarios but if we cover 90% of the
>> use cases correctly I think we should not let perfect be the enemy of
>> (very) good ;)
>
> We do not support this yet, but once we have nested virtualization, it
> won't be that odd to have a bridge or bond in the guest. I know that we
> already have users with in-guest vlan devices.
>
The fact that it's not odd does not mean it is common.., which was the
point I was trying to make.
I agree that we should be able to accommodate such info, not sure that
it is required at this point.
> I think that the api should accomodate these configurations - even if we
> do not report them right away. The guest agent already reports (some) of
> the information:
>
Which API are you referring to? if you are talking about VDSM-Engine API
we do not change it, only use what is already reported by the GA. I
don't think we should change the API for future support...
I was refering to the Engine API. Now that we are designing how guest IP
addresses are to be reported, we should think how to accomodate IP
addresses on non-nic devices.
I believe that the Engine API should replicate the guest agent API: give
a list of guest network devices, each one with its ethernet/ipv4/6
addresses.
I am less sure how we should correlate this information with the VNICs
defined on the VM. If we do not want to "taint" the VNIC with this dubious
information, we can leave this correlation (based on MAC address) to UI or user script.
Dan.
1:10 a.m.
On 25/11/12 08:11, Dan Kenigsberg wrote:
On Fri, Nov 23, 2012 at 09:02:09AM +0200, Livnat Peer wrote:
> On 22/11/12 13:59, Dan Kenigsberg wrote:
>> On Thu, Nov 22, 2012 at 09:55:43AM +0200, Livnat Peer wrote:
>>> On 22/11/12 00:02, Itamar Heim wrote:
>>>> On 11/21/2012 10:53 PM, Andrew Cathrow wrote:
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Moti Asayag" <masayag(a)redhat.com>
>>>>>> To: engine-devel(a)ovirt.org
>>>>>> Sent: Wednesday, November 21, 2012 12:36:58 PM
>>>>>> Subject: [Engine-devel] Report vNic Implementation Details
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> This is a proposal for reporting the vNic implementation details
as
>>>>>> reported by the guest agent per each vNic.
>>>>>>
>>>>>> Please review the wiki and add your comments.
>>>>>
>>>>>
>>>>> While we're making the change is there anything else we'd
want to
>>>>> report - MTU, MAC (since a user might try to override), etc ?
>>>>>>
>>>>>> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
>>>>
>>>> iirc, the fact ip addresses appear under guest info in the api and not
>>>> under the vnic was a modeling decision.
>>>> for example, what if guest is using a bridge, or a bond (yes, sounds
>>>> unlikely, but the point is it may be incorrect to assume ip-vnic
relation.
>>>> michael - do you remember the details of that discussion?
>>>
>>> I'd love to know what drove this modeling decision.
>>> The use case above is not a typical use case.
>>> We know we won't be able to present the guest internal network
>>> configuration accurately in some scenarios but if we cover 90% of the
>>> use cases correctly I think we should not let perfect be the enemy of
>>> (very) good ;)
>>
>> We do not support this yet, but once we have nested virtualization, it
>> won't be that odd to have a bridge or bond in the guest. I know that we
>> already have users with in-guest vlan devices.
>>
>
> The fact that it's not odd does not mean it is common.., which was the
> point I was trying to make.
> I agree that we should be able to accommodate such info, not sure that
> it is required at this point.
>
>
>> I think that the api should accomodate these configurations - even if we
>> do not report them right away. The guest agent already reports (some) of
>> the information:
>>
>
> Which API are you referring to? if you are talking about VDSM-Engine API
> we do not change it, only use what is already reported by the GA. I
> don't think we should change the API for future support...
I was refering to the Engine API. Now that we are designing how guest IP
addresses are to be reported, we should think how to accomodate IP
addresses on non-nic devices.
Currently the engine do not expose guest-network-devices other than
vNICs which were defined in the engine from the first place.
I suggested adding a blob (at VM level) to present the
network-devices-data reported by the guest agent.
So far I did not see on the users list any request for such info, so
maybe we can hold this addition back a little to see what requests our
users have for this.
I believe that the Engine API should replicate the guest agent API:
give
a list of guest network devices, each one with its ethernet/ipv4/6
addresses.
I am less sure how we should correlate this information with the VNICs
defined on the VM. If we do not want to "taint" the VNIC with this dubious
information, we can leave this correlation (based on MAC address) to UI or user script.
Dan.
2:18 a.m.
On 11/22/2012 12:02 AM, Itamar Heim wrote:
On 11/21/2012 10:53 PM, Andrew Cathrow wrote:
>
>
> ----- Original Message -----
>> From: "Moti Asayag" <masayag(a)redhat.com>
>> To: engine-devel(a)ovirt.org
>> Sent: Wednesday, November 21, 2012 12:36:58 PM
>> Subject: [Engine-devel] Report vNic Implementation Details
>>
>> Hi all,
>>
>> This is a proposal for reporting the vNic implementation details as
>> reported by the guest agent per each vNic.
>>
>> Please review the wiki and add your comments.
>
>
> While we're making the change is there anything else we'd want to report -
MTU, MAC (since a user might try to override), etc ?
>>
>> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
iirc, the fact ip addresses appear under guest info in the api and not under the vnic was
a modeling decision.
for example, what if guest is using a bridge, or a bond (yes, sounds unlikely, but the
point is it may be incorrect to assume ip-vnic relation.
michael - do you remember the details of that discussion?
indeed, unfortunately i can't recall exact discussion nor can find this thread in ML,
but afair this was the argument.
--
Michael Pasternak
RedHat, ENG-Virtualization R&D
1:48 a.m.
On 21/11/12 22:53, Andrew Cathrow wrote:
----- Original Message -----
> From: "Moti Asayag" <masayag(a)redhat.com>
> To: engine-devel(a)ovirt.org
> Sent: Wednesday, November 21, 2012 12:36:58 PM
> Subject: [Engine-devel] Report vNic Implementation Details
>
> Hi all,
>
> This is a proposal for reporting the vNic implementation details as
> reported by the guest agent per each vNic.
>
> Please review the wiki and add your comments.
While we're making the change is there anything else we'd want to report - MTU,
MAC (since a user might try to override), etc ?
About the MAC address - the engine uses the MAC address to correlate
between the guest-agent report and the VNICs defined in the engine. If
the GA reports a MAC that the engine does not recognize the engine can
not associate it with a VNIC.
What the engine can do is to issue a warning to the audit log in case
such a mismatch is recognized, Is that good enough?
About MTU - It is not being reported by the guest agent ATM (while IPv4
IPv6 and MAC are), If we'd like to have it I can open RFE for the GA to
report additional fields.
Livnat
>
> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
>
> Thanks,
> Moti
> _______________________________________________
> 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:05 a.m.
On Thu, Nov 22, 2012 at 09:48:19AM +0200, Livnat Peer wrote:
On 21/11/12 22:53, Andrew Cathrow wrote:
>
>
> ----- Original Message -----
>> From: "Moti Asayag" <masayag(a)redhat.com>
>> To: engine-devel(a)ovirt.org
>> Sent: Wednesday, November 21, 2012 12:36:58 PM
>> Subject: [Engine-devel] Report vNic Implementation Details
>>
>> Hi all,
>>
>> This is a proposal for reporting the vNic implementation details as
>> reported by the guest agent per each vNic.
>>
>> Please review the wiki and add your comments.
>
>
> While we're making the change is there anything else we'd want to report -
MTU, MAC (since a user might try to override), etc ?
>
About the MAC address - the engine uses the MAC address to correlate
between the guest-agent report and the VNICs defined in the engine. If
the GA reports a MAC that the engine does not recognize the engine can
not associate it with a VNIC.
What the engine can do is to issue a warning to the audit log in case
such a mismatch is recognized, Is that good enough?
Oops, I've been scooped...
The guest may also report devices with unknown MAC (bridge, vlan, dummy,
etc...), which is not a reason for alarm.
If the configured MAC is completely missing, a warning seems valid.
About MTU - It is not being reported by the guest agent ATM (while IPv4
IPv6 and MAC are), If we'd like to have it I can open RFE for the GA to
report additional fields.
9:32 a.m.
On 11/22/2012 08:48 AM, Livnat Peer wrote:
On 21/11/12 22:53, Andrew Cathrow wrote:
>
> ----- Original Message -----
>> From: "Moti Asayag" <masayag(a)redhat.com>
>> To: engine-devel(a)ovirt.org
>> Sent: Wednesday, November 21, 2012 12:36:58 PM
>> Subject: [Engine-devel] Report vNic Implementation Details
>>
>> Hi all,
>>
>> This is a proposal for reporting the vNic implementation details as
>> reported by the guest agent per each vNic.
>>
>> Please review the wiki and add your comments.
>
> While we're making the change is there anything else we'd want to report -
MTU, MAC (since a user might try to override), etc ?
>
About the MAC address - the engine uses the MAC address to correlate
between the guest-agent report and the VNICs defined in the engine. If
the GA reports a MAC that the engine does not recognize the engine can
not associate it with a VNIC.
What the engine can do is to issue a warning to the audit log in case
such a mismatch is recognized, Is that good enough?
About MTU - It is not being reported by the guest agent ATM (while IPv4
IPv6 and MAC are), If we'd like to have it I can open RFE for the GA to
report additional fields.
Well if there are changes needed for the GA, please let
me know soon, if
it should make it into 3.2.
Thanks.
Livnat
>
>> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
>>
>> Thanks,
>> Moti
>> _______________________________________________
>> 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
--
Regards,
Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
9:36 a.m.
On 11/21/2012 10:53 PM, Andrew Cathrow wrote:
----- Original Message -----
> From: "Moti Asayag" <masayag(a)redhat.com>
> To: engine-devel(a)ovirt.org
> Sent: Wednesday, November 21, 2012 12:36:58 PM
> Subject: [Engine-devel] Report vNic Implementation Details
>
> Hi all,
>
> This is a proposal for reporting the vNic implementation details as
> reported by the guest agent per each vNic.
>
> Please review the wiki and add your comments.
While we're making the change is there anything else we'd want to report - MTU,
MAC (since a user might try to override), etc ?
Do we support change of MAC from within the VM? Is it even working?
Y.
> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
>
> Thanks,
> Moti
> _______________________________________________
> 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:38 a.m.
----- Original Message -----
> >
> >
> >
> >> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
> >>
> >> Thanks,
> >> Moti
> >> _______________________________________________
> >> 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
From: "Yaniv Kaul" <ykaul(a)redhat.com>
To: "Andrew Cathrow" <acathrow(a)redhat.com>
Cc: "Moti Asayag" <masayag(a)redhat.com>, "Simon Grinberg"
<simon(a)redhat.com>, engine-devel(a)ovirt.org
Sent: Thursday, November 22, 2012 10:36:39 AM
Subject: Re: [Engine-devel] Report vNic Implementation Details
On 11/21/2012 10:53 PM, Andrew Cathrow wrote:
>
> ----- Original Message -----
>> From: "Moti Asayag" <masayag(a)redhat.com>
>> To: engine-devel(a)ovirt.org
>> Sent: Wednesday, November 21, 2012 12:36:58 PM
>> Subject: [Engine-devel] Report vNic Implementation Details
>>
>> Hi all,
>>
>> This is a proposal for reporting the vNic implementation details
>> as
>> reported by the guest agent per each vNic.
>>
>> Please review the wiki and add your comments.
>
> While we're making the change is there anything else we'd want to
> report - MTU, MAC (since a user might try to override), etc ?
Do we support change of MAC from within the VM? Is it even working?
Y.
Obviously they shouldn't change it but I can certainly imagine the case where it's
tried.
Either way - it's good to report as much as we can even if it's not in the UI but
in the api.
9:39 a.m.
On 11/22/2012 05:36 PM, Yaniv Kaul wrote:
On 11/21/2012 10:53 PM, Andrew Cathrow wrote:
>
> ----- Original Message -----
>> From: "Moti Asayag" <masayag(a)redhat.com>
>> To: engine-devel(a)ovirt.org
>> Sent: Wednesday, November 21, 2012 12:36:58 PM
>> Subject: [Engine-devel] Report vNic Implementation Details
>>
>> Hi all,
>>
>> This is a proposal for reporting the vNic implementation details as
>> reported by the guest agent per each vNic.
>>
>> Please review the wiki and add your comments.
>
> While we're making the change is there anything else we'd want to
> report - MTU, MAC (since a user might try to override), etc ?
Do we support change of MAC from within the VM? Is it even working?
Y.
Shouldn't work if the nwfilter rules are enabled (which are by default)
>
>
>
>> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
>>
>> Thanks,
>> Moti
>> _______________________________________________
>> 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
12:40 p.m.
Back to the original question:
What is most inconvenient for many users is:
1. The name we provide while creating the VNIC differs from the one in the guest
2. No correlation between IP and NIC
The current page covers for this but indeed as raised here does not cover what happens if
this information is not easy to retrieve due to non strait forward configurations.
What I suggest is,
For the short term:
- Agent to report the MACs, IPs and interface names if can be found, engine to match these
to the existing and show
Name In Engine| Name in guest | MAC | IP etc like the current feature page, but...
- If a match could not be found then just report Name in Engine N/A and then the rest and
keep it in dynamic only table.
This is useful for NICs created by hooks, advanced topology that we can't support ATM
etc.
*The above does require the agent to at least match MAC to IP.
Long term: The agent to report a topology the same as vdsm does (use same code at least
for Linux guests?) and present it similar to what we present in the host tab. In most
cases this will collapse to the short term.
MTU, is good to have in any of the two if we can get it.
More?
----- Original Message -----
From: "Moti Asayag" <masayag(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 22, 2012 5:39:53 PM
Subject: Re: [Engine-devel] Report vNic Implementation Details
On 11/22/2012 05:36 PM, Yaniv Kaul wrote:
> On 11/21/2012 10:53 PM, Andrew Cathrow wrote:
>>
>> ----- Original Message -----
>>> From: "Moti Asayag" <masayag(a)redhat.com>
>>> To: engine-devel(a)ovirt.org
>>> Sent: Wednesday, November 21, 2012 12:36:58 PM
>>> Subject: [Engine-devel] Report vNic Implementation Details
>>>
>>> Hi all,
>>>
>>> This is a proposal for reporting the vNic implementation details
>>> as
>>> reported by the guest agent per each vNic.
>>>
>>> Please review the wiki and add your comments.
>>
>> While we're making the change is there anything else we'd want to
>> report - MTU, MAC (since a user might try to override), etc ?
>
> Do we support change of MAC from within the VM? Is it even working?
> Y.
>
Shouldn't work if the nwfilter rules are enabled (which are by
default)
>
>>
>>
>>
>>> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
>>>
>>> Thanks,
>>> Moti
>>> _______________________________________________
>>> 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
3:18 p.m.
On 11/22/2012 08:40 PM, Simon Grinberg wrote:
Back to the original question:
What is most inconvenient for many users is:
1. The name we provide while creating the VNIC differs from the one in the guest
2. No correlation between IP and NIC
The current page covers for this but indeed as raised here does not cover what happens if
this information is not easy to retrieve due to non strait forward configurations.
What I suggest is,
For the short term:
- Agent to report the MACs, IPs and interface names if can be found, engine to match
these to the existing and show
Name In Engine| Name in guest | MAC | IP etc like the current feature page, but...
- If a match could not be found then just report Name in Engine N/A and then the rest and
keep it in dynamic only table.
This is useful for NICs created by hooks, advanced topology that we can't support ATM
etc.
*The above does require the agent to at least match MAC to IP.
Long term: The agent to report a topology the same as vdsm does (use same code at least
for Linux guests?) and present it similar to what we present in the host tab. In most
cases this will collapse to the short term.
MTU, is good to have in any of the two if we can get it.
More?
I don't think the guest agent ip information should be correlated to the
vnic engine information at rest api level.
the vm (and vnic) api provides the authoritative configuration
information of the guest as defined in the engine.
I don't think we should 'taint' it with untrusted data from the guest.
it would make sense to place there IPs configured/allocated by engine
when we deal with ip allocation though.
i.e., the guest info element in the rest api provides good separation
between engine level data, and guest agent data.
11:04 a.m.
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Simon Grinberg" <simon(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Thursday, November 22, 2012 11:18:48 PM
Subject: Re: [Engine-devel] Report vNic Implementation Details
On 11/22/2012 08:40 PM, Simon Grinberg wrote:
> Back to the original question:
>
> What is most inconvenient for many users is:
> 1. The name we provide while creating the VNIC differs from the one
> in the guest
> 2. No correlation between IP and NIC
>
> The current page covers for this but indeed as raised here does not
> cover what happens if this information is not easy to retrieve due
> to non strait forward configurations.
>
> What I suggest is,
>
> For the short term:
> - Agent to report the MACs, IPs and interface names if can be
> found, engine to match these to the existing and show
> Name In Engine| Name in guest | MAC | IP etc like the current
> feature page, but...
>
> - If a match could not be found then just report Name in Engine N/A
> and then the rest and keep it in dynamic only table.
> This is useful for NICs created by hooks, advanced topology that we
> can't support ATM etc.
>
> *The above does require the agent to at least match MAC to IP.
>
>
> Long term: The agent to report a topology the same as vdsm does
> (use same code at least for Linux guests?) and present it similar
> to what we present in the host tab. In most cases this will
> collapse to the short term.
>
> MTU, is good to have in any of the two if we can get it.
>
> More?
I don't think the guest agent ip information should be correlated to
the
vnic engine information at rest api level.
the vm (and vnic) api provides the authoritative configuration
information of the guest as defined in the engine.
I don't think we should 'taint' it with untrusted data from the
guest.
it would make sense to place there IPs configured/allocated by engine
when we deal with ip allocation though.
Agree that there should be a clear distinction between guest data and configuration.
Never the less you need to report the guest data and correlate where you can to the
configuration.
Where and how you present this correlation is a different matter and should be discussed.
i.e., the guest info element in the rest api provides good separation
between engine level data, and guest agent data.
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
6:56 a.m.
On 22/11/12 23:18, Itamar Heim wrote:
On 11/22/2012 08:40 PM, Simon Grinberg wrote:
> Back to the original question:
>
> What is most inconvenient for many users is:
> 1. The name we provide while creating the VNIC differs from the one in
> the guest
> 2. No correlation between IP and NIC
>
> The current page covers for this but indeed as raised here does not
> cover what happens if this information is not easy to retrieve due to
> non strait forward configurations.
>
> What I suggest is,
>
> For the short term:
> - Agent to report the MACs, IPs and interface names if can be found,
> engine to match these to the existing and show
> Name In Engine| Name in guest | MAC | IP etc like the current feature
> page, but...
>
> - If a match could not be found then just report Name in Engine N/A
> and then the rest and keep it in dynamic only table.
> This is useful for NICs created by hooks, advanced topology that we
> can't support ATM etc.
>
> *The above does require the agent to at least match MAC to IP.
>
>
> Long term: The agent to report a topology the same as vdsm does (use
> same code at least for Linux guests?) and present it similar to what
> we present in the host tab. In most cases this will collapse to the
> short term.
>
> MTU, is good to have in any of the two if we can get it.
>
> More?
I don't think the guest agent ip information should be correlated to the
vnic engine information at rest api level.
the vm (and vnic) api provides the authoritative configuration
information of the guest as defined in the engine.
I don't think we should 'taint' it with untrusted data from the guest.
it would make sense to place there IPs configured/allocated by engine
when we deal with ip allocation though.
I was too quick to say we have an agreement...
The comment above seems to give more emphasis on the segregation between
data collected via the GA and data configured via the engine.
In the API we have today the following modeling: per VM entity we hold
GuestInfo entity and there we hold a list of IP addresses.
Are you suggesting to keep this approach and not report anything on the
vNIC level at this point (until we'll be able to configure IP addresses
via the engine)?
Or add GuestInfo element under /api/vms/{vm:id}/nics/{nic:id}/ which
should be additional to the one on the VM level (as we discussed before
the correlation between VNIC and GA reported data is not always possible)
Also what you have in mind for the UI?
i.e., the guest info element in the rest api provides good
separation
between engine level data, and guest agent data.
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
7 a.m.
On 11/25/2012 02:56 PM, Livnat Peer wrote:
On 22/11/12 23:18, Itamar Heim wrote:
> On 11/22/2012 08:40 PM, Simon Grinberg wrote:
>> Back to the original question:
>>
>> What is most inconvenient for many users is:
>> 1. The name we provide while creating the VNIC differs from the one in
>> the guest
>> 2. No correlation between IP and NIC
>>
>> The current page covers for this but indeed as raised here does not
>> cover what happens if this information is not easy to retrieve due to
>> non strait forward configurations.
>>
>> What I suggest is,
>>
>> For the short term:
>> - Agent to report the MACs, IPs and interface names if can be found,
>> engine to match these to the existing and show
>> Name In Engine| Name in guest | MAC | IP etc like the current feature
>> page, but...
>>
>> - If a match could not be found then just report Name in Engine N/A
>> and then the rest and keep it in dynamic only table.
>> This is useful for NICs created by hooks, advanced topology that we
>> can't support ATM etc.
>>
>> *The above does require the agent to at least match MAC to IP.
>>
>>
>> Long term: The agent to report a topology the same as vdsm does (use
>> same code at least for Linux guests?) and present it similar to what
>> we present in the host tab. In most cases this will collapse to the
>> short term.
>>
>> MTU, is good to have in any of the two if we can get it.
>>
>> More?
>
> I don't think the guest agent ip information should be correlated to the
> vnic engine information at rest api level.
> the vm (and vnic) api provides the authoritative configuration
> information of the guest as defined in the engine.
> I don't think we should 'taint' it with untrusted data from the guest.
> it would make sense to place there IPs configured/allocated by engine
> when we deal with ip allocation though.
>
I was too quick to say we have an agreement...
The comment above seems to give more emphasis on the segregation between
data collected via the GA and data configured via the engine.
In the API we have today the following modeling: per VM entity we hold
GuestInfo entity and there we hold a list of IP addresses.
Are you suggesting to keep this approach and not report anything on the
vNIC level at this point (until we'll be able to configure IP addresses
via the engine)?
yes.
Or add GuestInfo element under /api/vms/{vm:id}/nics/{nic:id}/ which
should be additional to the one on the VM level (as we discussed before
the correlation between VNIC and GA reported data is not always possible)
i didn't think about reporting guest info at vnic level, only at vm
level. it could be a valid option, but since some network information
doesn't correlate to vnic's, i think a more natural modeling at vm level
may be easier.
Also what you have in mind for the UI?
at ui level i do think/agree it would make sense to show the ip per vnic
if the correlation between the two is clean and direct (based on mac
address i assume).
you do need to make sure "bad data" won't break the ui though.
> i.e., the guest info element in the rest api provides good separation
> between engine level data, and guest agent data.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
7:21 a.m.
On 25/11/12 15:00, Itamar Heim wrote:
On 11/25/2012 02:56 PM, Livnat Peer wrote:
> On 22/11/12 23:18, Itamar Heim wrote:
>> On 11/22/2012 08:40 PM, Simon Grinberg wrote:
>>> Back to the original question:
>>>
>>> What is most inconvenient for many users is:
>>> 1. The name we provide while creating the VNIC differs from the one in
>>> the guest
>>> 2. No correlation between IP and NIC
>>>
>>> The current page covers for this but indeed as raised here does not
>>> cover what happens if this information is not easy to retrieve due to
>>> non strait forward configurations.
>>>
>>> What I suggest is,
>>>
>>> For the short term:
>>> - Agent to report the MACs, IPs and interface names if can be found,
>>> engine to match these to the existing and show
>>> Name In Engine| Name in guest | MAC | IP etc like the current feature
>>> page, but...
>>>
>>> - If a match could not be found then just report Name in Engine N/A
>>> and then the rest and keep it in dynamic only table.
>>> This is useful for NICs created by hooks, advanced topology that we
>>> can't support ATM etc.
>>>
>>> *The above does require the agent to at least match MAC to IP.
>>>
>>>
>>> Long term: The agent to report a topology the same as vdsm does (use
>>> same code at least for Linux guests?) and present it similar to what
>>> we present in the host tab. In most cases this will collapse to the
>>> short term.
>>>
>>> MTU, is good to have in any of the two if we can get it.
>>>
>>> More?
>>
>> I don't think the guest agent ip information should be correlated to the
>> vnic engine information at rest api level.
>> the vm (and vnic) api provides the authoritative configuration
>> information of the guest as defined in the engine.
>> I don't think we should 'taint' it with untrusted data from the
guest.
>> it would make sense to place there IPs configured/allocated by engine
>> when we deal with ip allocation though.
>>
>
>
> I was too quick to say we have an agreement...
>
> The comment above seems to give more emphasis on the segregation between
> data collected via the GA and data configured via the engine.
>
> In the API we have today the following modeling: per VM entity we hold
> GuestInfo entity and there we hold a list of IP addresses.
>
> Are you suggesting to keep this approach and not report anything on the
> vNIC level at this point (until we'll be able to configure IP addresses
> via the engine)?
yes.
> Or add GuestInfo element under /api/vms/{vm:id}/nics/{nic:id}/ which
> should be additional to the one on the VM level (as we discussed before
> the correlation between VNIC and GA reported data is not always possible)
i didn't think about reporting guest info at vnic level, only at vm
level. it could be a valid option, but since some network information
doesn't correlate to vnic's, i think a more natural modeling at vm level
may be easier.
>
> Also what you have in mind for the UI?
at ui level i do think/agree it would make sense to show the ip per vnic
if the correlation between the two is clean and direct (based on mac
address i assume).
you do need to make sure "bad data" won't break the ui though.
I'm not sure I agree with the differentiation you are doing between UI
and API in this case.
If we think the IP address field per vNIC should display info configured
via the engine and not untrusted data (reported via the guest agent)
then we should keep this approach in the UI as well.
I agree that in some cases the API can model data differently, or enable
more complicated actions, but this is not the case, here we have the
same data modeled differently which can cause confusion with users.
I think that we should keep the separation in the UI as well and add GA
sub-tab in VM and there have a field network devices with the data given
by the GA. no correlation (between engine configured vNICs and GA
report) at this point, when we'll have the ip address configuration via
the engine we'll present per vNIC the address.
>
>
>
>
>> i.e., the guest info element in the rest api provides good separation
>> between engine level data, and guest agent data.
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
7:58 a.m.
On Sun, Nov 25, 2012 at 03:21:28PM +0200, Livnat Peer wrote:
On 25/11/12 15:00, Itamar Heim wrote:
> On 11/25/2012 02:56 PM, Livnat Peer wrote:
>> On 22/11/12 23:18, Itamar Heim wrote:
>>> On 11/22/2012 08:40 PM, Simon Grinberg wrote:
>>>> Back to the original question:
>>>>
>>>> What is most inconvenient for many users is:
>>>> 1. The name we provide while creating the VNIC differs from the one in
>>>> the guest
>>>> 2. No correlation between IP and NIC
>>>>
>>>> The current page covers for this but indeed as raised here does not
>>>> cover what happens if this information is not easy to retrieve due to
>>>> non strait forward configurations.
>>>>
>>>> What I suggest is,
>>>>
>>>> For the short term:
>>>> - Agent to report the MACs, IPs and interface names if can be found,
>>>> engine to match these to the existing and show
>>>> Name In Engine| Name in guest | MAC | IP etc like the current feature
>>>> page, but...
>>>>
>>>> - If a match could not be found then just report Name in Engine N/A
>>>> and then the rest and keep it in dynamic only table.
>>>> This is useful for NICs created by hooks, advanced topology that we
>>>> can't support ATM etc.
>>>>
>>>> *The above does require the agent to at least match MAC to IP.
>>>>
>>>>
>>>> Long term: The agent to report a topology the same as vdsm does (use
>>>> same code at least for Linux guests?) and present it similar to what
>>>> we present in the host tab. In most cases this will collapse to the
>>>> short term.
>>>>
>>>> MTU, is good to have in any of the two if we can get it.
>>>>
>>>> More?
>>>
>>> I don't think the guest agent ip information should be correlated to
the
>>> vnic engine information at rest api level.
>>> the vm (and vnic) api provides the authoritative configuration
>>> information of the guest as defined in the engine.
>>> I don't think we should 'taint' it with untrusted data from the
guest.
>>> it would make sense to place there IPs configured/allocated by engine
>>> when we deal with ip allocation though.
>>>
>>
>>
>> I was too quick to say we have an agreement...
>>
>> The comment above seems to give more emphasis on the segregation between
>> data collected via the GA and data configured via the engine.
>>
>> In the API we have today the following modeling: per VM entity we hold
>> GuestInfo entity and there we hold a list of IP addresses.
>>
>> Are you suggesting to keep this approach and not report anything on the
>> vNIC level at this point (until we'll be able to configure IP addresses
>> via the engine)?
>
> yes.
>
>> Or add GuestInfo element under /api/vms/{vm:id}/nics/{nic:id}/ which
>> should be additional to the one on the VM level (as we discussed before
>> the correlation between VNIC and GA reported data is not always possible)
>
> i didn't think about reporting guest info at vnic level, only at vm
> level. it could be a valid option, but since some network information
> doesn't correlate to vnic's, i think a more natural modeling at vm level
> may be easier.
>
>>
>> Also what you have in mind for the UI?
>
> at ui level i do think/agree it would make sense to show the ip per vnic
> if the correlation between the two is clean and direct (based on mac
> address i assume).
> you do need to make sure "bad data" won't break the ui though.
I'm not sure I agree with the differentiation you are doing between UI
and API in this case.
If we think the IP address field per vNIC should display info configured
via the engine and not untrusted data (reported via the guest agent)
then we should keep this approach in the UI as well.
I agree that in some cases the API can model data differently, or enable
more complicated actions, but this is not the case, here we have the
same data modeled differently which can cause confusion with users.
Yeah, it's a bit unfair to the UI users: it's like saying "we do not
want to get API users confused by an evil guest agent, but we allow this
to happen to those in the UI".
I think that we should keep the separation in the UI as well and add GA
sub-tab in VM and there have a field network devices with the data given
by the GA. no correlation (between engine configured vNICs and GA
report) at this point, when we'll have the ip address configuration via
the engine we'll present per vNIC the address.
Still, the reasonable UI user is less likely to correlate
Engine-configured mac addresses to GA-reported ones. So presenting the
naive correlation between the two has a benefit.
Dan.
10:02 a.m.
On 25/11/12 15:58, Dan Kenigsberg wrote:
On Sun, Nov 25, 2012 at 03:21:28PM +0200, Livnat Peer wrote:
> On 25/11/12 15:00, Itamar Heim wrote:
>> On 11/25/2012 02:56 PM, Livnat Peer wrote:
>>> On 22/11/12 23:18, Itamar Heim wrote:
>>>> On 11/22/2012 08:40 PM, Simon Grinberg wrote:
>>>>> Back to the original question:
>>>>>
>>>>> What is most inconvenient for many users is:
>>>>> 1. The name we provide while creating the VNIC differs from the one
in
>>>>> the guest
>>>>> 2. No correlation between IP and NIC
>>>>>
>>>>> The current page covers for this but indeed as raised here does not
>>>>> cover what happens if this information is not easy to retrieve due
to
>>>>> non strait forward configurations.
>>>>>
>>>>> What I suggest is,
>>>>>
>>>>> For the short term:
>>>>> - Agent to report the MACs, IPs and interface names if can be found,
>>>>> engine to match these to the existing and show
>>>>> Name In Engine| Name in guest | MAC | IP etc like the current
feature
>>>>> page, but...
>>>>>
>>>>> - If a match could not be found then just report Name in Engine N/A
>>>>> and then the rest and keep it in dynamic only table.
>>>>> This is useful for NICs created by hooks, advanced topology that we
>>>>> can't support ATM etc.
>>>>>
>>>>> *The above does require the agent to at least match MAC to IP.
>>>>>
>>>>>
>>>>> Long term: The agent to report a topology the same as vdsm does (use
>>>>> same code at least for Linux guests?) and present it similar to what
>>>>> we present in the host tab. In most cases this will collapse to the
>>>>> short term.
>>>>>
>>>>> MTU, is good to have in any of the two if we can get it.
>>>>>
>>>>> More?
>>>>
>>>> I don't think the guest agent ip information should be correlated to
the
>>>> vnic engine information at rest api level.
>>>> the vm (and vnic) api provides the authoritative configuration
>>>> information of the guest as defined in the engine.
>>>> I don't think we should 'taint' it with untrusted data from
the guest.
>>>> it would make sense to place there IPs configured/allocated by engine
>>>> when we deal with ip allocation though.
>>>>
>>>
>>>
>>> I was too quick to say we have an agreement...
>>>
>>> The comment above seems to give more emphasis on the segregation between
>>> data collected via the GA and data configured via the engine.
>>>
>>> In the API we have today the following modeling: per VM entity we hold
>>> GuestInfo entity and there we hold a list of IP addresses.
>>>
>>> Are you suggesting to keep this approach and not report anything on the
>>> vNIC level at this point (until we'll be able to configure IP addresses
>>> via the engine)?
>>
>> yes.
>>
>>> Or add GuestInfo element under /api/vms/{vm:id}/nics/{nic:id}/ which
>>> should be additional to the one on the VM level (as we discussed before
>>> the correlation between VNIC and GA reported data is not always possible)
>>
>> i didn't think about reporting guest info at vnic level, only at vm
>> level. it could be a valid option, but since some network information
>> doesn't correlate to vnic's, i think a more natural modeling at vm level
>> may be easier.
>>
>>>
>>> Also what you have in mind for the UI?
>>
>> at ui level i do think/agree it would make sense to show the ip per vnic
>> if the correlation between the two is clean and direct (based on mac
>> address i assume).
>> you do need to make sure "bad data" won't break the ui though.
>
> I'm not sure I agree with the differentiation you are doing between UI
> and API in this case.
>
> If we think the IP address field per vNIC should display info configured
> via the engine and not untrusted data (reported via the guest agent)
> then we should keep this approach in the UI as well.
>
> I agree that in some cases the API can model data differently, or enable
> more complicated actions, but this is not the case, here we have the
> same data modeled differently which can cause confusion with users.
Yeah, it's a bit unfair to the UI users: it's like saying "we do not
want to get API users confused by an evil guest agent, but we allow this
to happen to those in the UI".
>
> I think that we should keep the separation in the UI as well and add GA
> sub-tab in VM and there have a field network devices with the data given
> by the GA. no correlation (between engine configured vNICs and GA
> report) at this point, when we'll have the ip address configuration via
> the engine we'll present per vNIC the address.
Still, the reasonable UI user is less likely to correlate
Engine-configured mac addresses to GA-reported ones. So presenting the
naive correlation between the two has a benefit.
I think it can be confusing for users who use both API and UI.
Also if I have to explain that later on the users list I don't see a
good reason or logic behind this that I can use.
I think we should keep it aligned (UI-API).
Dan.
1:27 a.m.
On 22/11/12 20:40, Simon Grinberg wrote:
Back to the original question:
What is most inconvenient for many users is:
1. The name we provide while creating the VNIC differs from the one in the guest
2. No correlation between IP and NIC
The current page covers for this but indeed as raised here does not cover what happens if
this information is not easy to retrieve due to non strait forward configurations.
What I suggest is,
For the short term:
- Agent to report the MACs, IPs and interface names if can be found, engine to match
these to the existing and show
Name In Engine| Name in guest | MAC | IP etc like the current feature page, but...
I think we are all in agreement on the current proposal.
It also seems like you have ideas for enhancing the current proposal so
if you can write a detailed feature page with what you have in mind all
the way from the guest agent report to the REST API modeling we'll be
happy to discuss this as well.
- If a match could not be found then just report Name in Engine N/A
and then the rest and keep it in dynamic only table.
This is useful for NICs created by hooks, advanced topology that we can't support ATM
etc.
*The above does require the agent to at least match MAC to IP.
Long term: The agent to report a topology the same as vdsm does (use same code at least
for Linux guests?) and present it similar to what we present in the host tab. In most
cases this will collapse to the short term.
MTU, is good to have in any of the two if we can get it.
More?
----- Original Message -----
> From: "Moti Asayag" <masayag(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 22, 2012 5:39:53 PM
> Subject: Re: [Engine-devel] Report vNic Implementation Details
>
> On 11/22/2012 05:36 PM, Yaniv Kaul wrote:
>> On 11/21/2012 10:53 PM, Andrew Cathrow wrote:
>>>
>>> ----- Original Message -----
>>>> From: "Moti Asayag" <masayag(a)redhat.com>
>>>> To: engine-devel(a)ovirt.org
>>>> Sent: Wednesday, November 21, 2012 12:36:58 PM
>>>> Subject: [Engine-devel] Report vNic Implementation Details
>>>>
>>>> Hi all,
>>>>
>>>> This is a proposal for reporting the vNic implementation details
>>>> as
>>>> reported by the guest agent per each vNic.
>>>>
>>>> Please review the wiki and add your comments.
>>>
>>> While we're making the change is there anything else we'd want to
>>> report - MTU, MAC (since a user might try to override), etc ?
>>
>> Do we support change of MAC from within the VM? Is it even working?
>> Y.
>>
>
> Shouldn't work if the nwfilter rules are enabled (which are by
> default)
>
>>
>>>
>>>
>>>
>>>> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
>>>>
>>>> Thanks,
>>>> Moti
>>>> _______________________________________________
>>>> 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
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
3:16 p.m.
On 11/22/2012 05:39 PM, Moti Asayag wrote:
On 11/22/2012 05:36 PM, Yaniv Kaul wrote:
> On 11/21/2012 10:53 PM, Andrew Cathrow wrote:
>>
>> ----- Original Message -----
>>> From: "Moti Asayag" <masayag(a)redhat.com>
>>> To: engine-devel(a)ovirt.org
>>> Sent: Wednesday, November 21, 2012 12:36:58 PM
>>> Subject: [Engine-devel] Report vNic Implementation Details
>>>
>>> Hi all,
>>>
>>> This is a proposal for reporting the vNic implementation details as
>>> reported by the guest agent per each vNic.
>>>
>>> Please review the wiki and add your comments.
>>
>> While we're making the change is there anything else we'd want to
>> report - MTU, MAC (since a user might try to override), etc ?
>
> Do we support change of MAC from within the VM? Is it even working?
> Y.
>
Shouldn't work if the nwfilter rules are enabled (which are by default)
true, but not relevant in this discussion, as changing mac means no
external traffic.
doesn't mean it is not what the guest reports via the guest agent.
so guest can report ip per mac from guest agent regardless of vnic mac
address.
4164
days inactive
4168
days old
25 comments
9 participants
participants (9)
-
Andrew Cathrow -
Dan Kenigsberg -
Itamar Heim -
Livnat Peer -
Michael Pasternak -
Moti Asayag -
Simon Grinberg -
Vinzenz Feenstra -
Yaniv Kaul