[Engine-devel] VNIC profiles
Hi, We are working on adding VNIC profiles as part of the work to add VNIC QoS. http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles We need to define some of the system behavior followed by this change, here is my take - Editing a profile - -------------------- A user should be able to edit the profile properties (including profile name) while VMs are attached and are using this Profile (reference should be done by id). Changing the network though is a bit more tricky as long as we don't have a way to distinguish between running and current configurations I think it could be very confusing to the user. Especially since we support dynamic wiring so the behavior IMO is unpredictable. I think it should be blocked at this point. Edit a VNIC / change a VNIC profile - ------------------------------------ Changing the profile a VM is using while the VM is running should behave like dynamic wiring (changing the VM network while it is running). Remove a Profile - ------------------- Is only valid if all VMs that are using this profile are in status down. It should update all VMs to point to no profile which should behave like none network today. I see no reason to support a profile on a none network at this point. The above is also relevant for upgrade flow (upgrading none network to point to no profile) Removing a Network - ---------------------- should remove all profiles on that network VM snapshot/import/export - -------------------------- We should handle VMs that are pointing to a network directly for b/w compatibility. we need to select first profile that is on that network that the user has permissions on. I assume there are more, comments are welcome Thanks, Livnat
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "engine-devel" <engine-devel@ovirt.org>, "Ofri Masad" <omasad@redhat.com> Sent: Sunday, June 30, 2013 3:59:37 PM Subject: [Engine-devel] VNIC profiles
Hi,
We are working on adding VNIC profiles as part of the work to add VNIC QoS.
http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles
We need to define some of the system behavior followed by this change, here is my take -
Editing a profile - -------------------- A user should be able to edit the profile properties (including profile name) while VMs are attached and are using this Profile (reference should be done by id).
Changing the network though is a bit more tricky as long as we don't have a way to distinguish between running and current configurations I think it could be very confusing to the user. Especially since we support dynamic wiring so the behavior IMO is unpredictable. I think it should be blocked at this point.
Edit a VNIC / change a VNIC profile - ------------------------------------ Changing the profile a VM is using while the VM is running should behave like dynamic wiring (changing the VM network while it is running).
Remove a Profile - ------------------- Is only valid if all VMs that are using this profile are in status down.
What about HA VMs , are they forced to be down as well for this operation?
It should update all VMs to point to no profile which should behave like none network today.
I see no reason to support a profile on a none network at this point.
The above is also relevant for upgrade flow (upgrading none network to point to no profile)
Removing a Network - ---------------------- should remove all profiles on that network
VM snapshot/import/export - -------------------------- We should handle VMs that are pointing to a network directly for b/w compatibility. we need to select first profile that is on that network that the user has permissions on.
I assume there are more, comments are welcome
Thanks, Livnat
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 07/01/2013 12:19 AM, Eli Mesika wrote:
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "engine-devel" <engine-devel@ovirt.org>, "Ofri Masad" <omasad@redhat.com> Sent: Sunday, June 30, 2013 3:59:37 PM Subject: [Engine-devel] VNIC profiles
Hi,
We are working on adding VNIC profiles as part of the work to add VNIC QoS.
http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles
We need to define some of the system behavior followed by this change, here is my take -
Editing a profile - -------------------- A user should be able to edit the profile properties (including profile name) while VMs are attached and are using this Profile (reference should be done by id).
Changing the network though is a bit more tricky as long as we don't have a way to distinguish between running and current configurations I think it could be very confusing to the user. Especially since we support dynamic wiring so the behavior IMO is unpredictable. I think it should be blocked at this point.
Edit a VNIC / change a VNIC profile - ------------------------------------ Changing the profile a VM is using while the VM is running should behave like dynamic wiring (changing the VM network while it is running).
Remove a Profile - ------------------- Is only valid if all VMs that are using this profile are in status down.
What about HA VMs , are they forced to be down as well for this operation?
If you want to remove the profile you can remove it from the HA VM (hot unplug NIC for example) and then delete the profile. You can do that when the VM is up and running.
It should update all VMs to point to no profile which should behave like none network today.
I see no reason to support a profile on a none network at this point.
The above is also relevant for upgrade flow (upgrading none network to point to no profile)
Removing a Network - ---------------------- should remove all profiles on that network
VM snapshot/import/export - -------------------------- We should handle VMs that are pointing to a network directly for b/w compatibility. we need to select first profile that is on that network that the user has permissions on.
I assume there are more, comments are welcome
Thanks, Livnat
_______________________________________________ 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
Hi Livnat, My name is Malini Rao and I am the lead interaction designer dedicated to RHEV/Ovirt UX from Red Hat and we have another interaction designer Eldan Hildeshiem who is also focused on RHEV UX. I went over your feature page and in general, the GUI proposals look great. I do have some quick feedback comments - Will there be any predefined profiles available to the users out of the box in RHEV? Or will they have to define their own? I am wondering if there are any common standard QoS levels that can be predefined and the users can get a heeadstart and use or tweak instead of defining from scratch. VNIC level QoS dialog 1. Will the Outbound and inbound values come with some defaults? Or will they be empty? Is there a need for any spinners or drop downs for frequently used values or is it ok to just have fields to type in the numeric values? Also I am assuming there is some kind of validation to ensure only numbers an be entered in these fields. 2. For custom properties, why do we have a drop down? Can custom properties defined elsewhere be accessed here and applied? If not, then I am assuming this will have to be a text field. Correct? Also, I am guessing if there is only one custom property field, the [-] icon will be disabled. Edit Network Interface Dialog 1. It will be awesome if under the Profile Field value, you can present a short summary of the profile in gray text. alternately, there can be a little info icon which will present this info on hover. This will help people who pick Gold know what that means vs silver or any other profile. Besides these specific feedback, I am wondering if any of the VM dialogs are affected by this? Will a VNIC profile field now show up on those dialogs as well? I see you have identified a bunch of open issues to work out and we will be more than happy to help you with the GUI for these flows as needed. Please feel free to reach out to Eldan and me and we can post back to the group with our work. Thanks Malini ----- Original Message ----- From: "Livnat Peer" <lpeer@redhat.com> To: "engine-devel" <engine-devel@ovirt.org>, "Ofri Masad" <omasad@redhat.com> Sent: Sunday, June 30, 2013 8:59:37 AM Subject: [Engine-devel] VNIC profiles Hi, We are working on adding VNIC profiles as part of the work to add VNIC QoS. http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles We need to define some of the system behavior followed by this change, here is my take - Editing a profile - -------------------- A user should be able to edit the profile properties (including profile name) while VMs are attached and are using this Profile (reference should be done by id). Changing the network though is a bit more tricky as long as we don't have a way to distinguish between running and current configurations I think it could be very confusing to the user. Especially since we support dynamic wiring so the behavior IMO is unpredictable. I think it should be blocked at this point. Edit a VNIC / change a VNIC profile - ------------------------------------ Changing the profile a VM is using while the VM is running should behave like dynamic wiring (changing the VM network while it is running). Remove a Profile - ------------------- Is only valid if all VMs that are using this profile are in status down. It should update all VMs to point to no profile which should behave like none network today. I see no reason to support a profile on a none network at this point. The above is also relevant for upgrade flow (upgrading none network to point to no profile) Removing a Network - ---------------------- should remove all profiles on that network VM snapshot/import/export - -------------------------- We should handle VMs that are pointing to a network directly for b/w compatibility. we need to select first profile that is on that network that the user has permissions on. I assume there are more, comments are welcome Thanks, Livnat _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 07/01/2013 09:22 PM, Malini Rao wrote:
Hi Livnat,
My name is Malini Rao and I am the lead interaction designer dedicated to RHEV/Ovirt UX from Red Hat and we have another interaction designer Eldan Hildeshiem who is also focused on RHEV UX.
Hi Malini - nice to e-meet you :)
I went over your feature page and in general, the GUI proposals look great. I do have some quick feedback comments -
Just a small credit correction - the feature page is Ofri's feature page, I added some feedback of my own :)
Will there be any predefined profiles available to the users out of the box in RHEV? Or will they have to define their own?
If you start with a clean install setup there are no predefined vNICs profiles. Profiles can be generated in two flows, a user can explicitly generate a profile or when admin network creates a new network he can mark create a profile for this network** in a single action. A VNIC profile is the link between the abstract network entity and the VM which consumes this network. If you upgrade existing setup, in the upgrade process profiles will be created per network and will be attached to the VNICs that are currently using the network. **This is not accurate, the user would be able to check all relevant VNIC-QoS-entities and for each one we need to create a profile.
I am wondering if there are any common standard QoS levels that can be predefined and the users can get a heeadstart and use or tweak instead of defining from scratch.
That's a very good point. The wiki page is not fully up to date, I think. Ofri wanted to add an entity of VNIC QoS which would be linked from within the VNIC profile. The VNIC QoS entity is located in the entities hierarchy under Data Center. The point you made, I think, is will we have predefined VNIC QoS entities. The Qos entity is tight to the hardware you have in your DC. If you have 10G or 1G Ethernet links the QoS entities would look very different, so I'm not sure what predefined values would look like.
VNIC level QoS dialog
1. Will the Outbound and inbound values come with some defaults? Or will they be empty? Is there a need for any spinners or drop downs for frequently used values or is it ok to just have fields to type in the numeric values? Also I am assuming there is some kind of validation to ensure only numbers an be entered in these fields.
2. For custom properties, why do we have a drop down? Can custom properties defined elsewhere be accessed here and applied? If not, then I am assuming this will have to be a text field. Correct? Also, I am guessing if there is only one custom property field, the [-] icon will be disabled.
Edit Network Interface Dialog 1. It will be awesome if under the Profile Field value, you can present a short summary of the profile in gray text. alternately, there can be a little info icon which will present this info on hover. This will help people who pick Gold know what that means vs silver or any other profile.
Besides these specific feedback, I am wondering if any of the VM dialogs are affected by this? Will a VNIC profile field now show up on those dialogs as well?
I see you have identified a bunch of open issues to work out and we will be more than happy to help you with the GUI for these flows as needed. Please feel free to reach out to Eldan and me and we can post back to the group with our work.
Thank you Malini for the above feedback, I think these are good questions. Ofri - can you comment on the above ? Livnat
Thanks Malini
----- Original Message ----- From: "Livnat Peer" <lpeer@redhat.com> To: "engine-devel" <engine-devel@ovirt.org>, "Ofri Masad" <omasad@redhat.com> Sent: Sunday, June 30, 2013 8:59:37 AM Subject: [Engine-devel] VNIC profiles
Hi,
We are working on adding VNIC profiles as part of the work to add VNIC QoS.
http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles
We need to define some of the system behavior followed by this change, here is my take -
Editing a profile - -------------------- A user should be able to edit the profile properties (including profile name) while VMs are attached and are using this Profile (reference should be done by id).
Changing the network though is a bit more tricky as long as we don't have a way to distinguish between running and current configurations I think it could be very confusing to the user. Especially since we support dynamic wiring so the behavior IMO is unpredictable. I think it should be blocked at this point.
Edit a VNIC / change a VNIC profile - ------------------------------------ Changing the profile a VM is using while the VM is running should behave like dynamic wiring (changing the VM network while it is running).
Remove a Profile - ------------------- Is only valid if all VMs that are using this profile are in status down. It should update all VMs to point to no profile which should behave like none network today.
I see no reason to support a profile on a none network at this point.
The above is also relevant for upgrade flow (upgrading none network to point to no profile)
Removing a Network - ---------------------- should remove all profiles on that network
VM snapshot/import/export - -------------------------- We should handle VMs that are pointing to a network directly for b/w compatibility. we need to select first profile that is on that network that the user has permissions on.
I assume there are more, comments are welcome
Thanks, Livnat
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Malini Rao" <mrao@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Ofri Masad" <omasad@redhat.com>, "Eldan Hildesheim" <ehildesh@redhat.com> Sent: Tuesday, July 2, 2013 2:00:03 AM Subject: Re: [Engine-devel] VNIC profiles
On 07/01/2013 09:22 PM, Malini Rao wrote:
Hi Livnat,
My name is Malini Rao and I am the lead interaction designer dedicated to RHEV/Ovirt UX from Red Hat and we have another interaction designer Eldan Hildeshiem who is also focused on RHEV UX.
Hi Malini - nice to e-meet you :)
I went over your feature page and in general, the GUI proposals look great. I do have some quick feedback comments -
Just a small credit correction - the feature page is Ofri's feature page, I added some feedback of my own :)
Sorry about that! Ofri, I look forward to collaborating with you and I hope we can contribute to this feature from the UX/ usability perspective.
Will there be any predefined profiles available to the users out of the box in RHEV? Or will they have to define their own?
If you start with a clean install setup there are no predefined vNICs profiles.
Profiles can be generated in two flows, a user can explicitly generate a profile or when admin network creates a new network he can mark create a profile for this network** in a single action. A VNIC profile is the link between the abstract network entity and the VM which consumes this network.
If you upgrade existing setup, in the upgrade process profiles will be created per network and will be attached to the VNICs that are currently using the network.
So you are saying any VNIC profiles created and the associations with VMS that already exist will be preserved during Upgrades... correct? But none of these need to be pre-defined ( as in something that was available to the user automatically and not via user action)... correct?
**This is not accurate, the user would be able to check all relevant VNIC-QoS-entities and for each one we need to create a profile.
So there are two concepts here - VNIC-QoS-entities and VNIC Profiles?
I am wondering if there are any common standard QoS levels that can be predefined and the users can get a heeadstart and use or tweak instead of defining from scratch.
That's a very good point. The wiki page is not fully up to date, I think. Ofri wanted to add an entity of VNIC QoS which would be linked from within the VNIC profile.
The VNIC QoS entity is located in the entities hierarchy under Data Center.
The point you made, I think, is will we have predefined VNIC QoS entities.
The Qos entity is tight to the hardware you have in your DC. If you have 10G or 1G Ethernet links the QoS entities would look very different, so I'm not sure what predefined values would look like.
So are you saying that we can have pre-defined VNIC Qos Entities like Gold, silver etc. but not VNIC profiles because what is gold for a 10G Ehternet is different from gold for a 1G Ethernet? But even if they are different, can the VNIC profiles not also be auto generated based on the Hardware and the VNIC Qos Entities?
VNIC level QoS dialog
1. Will the Outbound and inbound values come with some defaults? Or will they be empty? Is there a need for any spinners or drop downs for frequently used values or is it ok to just have fields to type in the numeric values? Also I am assuming there is some kind of validation to ensure only numbers an be entered in these fields.
2. For custom properties, why do we have a drop down? Can custom properties defined elsewhere be accessed here and applied? If not, then I am assuming this will have to be a text field. Correct? Also, I am guessing if there is only one custom property field, the [-] icon will be disabled.
Edit Network Interface Dialog 1. It will be awesome if under the Profile Field value, you can present a short summary of the profile in gray text. alternately, there can be a little info icon which will present this info on hover. This will help people who pick Gold know what that means vs silver or any other profile.
Besides these specific feedback, I am wondering if any of the VM dialogs are affected by this? Will a VNIC profile field now show up on those dialogs as well?
I see you have identified a bunch of open issues to work out and we will be more than happy to help you with the GUI for these flows as needed. Please feel free to reach out to Eldan and me and we can post back to the group with our work.
Thank you Malini for the above feedback, I think these are good questions.
Ofri - can you comment on the above ?
Looking forward to some of the answers to the questions above.
Livnat
Thanks Malini
----- Original Message ----- From: "Livnat Peer" <lpeer@redhat.com> To: "engine-devel" <engine-devel@ovirt.org>, "Ofri Masad" <omasad@redhat.com> Sent: Sunday, June 30, 2013 8:59:37 AM Subject: [Engine-devel] VNIC profiles
Hi,
We are working on adding VNIC profiles as part of the work to add VNIC QoS.
http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles
We need to define some of the system behavior followed by this change, here is my take -
Editing a profile - -------------------- A user should be able to edit the profile properties (including profile name) while VMs are attached and are using this Profile (reference should be done by id).
Changing the network though is a bit more tricky as long as we don't have a way to distinguish between running and current configurations I think it could be very confusing to the user. Especially since we support dynamic wiring so the behavior IMO is unpredictable. I think it should be blocked at this point.
Edit a VNIC / change a VNIC profile - ------------------------------------ Changing the profile a VM is using while the VM is running should behave like dynamic wiring (changing the VM network while it is running).
Remove a Profile - ------------------- Is only valid if all VMs that are using this profile are in status down. It should update all VMs to point to no profile which should behave like none network today.
I see no reason to support a profile on a none network at this point.
The above is also relevant for upgrade flow (upgrading none network to point to no profile)
Removing a Network - ---------------------- should remove all profiles on that network
VM snapshot/import/export - -------------------------- We should handle VMs that are pointing to a network directly for b/w compatibility. we need to select first profile that is on that network that the user has permissions on.
I assume there are more, comments are welcome
Thanks, Livnat
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 07/03/2013 07:42 PM, Malini Rao wrote:
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Malini Rao" <mrao@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Ofri Masad" <omasad@redhat.com>, "Eldan Hildesheim" <ehildesh@redhat.com> Sent: Tuesday, July 2, 2013 2:00:03 AM Subject: Re: [Engine-devel] VNIC profiles
On 07/01/2013 09:22 PM, Malini Rao wrote:
Hi Livnat,
My name is Malini Rao and I am the lead interaction designer dedicated to RHEV/Ovirt UX from Red Hat and we have another interaction designer Eldan Hildeshiem who is also focused on RHEV UX.
Hi Malini - nice to e-meet you :)
I went over your feature page and in general, the GUI proposals look great. I do have some quick feedback comments -
Just a small credit correction - the feature page is Ofri's feature page, I added some feedback of my own :)
Sorry about that! Ofri, I look forward to collaborating with you and I hope we can contribute to this feature from the UX/ usability perspective.
Will there be any predefined profiles available to the users out of the box in RHEV? Or will they have to define their own?
If you start with a clean install setup there are no predefined vNICs profiles.
Profiles can be generated in two flows, a user can explicitly generate a profile or when admin network creates a new network he can mark create a profile for this network** in a single action. A VNIC profile is the link between the abstract network entity and the VM which consumes this network.
If you upgrade existing setup, in the upgrade process profiles will be created per network and will be attached to the VNICs that are currently using the network.
So you are saying any VNIC profiles created and the associations with VMS that already exist will be preserved during Upgrades... correct? But none of these need to be pre-defined ( as in something that was available to the user automatically and not via user action)... correct?
correct x2
**This is not accurate, the user would be able to check all relevant VNIC-QoS-entities and for each one we need to create a profile.
So there are two concepts here - VNIC-QoS-entities and VNIC Profiles?
correct again :)
I am wondering if there are any common standard QoS levels that can be predefined and the users can get a heeadstart and use or tweak instead of defining from scratch.
That's a very good point. The wiki page is not fully up to date, I think. Ofri wanted to add an entity of VNIC QoS which would be linked from within the VNIC profile.
The VNIC QoS entity is located in the entities hierarchy under Data Center.
The point you made, I think, is will we have predefined VNIC QoS entities.
The Qos entity is tight to the hardware you have in your DC. If you have 10G or 1G Ethernet links the QoS entities would look very different, so I'm not sure what predefined values would look like.
So are you saying that we can have pre-defined VNIC Qos Entities like Gold, silver etc.
I am saying it is something that Ofri should consider, although I personally don't think there is an added value in having a pre-defined VNIC Qos.
but not VNIC profiles because what is gold for a 10G Ehternet is different from gold for a 1G Ethernet?
VNIC profile is associated with a specific Network, so technically we can't have pre-defined profiles as we don't have predefined Networks. Well, we do have the management network (which is predefined) and for that we do need to create a predefined profile - Thanks. This point out another behavior we should document, when removing the VM-network role from a network we need to remove the profiles associated with that network. (Moti, can you capture this in the VNIC profile wiki as well)
But even if they are different, can the VNIC profiles not also be auto generated based on the Hardware and the VNIC Qos Entities?
I lost you here, can you please elaborate.
VNIC level QoS dialog
1. Will the Outbound and inbound values come with some defaults? Or will they be empty? Is there a need for any spinners or drop downs for frequently used values or is it ok to just have fields to type in the numeric values? Also I am assuming there is some kind of validation to ensure only numbers an be entered in these fields.
2. For custom properties, why do we have a drop down? Can custom properties defined elsewhere be accessed here and applied? If not, then I am assuming this will have to be a text field. Correct? Also, I am guessing if there is only one custom property field, the [-] icon will be disabled.
Edit Network Interface Dialog 1. It will be awesome if under the Profile Field value, you can present a short summary of the profile in gray text. alternately, there can be a little info icon which will present this info on hover. This will help people who pick Gold know what that means vs silver or any other profile.
Besides these specific feedback, I am wondering if any of the VM dialogs are affected by this? Will a VNIC profile field now show up on those dialogs as well?
I see you have identified a bunch of open issues to work out and we will be more than happy to help you with the GUI for these flows as needed. Please feel free to reach out to Eldan and me and we can post back to the group with our work.
Thank you Malini for the above feedback, I think these are good questions.
Ofri - can you comment on the above ?
Looking forward to some of the answers to the questions above.
Livnat
Thanks Malini
----- Original Message ----- From: "Livnat Peer" <lpeer@redhat.com> To: "engine-devel" <engine-devel@ovirt.org>, "Ofri Masad" <omasad@redhat.com> Sent: Sunday, June 30, 2013 8:59:37 AM Subject: [Engine-devel] VNIC profiles
Hi,
We are working on adding VNIC profiles as part of the work to add VNIC QoS.
http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles
We need to define some of the system behavior followed by this change, here is my take -
Editing a profile - -------------------- A user should be able to edit the profile properties (including profile name) while VMs are attached and are using this Profile (reference should be done by id).
Changing the network though is a bit more tricky as long as we don't have a way to distinguish between running and current configurations I think it could be very confusing to the user. Especially since we support dynamic wiring so the behavior IMO is unpredictable. I think it should be blocked at this point.
Edit a VNIC / change a VNIC profile - ------------------------------------ Changing the profile a VM is using while the VM is running should behave like dynamic wiring (changing the VM network while it is running).
Remove a Profile - ------------------- Is only valid if all VMs that are using this profile are in status down. It should update all VMs to point to no profile which should behave like none network today.
I see no reason to support a profile on a none network at this point.
The above is also relevant for upgrade flow (upgrading none network to point to no profile)
Removing a Network - ---------------------- should remove all profiles on that network
VM snapshot/import/export - -------------------------- We should handle VMs that are pointing to a network directly for b/w compatibility. we need to select first profile that is on that network that the user has permissions on.
I assume there are more, comments are welcome
Thanks, Livnat
_______________________________________________ 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
Hi, I've updated the wiki with the feedbacks from this thread, added a backend section naming the affected commands and also add added few questions of my own embedded in the pastedtext below. In addition, another question here: The units within the UI mockups are Mb and Mbps. The libvirt APIs expects the units to be in kb and kbps. Which component is responsible to convert them to the expect units ? engine or VDSM ? Copied text from the wiki: Adding a Profile The network administrator could create several VNIC Profiles for each network. He could then grant a users with the permission to use (consume) each profile. The user will only be able to use profiles which he was granted access to. For example: the network admin will create two VNIC profiles for network "blue": Profile "Gold" - with better QoS and with port mirroring Profile "Silver" with lower QoS and without port mirroring. He will then define the user-group "students" as user of profile "Silver" and user-group "teachers" as user of profile "Gold". In this case the teachers will enjoy better quality of service then the students. When a teacher will add/edit a virtual NIC he could select profile "Gold" for that NIC - the VNIC will be connected to network "blue" with high QoS and with port mirroring. Question: In the same matter we allowed via the UI to grant 'NetworkUser' to 'everyone' user, wouldn't it ease the use of Profiles if we support it in this context as well? Editing a Profile A user should be able to edit the profile properties (including profile name) while VMs are attached and are using this Profile (reference should be done by id). Changing the network of a vNic profile will be allowed only if no VMs are using the profile. Since we have no way to distinguish between running and current configurations, the expected behavior of such a change is unpredictable and less intuitive to the user (especially since dynamic wiring is supported). The changes will seep down to all VNICs using the profile. In case VNIC using the edited profile are connected to running VMs, the change will apply only on the VM next run. Question: What about Hibernate/Suspend VM ? will the resume VM action uses the original configuration for the vnics when the VM was started ? Deleting a Profile VNIC Profiles could not be deleted from the engine as long as one or more VM/Templates are using those profiles. Reporting vNic actual configuration The engine will retrieve the actual configuration of the profile properties on the VNIC from VDSM (using the network statistics mechanism) and the networked administrator will be presented with the state of each VNIC (synched/unsynched). Editing a VNIC / Changing a VNIC profile Changing the profile a VM is using while the VM is running should behave like dynamic wiring (changing the VM network while it is running). Hot-plug of a vnic will will use will use the updated profile connected to the VNIC. Adding a Network When adding a network, a user can provide an option to create a vNic Profile for it. Question: Is it s default profile ? what are its properties ? Question: What about 'Public Use' option ? Are they still relevant in the context of adding new networks or we should eliminate them and move it only to 'Add vNic Profile' dialog? Updating a Network When a network role is modified to be a 'non-VM network', all vNic profiles associated with it should be deleted. Removing a Network Should remove all profiles on that network Adding an Empty Data-Center Currently, When creating a new Data-Center, the management network is automatically created. From 3.3, a default vNic profile will be created for the management network. VM snapshot/import/export We should handle VMs that are pointing to a network directly for backward compatibility. We need to select first profile that is on that network that the user has permissions on. Question: Do we wish to support it export from 3.3 and import to 3.2 or below? Question: A user can import/export a VM/Template even if he doesn't have permissions on the networks. Is the next flow valid ? The profile name should be saved in the OVF (in addition to the network name which is saved today). During import, if both (network name, profile name) exist on the target DC, the vnic will get the profile id. If the network exists in the Data-Center, but has no profile as specified in the OVF, the user will be notified (event log) and the VNIC will be connected to a default minimal profile defined in the system, regardless the permissions the user has on the network. If failed to find any matching vNic profile, the vnic's profile will be set with 'none'. When a Template is created from a VM the VNIC Profile will be kept along with the VNIC. When a VM is created from template the VNIC Profiles will be taken from the template's VNICs. ----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "engine-devel" <engine-devel@ovirt.org>, "Ofri Masad" <omasad@redhat.com> Cc: "Mike Kolesnik" <mkolesni@redhat.com>, "Moti Asayag" <masayag@redhat.com>, "Oved Ourfalli" <oourfali@redhat.com> Sent: Sunday, June 30, 2013 3:59:37 PM Subject: VNIC profiles
Hi,
We are working on adding VNIC profiles as part of the work to add VNIC QoS.
http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles
We need to define some of the system behavior followed by this change, here is my take -
Editing a profile - -------------------- A user should be able to edit the profile properties (including profile name) while VMs are attached and are using this Profile (reference should be done by id).
Changing the network though is a bit more tricky as long as we don't have a way to distinguish between running and current configurations I think it could be very confusing to the user. Especially since we support dynamic wiring so the behavior IMO is unpredictable. I think it should be blocked at this point.
Edit a VNIC / change a VNIC profile - ------------------------------------ Changing the profile a VM is using while the VM is running should behave like dynamic wiring (changing the VM network while it is running).
Remove a Profile - ------------------- Is only valid if all VMs that are using this profile are in status down. It should update all VMs to point to no profile which should behave like none network today.
I see no reason to support a profile on a none network at this point.
The above is also relevant for upgrade flow (upgrading none network to point to no profile)
Removing a Network - ---------------------- should remove all profiles on that network
VM snapshot/import/export - -------------------------- We should handle VMs that are pointing to a network directly for b/w compatibility. we need to select first profile that is on that network that the user has permissions on.
I assume there are more, comments are welcome
Thanks, Livnat
On 07/07/2013 01:59 PM, Moti Asayag wrote:
Hi,
I've updated the wiki with the feedbacks from this thread, added a backend section naming the affected commands and also add added few questions of my own embedded in the pastedtext below.
Hi Moti, A good and comprehensive description of the feature behavior. See my comments bellow -
In addition, another question here:
The units within the UI mockups are Mb and Mbps. The libvirt APIs expects the units to be in kb and kbps. Which component is responsible to convert them to the expect units ? engine or VDSM ?
Giuseppe mentioned that in a previous thread on this subject. Ofri and Giuseppe agreed that the translation would be done on the engine level.
Copied text from the wiki:
Adding a Profile
The network administrator could create several VNIC Profiles for each network. He could then grant a users with the permission to use (consume) each profile. The user will only be able to use profiles which he was granted access to.
For example: the network admin will create two VNIC profiles for network "blue":
Profile "Gold" - with better QoS and with port mirroring Profile "Silver" with lower QoS and without port mirroring.
I would use other names for the profiles to avoid confusion. Gold and Silver are likely to be QoS object names, a more typical name for a network profile is - teachers-blue and students-blue The different profiles can have different QoS (teachers-blue would get Gold QoS while Students-blue will have Silver).
He will then define the user-group "students" as user of profile "Silver" and user-group "teachers" as user of profile "Gold". In this case the teachers will enjoy better quality of service then the students. When a teacher will add/edit a virtual NIC he could select profile "Gold" for that NIC - the VNIC will be connected to network "blue" with high QoS and with port mirroring.
Question: In the same matter we allowed via the UI to grant 'NetworkUser' to 'everyone' user, wouldn't it ease the use of Profiles if we support it in this context as well?
The ease of use could be that when creating a network we'll display in the UI all VNIC-QoS-objects and the users could tick next to the QoS they are interested in, for each QoS that was chosen a profile would be created. I would enhance that with youe suggestion above and display next to the QoS that was checked the option to mark 'Allow All users' like we have today for making a network public, this option would give permission to everyone on that profile.
Editing a Profile
A user should be able to edit the profile properties (including profile name) while VMs are attached and are using this Profile (reference should be done by id). Changing the network of a vNic profile will be allowed only if no VMs are using the profile.
It would be better if we can limit this to no running VM is using the profile (or more simple to implement if all VMs that are using this profile are in status down).
Since we have no way to distinguish between running and current configurations, the expected behavior of such a change is unpredictable and less intuitive to the user (especially since dynamic wiring is supported). The changes will seep down to all VNICs using the profile. In case VNIC using the edited profile are connected to running VMs, the change will apply only on the VM next run.
Question: What about Hibernate/Suspend VM ? will the resume VM action uses the original configuration for the vnics when the VM was started ?
Currently profile includes: network, port-mirroring, custom property, QoS Changing any of the above (except for network) requires a VM reboot, so I think that we can start with the following statement - the profile change would only apply after next VM reboot. There are 2 problems with the above: - Today we support network wiring, with VNIC profiles we are asking the users to create a new profile and attach the VMs to the new profile, I can see the RFE coming - we can report that ourselves ;) - We don't reflect with which configuration the VM is running, e.g we edited the profile QoS but I'm not sure with which QoS the VM is currently running. (The RFE for differentiating between current configuration and running configuration was already asked for by numerous users) The above is a general issue that we need to solve and I would not limit editing VNIC profiles because of it. We can mitigate this specifically for QoS like described bellow.
Deleting a Profile
VNIC Profiles could not be deleted from the engine as long as one or more VM/Templates are using those profiles.
Reporting vNic actual configuration
The engine will retrieve the actual configuration of the profile properties on the VNIC from VDSM (using the network statistics mechanism) and the networked administrator will be presented with the state of each VNIC (synched/unsynched).
Will the admin be able to see the actual values? I think the synced property is not enough (I'm not sure how interesting this property is to start with).
Editing a VNIC / Changing a VNIC profile
Changing the profile a VM is using while the VM is running should behave like dynamic wiring (changing the VM network while it is running). Hot-plug of a vnic will will use will use the updated profile connected to the VNIC.
Not sure I fully understand the sentence above. Hot plug will be fully supported, you can choose any profile (you have permissions on) while plugging a new device.
Adding a Network
When adding a network, a user can provide an option to create a vNic Profile for it.
Question: Is it s default profile ? what are its properties ? Question: What about 'Public Use' option ? Are they still relevant in the context of adding new networks or we should eliminate them and move it only to 'Add vNic Profile' dialog?
see previous comments In addition when creating a profile we should have 'Allow all' for implicitly creating permissions, like we have today for network.
Updating a Network
When a network role is modified to be a 'non-VM network', all vNic profiles associated with it should be deleted.
And permissions associated with these profiles
Removing a Network
Should remove all profiles on that network
And associated permissions
Adding an Empty Data-Center
Currently, When creating a new Data-Center, the management network is automatically created. From 3.3, a default vNic profile will be created for the management network.
VM snapshot/import/export
We should handle VMs that are pointing to a network directly for backward compatibility. We need to select first profile that is on that network that the user has permissions on.
Question: Do we wish to support it export from 3.3 and import to 3.2 or below?
That means that when you write a VM in the OVF you need to write network in addition to profile.
Question: A user can import/export a VM/Template even if he doesn't have permissions on the networks. Is the next flow valid ?
The profile name should be saved in the OVF (in addition to the network name which is saved today). During import, if both (network name, profile name) exist on the target DC, the vnic will get the profile id. If the network exists in the Data-Center, but has no profile as specified in the OVF, the user will be notified (event log) and the VNIC will be connected to a default minimal profile defined in the system, regardless the permissions the user has on the network.
What is a 'default minimal profile' ? I would rather have a VNIC with no profile associated with it.
If failed to find any matching vNic profile, the vnic's profile will be set with 'none'.
When a Template is created from a VM the VNIC Profile will be kept along with the VNIC. When a VM is created from template the VNIC Profiles will be taken from the template's VNICs.
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "engine-devel" <engine-devel@ovirt.org>, "Ofri Masad" <omasad@redhat.com> Cc: "Mike Kolesnik" <mkolesni@redhat.com>, "Moti Asayag" <masayag@redhat.com>, "Oved Ourfalli" <oourfali@redhat.com> Sent: Sunday, June 30, 2013 3:59:37 PM Subject: VNIC profiles
Hi,
We are working on adding VNIC profiles as part of the work to add VNIC QoS.
http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles
We need to define some of the system behavior followed by this change, here is my take -
Editing a profile - -------------------- A user should be able to edit the profile properties (including profile name) while VMs are attached and are using this Profile (reference should be done by id).
Changing the network though is a bit more tricky as long as we don't have a way to distinguish between running and current configurations I think it could be very confusing to the user. Especially since we support dynamic wiring so the behavior IMO is unpredictable. I think it should be blocked at this point.
Edit a VNIC / change a VNIC profile - ------------------------------------ Changing the profile a VM is using while the VM is running should behave like dynamic wiring (changing the VM network while it is running).
Remove a Profile - ------------------- Is only valid if all VMs that are using this profile are in status down. It should update all VMs to point to no profile which should behave like none network today.
I see no reason to support a profile on a none network at this point.
The above is also relevant for upgrade flow (upgrading none network to point to no profile)
Removing a Network - ---------------------- should remove all profiles on that network
VM snapshot/import/export - -------------------------- We should handle VMs that are pointing to a network directly for b/w compatibility. we need to select first profile that is on that network that the user has permissions on.
I assume there are more, comments are welcome
Thanks, Livnat
I've updated the wiki accordingly and added few comments inline. ----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Moti Asayag" <masayag@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Ofri Masad" <omasad@redhat.com>, "Mike Kolesnik" <mkolesni@redhat.com>, "Oved Ourfalli" <oourfali@redhat.com> Sent: Sunday, July 7, 2013 2:59:34 PM Subject: Re: VNIC profiles
On 07/07/2013 01:59 PM, Moti Asayag wrote:
Hi,
I've updated the wiki with the feedbacks from this thread, added a backend section naming the affected commands and also add added few questions of my own embedded in the pastedtext below.
Hi Moti, A good and comprehensive description of the feature behavior. See my comments bellow -
In addition, another question here:
The units within the UI mockups are Mb and Mbps. The libvirt APIs expects the units to be in kb and kbps. Which component is responsible to convert them to the expect units ? engine or VDSM ?
Giuseppe mentioned that in a previous thread on this subject. Ofri and Giuseppe agreed that the translation would be done on the engine level.
Copied text from the wiki:
Adding a Profile
The network administrator could create several VNIC Profiles for each network. He could then grant a users with the permission to use (consume) each profile. The user will only be able to use profiles which he was granted access to.
For example: the network admin will create two VNIC profiles for network "blue":
Profile "Gold" - with better QoS and with port mirroring Profile "Silver" with lower QoS and without port mirroring.
I would use other names for the profiles to avoid confusion. Gold and Silver are likely to be QoS object names, a more typical name for a network profile is - teachers-blue and students-blue
The different profiles can have different QoS (teachers-blue would get Gold QoS while Students-blue will have Silver).
He will then define the user-group "students" as user of profile "Silver" and user-group "teachers" as user of profile "Gold". In this case the teachers will enjoy better quality of service then the students. When a teacher will add/edit a virtual NIC he could select profile "Gold" for that NIC - the VNIC will be connected to network "blue" with high QoS and with port mirroring.
Question: In the same matter we allowed via the UI to grant 'NetworkUser' to 'everyone' user, wouldn't it ease the use of Profiles if we support it in this context as well?
The ease of use could be that when creating a network we'll display in the UI all VNIC-QoS-objects and the users could tick next to the QoS they are interested in, for each QoS that was chosen a profile would be created.
I would enhance that with youe suggestion above and display next to the QoS that was checked the option to mark 'Allow All users' like we have today for making a network public, this option would give permission to everyone on that profile.
Editing a Profile
A user should be able to edit the profile properties (including profile name) while VMs are attached and are using this Profile (reference should be done by id). Changing the network of a vNic profile will be allowed only if no VMs are using the profile.
It would be better if we can limit this to no running VM is using the profile (or more simple to implement if all VMs that are using this profile are in status down).
Allowing to delete a vnic profile when used by vms is asymmetric to the network removal when it is used by vms or templates. Today the update network operation is blocked for that. In addition, with the suggest simplification to remove a profile when no running vms, the user will have to find for himself if the profile is being used prior to its removal since the operation will not be blocked. If we allow to delete a vnic profile, when a vm is using it (regardless the VM status) we'll have to update the VM entity as well in that operation: since we do not support a network with 'none' profile, we'll have to delete the network as well. If we'll remove a vnic profile in 3.1 cluster, used by vms in status down, we'd find a case in which a VM is attached to a 'none' network. This is unsupported in 3.1 cluster. We can block such operation, but this is another motivation why we'd better not to allow removing a used profile.
Since we have no way to distinguish between running and current configurations, the expected behavior of such a change is unpredictable and less intuitive to the user (especially since dynamic wiring is supported). The changes will seep down to all VNICs using the profile. In case VNIC using the edited profile are connected to running VMs, the change will apply only on the VM next run.
Question: What about Hibernate/Suspend VM ? will the resume VM action uses the original configuration for the vnics when the VM was started ?
Currently profile includes: network, port-mirroring, custom property, QoS
Changing any of the above (except for network) requires a VM reboot, so I think that we can start with the following statement - the profile change would only apply after next VM reboot.
There are 2 problems with the above: - Today we support network wiring, with VNIC profiles we are asking the users to create a new profile and attach the VMs to the new profile, I can see the RFE coming - we can report that ourselves ;)
- We don't reflect with which configuration the VM is running, e.g we edited the profile QoS but I'm not sure with which QoS the VM is currently running. (The RFE for differentiating between current configuration and running configuration was already asked for by numerous users)
The above is a general issue that we need to solve and I would not limit editing VNIC profiles because of it. We can mitigate this specifically for QoS like described bellow.
Deleting a Profile
VNIC Profiles could not be deleted from the engine as long as one or more VM/Templates are using those profiles.
Reporting vNic actual configuration
The engine will retrieve the actual configuration of the profile properties on the VNIC from VDSM (using the network statistics mechanism) and the networked administrator will be presented with the state of each VNIC (synched/unsynched).
Will the admin be able to see the actual values? I think the synced property is not enough (I'm not sure how interesting this property is to start with).
We can extend the VmGuestAgentInterface to contain the actual value, so they will be presented for each vnic in the 'guest data' sub-tab.
Editing a VNIC / Changing a VNIC profile
Changing the profile a VM is using while the VM is running should behave like dynamic wiring (changing the VM network while it is running). Hot-plug of a vnic will will use will use the updated profile connected to the VNIC.
Not sure I fully understand the sentence above. Hot plug will be fully supported, you can choose any profile (you have permissions on) while plugging a new device.
That was the intention. seems like an edgy hand syndrome :) Changed to: * Hot plug will be fully supported: the user can choose any permitted profile while plugging a new device or when activating an existing one.
Adding a Network
When adding a network, a user can provide an option to create a vNic Profile for it.
Question: Is it s default profile ? what are its properties ? Question: What about 'Public Use' option ? Are they still relevant in the context of adding new networks or we should eliminate them and move it only to 'Add vNic Profile' dialog?
see previous comments In addition when creating a profile we should have 'Allow all' for implicitly creating permissions, like we have today for network.
Updating a Network
When a network role is modified to be a 'non-VM network', all vNic profiles associated with it should be deleted.
And permissions associated with these profiles
Removing a Network
Should remove all profiles on that network
And associated permissions
Adding an Empty Data-Center
Currently, When creating a new Data-Center, the management network is automatically created. From 3.3, a default vNic profile will be created for the management network.
VM snapshot/import/export
We should handle VMs that are pointing to a network directly for backward compatibility. We need to select first profile that is on that network that the user has permissions on.
Question: Do we wish to support it export from 3.3 and import to 3.2 or below?
That means that when you write a VM in the OVF you need to write network in addition to profile.
The network name is already there, so when importing a vnic from 3.3 to an earlier version the profile name will be ignored.
Question: A user can import/export a VM/Template even if he doesn't have permissions on the networks. Is the next flow valid ?
The profile name should be saved in the OVF (in addition to the network name which is saved today). During import, if both (network name, profile name) exist on the target DC, the vnic will get the profile id. If the network exists in the Data-Center, but has no profile as specified in the OVF, the user will be notified (event log) and the VNIC will be connected to a default minimal profile defined in the system, regardless the permissions the user has on the network.
What is a 'default minimal profile' ? I would rather have a VNIC with no profile associated with it.
The 'default minimal profile' refers to a vnic profile with the lower average bandwidth. With the approach you've suggested, any imported VM/Template from an earlier to 3.3 version will require a manual intervention in order to configure a network to the VM. And for 3.1 we'll have to drop such vnics since network 'none' isn't supported.
If failed to find any matching vNic profile, the vnic's profile will be set with 'none'.
When a Template is created from a VM the VNIC Profile will be kept along with the VNIC. When a VM is created from template the VNIC Profiles will be taken from the template's VNICs.
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "engine-devel" <engine-devel@ovirt.org>, "Ofri Masad" <omasad@redhat.com> Cc: "Mike Kolesnik" <mkolesni@redhat.com>, "Moti Asayag" <masayag@redhat.com>, "Oved Ourfalli" <oourfali@redhat.com> Sent: Sunday, June 30, 2013 3:59:37 PM Subject: VNIC profiles
Hi,
We are working on adding VNIC profiles as part of the work to add VNIC QoS.
http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles
We need to define some of the system behavior followed by this change, here is my take -
Editing a profile - -------------------- A user should be able to edit the profile properties (including profile name) while VMs are attached and are using this Profile (reference should be done by id).
Changing the network though is a bit more tricky as long as we don't have a way to distinguish between running and current configurations I think it could be very confusing to the user. Especially since we support dynamic wiring so the behavior IMO is unpredictable. I think it should be blocked at this point.
Edit a VNIC / change a VNIC profile - ------------------------------------ Changing the profile a VM is using while the VM is running should behave like dynamic wiring (changing the VM network while it is running).
Remove a Profile - ------------------- Is only valid if all VMs that are using this profile are in status down. It should update all VMs to point to no profile which should behave like none network today.
I see no reason to support a profile on a none network at this point.
The above is also relevant for upgrade flow (upgrading none network to point to no profile)
Removing a Network - ---------------------- should remove all profiles on that network
VM snapshot/import/export - -------------------------- We should handle VMs that are pointing to a network directly for b/w compatibility. we need to select first profile that is on that network that the user has permissions on.
I assume there are more, comments are welcome
Thanks, Livnat
On 07/08/2013 12:36 AM, Moti Asayag wrote:
I've updated the wiki accordingly and added few comments inline.
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Moti Asayag" <masayag@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Ofri Masad" <omasad@redhat.com>, "Mike Kolesnik" <mkolesni@redhat.com>, "Oved Ourfalli" <oourfali@redhat.com> Sent: Sunday, July 7, 2013 2:59:34 PM Subject: Re: VNIC profiles
On 07/07/2013 01:59 PM, Moti Asayag wrote:
Hi,
I've updated the wiki with the feedbacks from this thread, added a backend section naming the affected commands and also add added few questions of my own embedded in the pastedtext below.
Hi Moti, A good and comprehensive description of the feature behavior. See my comments bellow -
In addition, another question here:
The units within the UI mockups are Mb and Mbps. The libvirt APIs expects the units to be in kb and kbps. Which component is responsible to convert them to the expect units ? engine or VDSM ?
Giuseppe mentioned that in a previous thread on this subject. Ofri and Giuseppe agreed that the translation would be done on the engine level.
Copied text from the wiki:
Adding a Profile
The network administrator could create several VNIC Profiles for each network. He could then grant a users with the permission to use (consume) each profile. The user will only be able to use profiles which he was granted access to.
For example: the network admin will create two VNIC profiles for network "blue":
Profile "Gold" - with better QoS and with port mirroring Profile "Silver" with lower QoS and without port mirroring.
I would use other names for the profiles to avoid confusion. Gold and Silver are likely to be QoS object names, a more typical name for a network profile is - teachers-blue and students-blue
The different profiles can have different QoS (teachers-blue would get Gold QoS while Students-blue will have Silver).
He will then define the user-group "students" as user of profile "Silver" and user-group "teachers" as user of profile "Gold". In this case the teachers will enjoy better quality of service then the students. When a teacher will add/edit a virtual NIC he could select profile "Gold" for that NIC - the VNIC will be connected to network "blue" with high QoS and with port mirroring.
Question: In the same matter we allowed via the UI to grant 'NetworkUser' to 'everyone' user, wouldn't it ease the use of Profiles if we support it in this context as well?
The ease of use could be that when creating a network we'll display in the UI all VNIC-QoS-objects and the users could tick next to the QoS they are interested in, for each QoS that was chosen a profile would be created.
I would enhance that with youe suggestion above and display next to the QoS that was checked the option to mark 'Allow All users' like we have today for making a network public, this option would give permission to everyone on that profile.
Editing a Profile
A user should be able to edit the profile properties (including profile name) while VMs are attached and are using this Profile (reference should be done by id). Changing the network of a vNic profile will be allowed only if no VMs are using the profile.
It would be better if we can limit this to no running VM is using the profile (or more simple to implement if all VMs that are using this profile are in status down).
Allowing to delete a vnic profile when used by vms is asymmetric to the network removal when it is used by vms or templates. Today the update network operation is blocked for that. In addition, with the suggest simplification to remove a profile when no running vms, the user will have to find for himself if the profile is being used prior to its removal since the operation will not be blocked.
If we allow to delete a vnic profile, when a vm is using it (regardless the VM status) we'll have to update the VM entity as well in that operation: since we do not support a network with 'none' profile, we'll have to delete the network as well.
If we'll remove a vnic profile in 3.1 cluster, used by vms in status down, we'd find a case in which a VM is attached to a 'none' network. This is unsupported in 3.1 cluster. We can block such operation, but this is another motivation why we'd better not to allow removing a used profile.
The context above is about editing not deleting :) I agree with what you wrote if the context was remove.
Since we have no way to distinguish between running and current configurations, the expected behavior of such a change is unpredictable and less intuitive to the user (especially since dynamic wiring is supported). The changes will seep down to all VNICs using the profile. In case VNIC using the edited profile are connected to running VMs, the change will apply only on the VM next run.
Question: What about Hibernate/Suspend VM ? will the resume VM action uses the original configuration for the vnics when the VM was started ?
Currently profile includes: network, port-mirroring, custom property, QoS
Changing any of the above (except for network) requires a VM reboot, so I think that we can start with the following statement - the profile change would only apply after next VM reboot.
There are 2 problems with the above: - Today we support network wiring, with VNIC profiles we are asking the users to create a new profile and attach the VMs to the new profile, I can see the RFE coming - we can report that ourselves ;)
- We don't reflect with which configuration the VM is running, e.g we edited the profile QoS but I'm not sure with which QoS the VM is currently running. (The RFE for differentiating between current configuration and running configuration was already asked for by numerous users)
The above is a general issue that we need to solve and I would not limit editing VNIC profiles because of it. We can mitigate this specifically for QoS like described bellow.
Deleting a Profile
VNIC Profiles could not be deleted from the engine as long as one or more VM/Templates are using those profiles.
Reporting vNic actual configuration
The engine will retrieve the actual configuration of the profile properties on the VNIC from VDSM (using the network statistics mechanism) and the networked administrator will be presented with the state of each VNIC (synched/unsynched).
Will the admin be able to see the actual values? I think the synced property is not enough (I'm not sure how interesting this property is to start with).
We can extend the VmGuestAgentInterface to contain the actual value, so they will be presented for each vnic in the 'guest data' sub-tab.
AFAIU this info does not come from the guest it is info we retrieve from libvirt. The VmGuestAgentInterface should be used only for information reported by the guest, information whose credibility can be questioned.
Editing a VNIC / Changing a VNIC profile
Changing the profile a VM is using while the VM is running should behave like dynamic wiring (changing the VM network while it is running). Hot-plug of a vnic will will use will use the updated profile connected to the VNIC.
Not sure I fully understand the sentence above. Hot plug will be fully supported, you can choose any profile (you have permissions on) while plugging a new device.
That was the intention. seems like an edgy hand syndrome :) Changed to: * Hot plug will be fully supported: the user can choose any permitted profile while plugging a new device or when activating an existing one.
Adding a Network
When adding a network, a user can provide an option to create a vNic Profile for it.
Question: Is it s default profile ? what are its properties ? Question: What about 'Public Use' option ? Are they still relevant in the context of adding new networks or we should eliminate them and move it only to 'Add vNic Profile' dialog?
see previous comments In addition when creating a profile we should have 'Allow all' for implicitly creating permissions, like we have today for network.
Updating a Network
When a network role is modified to be a 'non-VM network', all vNic profiles associated with it should be deleted.
And permissions associated with these profiles
Removing a Network
Should remove all profiles on that network
And associated permissions
Adding an Empty Data-Center
Currently, When creating a new Data-Center, the management network is automatically created. From 3.3, a default vNic profile will be created for the management network.
VM snapshot/import/export
We should handle VMs that are pointing to a network directly for backward compatibility. We need to select first profile that is on that network that the user has permissions on.
Question: Do we wish to support it export from 3.3 and import to 3.2 or below?
That means that when you write a VM in the OVF you need to write network in addition to profile.
The network name is already there, so when importing a vnic from 3.3 to an earlier version the profile name will be ignored.
Question: A user can import/export a VM/Template even if he doesn't have permissions on the networks. Is the next flow valid ?
The profile name should be saved in the OVF (in addition to the network name which is saved today). During import, if both (network name, profile name) exist on the target DC, the vnic will get the profile id. If the network exists in the Data-Center, but has no profile as specified in the OVF, the user will be notified (event log) and the VNIC will be connected to a default minimal profile defined in the system, regardless the permissions the user has on the network.
What is a 'default minimal profile' ? I would rather have a VNIC with no profile associated with it.
The 'default minimal profile' refers to a vnic profile with the lower average bandwidth.
With the approach you've suggested, any imported VM/Template from an earlier to 3.3 version will require a manual intervention in order to configure a network to the VM.
I should have elaborated some more - If a VM has a profile then we should look up this specific profile, if such a profile does not exists then import the VM with profile none like we do today for VM's with reference to a network that does not exist on the setup. If a VM does not have a profile (3.2 and lower versions) we should look into the network name, if this network exist and we have a profile with permissions to the user then use this profile (if there is more than one choose one randomly).
And for 3.1 we'll have to drop such vnics since network 'none' isn't supported.
If failed to find any matching vNic profile, the vnic's profile will be set with 'none'.
When a Template is created from a VM the VNIC Profile will be kept along with the VNIC. When a VM is created from template the VNIC Profiles will be taken from the template's VNICs.
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "engine-devel" <engine-devel@ovirt.org>, "Ofri Masad" <omasad@redhat.com> Cc: "Mike Kolesnik" <mkolesni@redhat.com>, "Moti Asayag" <masayag@redhat.com>, "Oved Ourfalli" <oourfali@redhat.com> Sent: Sunday, June 30, 2013 3:59:37 PM Subject: VNIC profiles
Hi,
We are working on adding VNIC profiles as part of the work to add VNIC QoS.
http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles
We need to define some of the system behavior followed by this change, here is my take -
Editing a profile - -------------------- A user should be able to edit the profile properties (including profile name) while VMs are attached and are using this Profile (reference should be done by id).
Changing the network though is a bit more tricky as long as we don't have a way to distinguish between running and current configurations I think it could be very confusing to the user. Especially since we support dynamic wiring so the behavior IMO is unpredictable. I think it should be blocked at this point.
Edit a VNIC / change a VNIC profile - ------------------------------------ Changing the profile a VM is using while the VM is running should behave like dynamic wiring (changing the VM network while it is running).
Remove a Profile - ------------------- Is only valid if all VMs that are using this profile are in status down. It should update all VMs to point to no profile which should behave like none network today.
I see no reason to support a profile on a none network at this point.
The above is also relevant for upgrade flow (upgrading none network to point to no profile)
Removing a Network - ---------------------- should remove all profiles on that network
VM snapshot/import/export - -------------------------- We should handle VMs that are pointing to a network directly for b/w compatibility. we need to select first profile that is on that network that the user has permissions on.
I assume there are more, comments are welcome
Thanks, Livnat
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Moti Asayag" <masayag@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Ofri Masad" <omasad@redhat.com>, "Mike Kolesnik" <mkolesni@redhat.com>, "Oved Ourfalli" <oourfali@redhat.com> Sent: Monday, July 8, 2013 10:11:15 AM Subject: Re: VNIC profiles
On 07/08/2013 12:36 AM, Moti Asayag wrote:
I've updated the wiki accordingly and added few comments inline.
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Moti Asayag" <masayag@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Ofri Masad" <omasad@redhat.com>, "Mike Kolesnik" <mkolesni@redhat.com>, "Oved Ourfalli" <oourfali@redhat.com> Sent: Sunday, July 7, 2013 2:59:34 PM Subject: Re: VNIC profiles
On 07/07/2013 01:59 PM, Moti Asayag wrote:
Hi,
I've updated the wiki with the feedbacks from this thread, added a backend section naming the affected commands and also add added few questions of my own embedded in the pastedtext below.
Hi Moti, A good and comprehensive description of the feature behavior. See my comments bellow -
In addition, another question here:
The units within the UI mockups are Mb and Mbps. The libvirt APIs expects the units to be in kb and kbps. Which component is responsible to convert them to the expect units ? engine or VDSM ?
Giuseppe mentioned that in a previous thread on this subject. Ofri and Giuseppe agreed that the translation would be done on the engine level.
Copied text from the wiki:
Adding a Profile
The network administrator could create several VNIC Profiles for each network. He could then grant a users with the permission to use (consume) each profile. The user will only be able to use profiles which he was granted access to.
For example: the network admin will create two VNIC profiles for network "blue":
Profile "Gold" - with better QoS and with port mirroring Profile "Silver" with lower QoS and without port mirroring.
I would use other names for the profiles to avoid confusion. Gold and Silver are likely to be QoS object names, a more typical name for a network profile is - teachers-blue and students-blue
The different profiles can have different QoS (teachers-blue would get Gold QoS while Students-blue will have Silver).
He will then define the user-group "students" as user of profile "Silver" and user-group "teachers" as user of profile "Gold". In this case the teachers will enjoy better quality of service then the students. When a teacher will add/edit a virtual NIC he could select profile "Gold" for that NIC - the VNIC will be connected to network "blue" with high QoS and with port mirroring.
Question: In the same matter we allowed via the UI to grant 'NetworkUser' to 'everyone' user, wouldn't it ease the use of Profiles if we support it in this context as well?
The ease of use could be that when creating a network we'll display in the UI all VNIC-QoS-objects and the users could tick next to the QoS they are interested in, for each QoS that was chosen a profile would be created.
I would enhance that with youe suggestion above and display next to the QoS that was checked the option to mark 'Allow All users' like we have today for making a network public, this option would give permission to everyone on that profile.
Editing a Profile
A user should be able to edit the profile properties (including profile name) while VMs are attached and are using this Profile (reference should be done by id). Changing the network of a vNic profile will be allowed only if no VMs are using the profile.
It would be better if we can limit this to no running VM is using the profile (or more simple to implement if all VMs that are using this profile are in status down).
Allowing to delete a vnic profile when used by vms is asymmetric to the network removal when it is used by vms or templates. Today the update network operation is blocked for that. In addition, with the suggest simplification to remove a profile when no running vms, the user will have to find for himself if the profile is being used prior to its removal since the operation will not be blocked.
If we allow to delete a vnic profile, when a vm is using it (regardless the VM status) we'll have to update the VM entity as well in that operation: since we do not support a network with 'none' profile, we'll have to delete the network as well.
If we'll remove a vnic profile in 3.1 cluster, used by vms in status down, we'd find a case in which a VM is attached to a 'none' network. This is unsupported in 3.1 cluster. We can block such operation, but this is another motivation why we'd better not to allow removing a used profile.
The context above is about editing not deleting :) I agree with what you wrote if the context was remove.
Since we have no way to distinguish between running and current configurations, the expected behavior of such a change is unpredictable and less intuitive to the user (especially since dynamic wiring is supported). The changes will seep down to all VNICs using the profile. In case VNIC using the edited profile are connected to running VMs, the change will apply only on the VM next run.
Question: What about Hibernate/Suspend VM ? will the resume VM action uses the original configuration for the vnics when the VM was started ?
Currently profile includes: network, port-mirroring, custom property, QoS
Changing any of the above (except for network) requires a VM reboot, so I think that we can start with the following statement - the profile change would only apply after next VM reboot.
There are 2 problems with the above: - Today we support network wiring, with VNIC profiles we are asking the users to create a new profile and attach the VMs to the new profile, I can see the RFE coming - we can report that ourselves ;)
- We don't reflect with which configuration the VM is running, e.g we edited the profile QoS but I'm not sure with which QoS the VM is currently running. (The RFE for differentiating between current configuration and running configuration was already asked for by numerous users)
The above is a general issue that we need to solve and I would not limit editing VNIC profiles because of it. We can mitigate this specifically for QoS like described bellow.
Deleting a Profile
VNIC Profiles could not be deleted from the engine as long as one or more VM/Templates are using those profiles.
Reporting vNic actual configuration
The engine will retrieve the actual configuration of the profile properties on the VNIC from VDSM (using the network statistics mechanism) and the networked administrator will be presented with the state of each VNIC (synched/unsynched).
Will the admin be able to see the actual values? I think the synced property is not enough (I'm not sure how interesting this property is to start with).
We can extend the VmGuestAgentInterface to contain the actual value, so they will be presented for each vnic in the 'guest data' sub-tab.
AFAIU this info does not come from the guest it is info we retrieve from libvirt. The VmGuestAgentInterface should be used only for information reported by the guest, information whose credibility can be questioned.
we'll use the vm network statistics to persist that information which will be presented to the user in new sub-tab under the vm-network-interface sub-tab.
Editing a VNIC / Changing a VNIC profile
Changing the profile a VM is using while the VM is running should behave like dynamic wiring (changing the VM network while it is running). Hot-plug of a vnic will will use will use the updated profile connected to the VNIC.
Not sure I fully understand the sentence above. Hot plug will be fully supported, you can choose any profile (you have permissions on) while plugging a new device.
That was the intention. seems like an edgy hand syndrome :) Changed to: * Hot plug will be fully supported: the user can choose any permitted profile while plugging a new device or when activating an existing one.
Adding a Network
When adding a network, a user can provide an option to create a vNic Profile for it.
Question: Is it s default profile ? what are its properties ? Question: What about 'Public Use' option ? Are they still relevant in the context of adding new networks or we should eliminate them and move it only to 'Add vNic Profile' dialog?
see previous comments In addition when creating a profile we should have 'Allow all' for implicitly creating permissions, like we have today for network.
Updating a Network
When a network role is modified to be a 'non-VM network', all vNic profiles associated with it should be deleted.
And permissions associated with these profiles
Removing a Network
Should remove all profiles on that network
And associated permissions
Adding an Empty Data-Center
Currently, When creating a new Data-Center, the management network is automatically created. From 3.3, a default vNic profile will be created for the management network.
VM snapshot/import/export
We should handle VMs that are pointing to a network directly for backward compatibility. We need to select first profile that is on that network that the user has permissions on.
Question: Do we wish to support it export from 3.3 and import to 3.2 or below?
That means that when you write a VM in the OVF you need to write network in addition to profile.
The network name is already there, so when importing a vnic from 3.3 to an earlier version the profile name will be ignored.
Question: A user can import/export a VM/Template even if he doesn't have permissions on the networks. Is the next flow valid ?
The profile name should be saved in the OVF (in addition to the network name which is saved today). During import, if both (network name, profile name) exist on the target DC, the vnic will get the profile id. If the network exists in the Data-Center, but has no profile as specified in the OVF, the user will be notified (event log) and the VNIC will be connected to a default minimal profile defined in the system, regardless the permissions the user has on the network.
What is a 'default minimal profile' ? I would rather have a VNIC with no profile associated with it.
The 'default minimal profile' refers to a vnic profile with the lower average bandwidth.
With the approach you've suggested, any imported VM/Template from an earlier to 3.3 version will require a manual intervention in order to configure a network to the VM.
I should have elaborated some more -
If a VM has a profile then we should look up this specific profile, if such a profile does not exists then import the VM with profile none like we do today for VM's with reference to a network that does not exist on the setup.
If a VM does not have a profile (3.2 and lower versions) we should look into the network name, if this network exist and we have a profile with permissions to the user then use this profile (if there is more than one choose one randomly).
The wiki was updated with the VM/Template import logic: http://www.ovirt.org/Features/Vnic_Profiles#VM_snapshot.2Fimport.2Fexport
And for 3.1 we'll have to drop such vnics since network 'none' isn't supported.
If failed to find any matching vNic profile, the vnic's profile will be set with 'none'.
When a Template is created from a VM the VNIC Profile will be kept along with the VNIC. When a VM is created from template the VNIC Profiles will be taken from the template's VNICs.
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "engine-devel" <engine-devel@ovirt.org>, "Ofri Masad" <omasad@redhat.com> Cc: "Mike Kolesnik" <mkolesni@redhat.com>, "Moti Asayag" <masayag@redhat.com>, "Oved Ourfalli" <oourfali@redhat.com> Sent: Sunday, June 30, 2013 3:59:37 PM Subject: VNIC profiles
Hi,
We are working on adding VNIC profiles as part of the work to add VNIC QoS.
http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles
We need to define some of the system behavior followed by this change, here is my take -
Editing a profile - -------------------- A user should be able to edit the profile properties (including profile name) while VMs are attached and are using this Profile (reference should be done by id).
Changing the network though is a bit more tricky as long as we don't have a way to distinguish between running and current configurations I think it could be very confusing to the user. Especially since we support dynamic wiring so the behavior IMO is unpredictable. I think it should be blocked at this point.
Edit a VNIC / change a VNIC profile - ------------------------------------ Changing the profile a VM is using while the VM is running should behave like dynamic wiring (changing the VM network while it is running).
Remove a Profile - ------------------- Is only valid if all VMs that are using this profile are in status down. It should update all VMs to point to no profile which should behave like none network today.
I see no reason to support a profile on a none network at this point.
The above is also relevant for upgrade flow (upgrading none network to point to no profile)
Removing a Network - ---------------------- should remove all profiles on that network
VM snapshot/import/export - -------------------------- We should handle VMs that are pointing to a network directly for b/w compatibility. we need to select first profile that is on that network that the user has permissions on.
I assume there are more, comments are welcome
Thanks, Livnat
On 07/08/2013 11:21 AM, Moti Asayag wrote:
...
The wiki was updated with the VM/Template import logic:
http://www.ovirt.org/Features/Vnic_Profiles#VM_snapshot.2Fimport.2Fexport
1. you are updating the OVF - have you found a matching field in the OVF spec[1] for vnic profiles? 2. import/export - please note exporting is backward compatible based on DC level (iirc - omer should remember better), i.e., if the DC is 3.2, the export should ignore vnic profiles, etc. 3. while at it - just to make sure before i add more comments- are the screenshots in the wiki up to date? Thanks, Itamar [1] http://dmtf.org/standards/ovf
On 07/13/2013 01:17 PM, Itamar Heim wrote:
On 07/08/2013 11:21 AM, Moti Asayag wrote:
...
The wiki was updated with the VM/Template import logic:
http://www.ovirt.org/Features/Vnic_Profiles#VM_snapshot.2Fimport.2Fexport
1. you are updating the OVF - have you found a matching field in the OVF spec[1] for vnic profiles?
Currently the only field used to specify the network is "Connection". There is no specific field for specifying a vnic profile. We can make a use of the 'OtherResourceType' which isn't in use by the engine for storing the vnic profile name. An alternative would be using the Connection field to store both Network:Profile, and parsing it when a vm or template are being imported. I'm in favour of the first option for simplicity and in order not to modify the Connection field as is being used today.
2. import/export - please note exporting is backward compatible based on DC level (iirc - omer should remember better), i.e., if the DC is 3.2, the export should ignore vnic profiles, etc.
3. while at it - just to make sure before i add more comments- are the screenshots in the wiki up to date?
The images should be updated since the vnic profiles will be a main-tab, appears only when a network is selected, instead of a sub-tab of the networks.
Thanks, Itamar
On 07/14/2013 11:25 AM, Moti Asayag wrote:
2. import/export - please note exporting is backward compatible based on
DC level (iirc - omer should remember better), i.e., if the DC is 3.2, the export should ignore vnic profiles, etc.
3. while at it - just to make sure before i add more comments- are the screenshots in the wiki up to date? The images should be updated since the vnic profiles will be a main-tab, appears only when a network is selected, instead of a sub-tab of the networks.
that sounds a bit arduous (a main tab appearing only when standing on a specific entity)?
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Moti Asayag" <masayag@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Sunday, July 14, 2013 12:58:39 PM Subject: Re: [Engine-devel] VNIC profiles
On 07/14/2013 11:25 AM, Moti Asayag wrote:
2. import/export - please note exporting is backward compatible based on
DC level (iirc - omer should remember better), i.e., if the DC is 3.2, the export should ignore vnic profiles, etc.
3. while at it - just to make sure before i add more comments- are the screenshots in the wiki up to date? The images should be updated since the vnic profiles will be a main-tab, appears only when a network is selected, instead of a sub-tab of the networks.
that sounds a bit arduous (a main tab appearing only when standing on a specific entity)? That's how Quota works:) I think it would be great if we could show profiles main tab also under system. But as we have too many main tabs under system and we don't have the option to close tabs we don't want to see, we decided not to put profiles main tab under system.
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 07/15/2013 03:58 PM, Alona Kaplan wrote:
2. import/export - please note exporting is backward compatible based on
>> >DC level (iirc - omer should remember better), i.e., if the DC is 3.2, >> >the export should ignore vnic profiles, etc. >> > >> >3. while at it - just to make sure before i add more comments- are the >> >screenshots in the wiki up to date? The images should be updated since the vnic profiles will be a main-tab, appears only when a network is selected, instead of a sub-tab of the networks.
that sounds a bit arduous (a main tab appearing only when standing on a specific entity)? That's how Quota works:) I think it would be great if we could show profiles main tab also under system. But as we have too many main tabs under system and we don't have the option to close tabs we don't want to see, we decided not to put profiles main tab under system.
quota's are at DC level. vnic profiles are at logical network level?
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Alona Kaplan" <alkaplan@redhat.com> Cc: "Moti Asayag" <masayag@redhat.com>, "engine-devel" <engine-devel@ovirt.org> Sent: Monday, July 15, 2013 4:07:16 PM Subject: Re: [Engine-devel] VNIC profiles
On 07/15/2013 03:58 PM, Alona Kaplan wrote:
2. import/export - please note exporting is backward compatible based on
> >> >DC level (iirc - omer should remember better), i.e., if the DC is > >> >3.2, > >> >the export should ignore vnic profiles, etc. > >> > > >> >3. while at it - just to make sure before i add more comments- > >> >are the > >> >screenshots in the wiki up to date? The images should be updated since the vnic profiles will be a main-tab, appears only when a network is selected, instead of a sub-tab of the networks.
that sounds a bit arduous (a main tab appearing only when standing on a specific entity)? That's how Quota works:) I think it would be great if we could show profiles main tab also under system. But as we have too many main tabs under system and we don't have the option to close tabs we don't want to see, we decided not to put profiles main tab under system.
quota's are at DC level. vnic profiles are at logical network level?
Yes, profiles are at logical network level. But the tab can be visible on dc context as well. It can be convenient since the user can change the profile's network.
On 07/15/2013 04:40 PM, Alona Kaplan wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Alona Kaplan" <alkaplan@redhat.com> Cc: "Moti Asayag" <masayag@redhat.com>, "engine-devel" <engine-devel@ovirt.org> Sent: Monday, July 15, 2013 4:07:16 PM Subject: Re: [Engine-devel] VNIC profiles
On 07/15/2013 03:58 PM, Alona Kaplan wrote:
2. import/export - please note exporting is backward compatible based on >>>>> DC level (iirc - omer should remember better), i.e., if the DC is >>>>> 3.2, >>>>> the export should ignore vnic profiles, etc. >>>>> >>>>> 3. while at it - just to make sure before i add more comments- >>>>> are the >>>>> screenshots in the wiki up to date? > The images should be updated since the vnic profiles will be a > main-tab, > appears only when a network is selected, instead of a sub-tab of the > networks. >
that sounds a bit arduous (a main tab appearing only when standing on a specific entity)? That's how Quota works:) I think it would be great if we could show profiles main tab also under system. But as we have too many main tabs under system and we don't have the option to close tabs we don't want to see, we decided not to put profiles main tab under system.
quota's are at DC level. vnic profiles are at logical network level?
Yes, profiles are at logical network level. But the tab can be visible on dc context as well. It can be convenient since the user can change the profile's network.
it will be easier for me to continue the discussion when the screenshots/mockups are updated i guess. Thanks, Itamar
----- Original Message -----
From: "Moti Asayag" <masayag@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Sunday, July 14, 2013 11:25:41 AM Subject: Re: [Engine-devel] VNIC profiles
On 07/13/2013 01:17 PM, Itamar Heim wrote:
On 07/08/2013 11:21 AM, Moti Asayag wrote:
...
The wiki was updated with the VM/Template import logic:
http://www.ovirt.org/Features/Vnic_Profiles#VM_snapshot.2Fimport.2Fexport
1. you are updating the OVF - have you found a matching field in the OVF spec[1] for vnic profiles?
Currently the only field used to specify the network is "Connection". There is no specific field for specifying a vnic profile. We can make a use of the 'OtherResourceType' which isn't in use by the engine for storing the vnic profile name.
An alternative would be using the Connection field to store both Network:Profile, and parsing it when a vm or template are being imported.
I'm in favour of the first option for simplicity and in order not to modify the Connection field as is being used today.
I'm in favor of this option as well.
2. import/export - please note exporting is backward compatible based on DC level (iirc - omer should remember better), i.e., if the DC is 3.2, the export should ignore vnic profiles, etc.
3. while at it - just to make sure before i add more comments- are the screenshots in the wiki up to date?
The images should be updated since the vnic profiles will be a main-tab, appears only when a network is selected, instead of a sub-tab of the networks.
Thanks, Itamar
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
participants (7)
-
Alona Kaplan -
Eli Mesika -
Itamar Heim -
Livnat Peer -
Malini Rao -
Moti Asayag -
Oved Ourfalli