[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. http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation Thanks, Moti
----- Original Message -----
From: "Moti Asayag" <masayag@redhat.com> To: engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 11/21/2012 10:53 PM, Andrew Cathrow wrote:
----- Original Message -----
From: "Moti Asayag" <masayag@redhat.com> To: engine-devel@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?
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@redhat.com> To: engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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@redhat.com> To: engine-devel@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.
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@redhat.com> To: engine-devel@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.
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Dan Kenigsberg" <danken@redhat.com> Cc: "Itamar Heim" <iheim@redhat.com>, "Simon Grinberg" <simon@redhat.com>, engine-devel@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@redhat.com> To: engine-devel@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.
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@redhat.com> To: engine-devel@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.
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@redhat.com> > To: engine-devel@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.
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@redhat.com> To: engine-devel@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
On 21/11/12 22:53, Andrew Cathrow wrote:
----- Original Message -----
From: "Moti Asayag" <masayag@redhat.com> To: engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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@redhat.com> To: engine-devel@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.
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@redhat.com> To: engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@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
On 11/21/2012 10:53 PM, Andrew Cathrow wrote:
----- Original Message -----
From: "Moti Asayag" <masayag@redhat.com> To: engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Yaniv Kaul" <ykaul@redhat.com> To: "Andrew Cathrow" <acathrow@redhat.com> Cc: "Moti Asayag" <masayag@redhat.com>, "Simon Grinberg" <simon@redhat.com>, engine-devel@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@redhat.com> To: engine-devel@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.
http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
Thanks, Moti _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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@redhat.com> To: engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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@redhat.com> To: "Yaniv Kaul" <ykaul@redhat.com> Cc: "Simon Grinberg" <simon@redhat.com>, engine-devel@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@redhat.com> To: engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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.
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Simon Grinberg" <simon@redhat.com> Cc: engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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.
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.
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@redhat.com> To: "Yaniv Kaul" <ykaul@redhat.com> Cc: "Simon Grinberg" <simon@redhat.com>, engine-devel@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@redhat.com> To: engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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@redhat.com> To: engine-devel@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.
participants (9)
-
Andrew Cathrow -
Dan Kenigsberg -
Itamar Heim -
Livnat Peer -
Michael Pasternak -
Moti Asayag -
Simon Grinberg -
Vinzenz Feenstra -
Yaniv Kaul