<html><body><div style="font-family: times new roman, new york, times, serif; font-size: 12pt; color: #000000"><div>Hi Moti,<br></div><div><br></div><div>Thanks for the quick response,<br></div><div><br></div><div>Please look down at the comment.<br></div><div><br></div><div><br></div><div>Amihay<br></div><hr id="zwchr"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Moti Asayag" <masayag@redhat.com><br><b>To: </b>"Amihay Winter" <awinter@redhat.com><br><b>Cc: </b>engine-devel@ovirt.org, "Livnat Peer" <lpeer@redhat.com><br><b>Sent: </b>Sunday, July 28, 2013 3:33:27 PM<br><b>Subject: </b>Re: VNIC profiles & Device Custom Properties<br><div><br></div>Hi Amihay,<br><div><br></div>Thank you for your inputs on the feature. See answers in-line for each of the raised issues.<br><div><br></div>----- Original Message -----<br>> From: "Amihay Winter" <awinter@redhat.com><br>> To: engine-devel@ovirt.org<br>> Cc: "Moti Asayag" <masayag@redhat.com>, "Livnat Peer" <lpeer@redhat.com><br>> Sent: Tuesday, July 23, 2013 3:12:45 PM<br>> Subject: VNIC profiles & Device Custom Properties<br>> <br>> Hi all,<br>> <br>> I'm building a TCMS plan for the Device Custom Properties feature and I came<br>> across some questions.<br>> I'm sorry that I'm a little late with my thoughts but I hope you'll still<br>> hear them out.<br>> Also, I know It's a little long but please bear with me :)<br>> <br>> I want to talk about two things:<br>> 1. Sending an updateDevice verb whenever clicking on "Edit" and than "OK".<br>> 2. Setting Port Mirroring at the configuring of a nic and not at the profile.<br>> <br>> 1.According to the Vnic_Profiles's wiki (in the Editing a profile section) it<br>> says:<br>> "The changes will seep down to all VNICs using the profile.<br>> In case VNIC using the edited profile are connected to running VMs, the<br>> change will apply only on the VM next run."<br>> I'll describe a Scenario:<br>> Creating profile A with property speed = 500<br>> Setting vnic2 on vm to have profile A (using Hotplugnic)<br>> Changing (in the profile) speed = 700<br>> According to the Vnic_Profiles's wiki, only when I restart my vm I'll get my<br>> setting right.<br>> In my opinion, If we could enable the update of those setting LIVE we will<br>> give the clients a better solution in the Vnic Profiles.<br>> I will be able to update all of my 1000 vms in a few minutes with a single<br>> script instead of restarting them all and maybe stopping others' work.<br>> I think that restarting 1000 vms because I want to set a property is not<br>> something that an admin would want to do.<br>> One way to implement it is to send a verb "updateDevice" each time we open<br>> the the "Edit" window and clicking "OK"<br>> I guess that when the design of update device was made, we tried to send<br>> minimal verbs, but in this case, I think that if a user clicked on "Edit" &<br>> "OK" then he wanted to send the verb, otherwise, he would have pressed on<br>> "Edit" & "Cancel".<br>> <br>> Sending this verb will allow us to keep the vms update with, in my opinion,<br>> minimum cost and with great profit - Giving the client a "more correct<br>> environment" LIVE.<br><div><br></div>The engine-vdsm has a verb for updating a device. It is sent when the engine<br>detect a change in the state of the vnic which requires updating the device.<br>However, the engine doesn't store the vnic profile definition used to activate<br>the vnic.<br><div><br></div>Instead of restarting the VM, the user can plug-unplug the specific device, if<br>it already activated.</blockquote><div><br></div><div>I know that plug/unplug the specific device will propagate the change but why use only the hotplug &<br></div><div>hotunplug verbs? why not using the updateDevice verb as well?<br></div><div>Isn't LIVE (without losing connectivity to vm (because the hotunplug)) is better?<br></div><div><br></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div><br></div>> <br>> 2. I'll start with saying that in my opinion, the Vnic Profile feature was<br>> created to give the client a *more dynamic network environment* and I<br>> support.<br>> But, I think that the statical variables like MAC, Un/Pluged and Port<br>> Mirroring which always exist should be at the nic and not in the profile.<br>> In my opinion, Profile's properties may have: max_mtu, min_mtu, mtu, speed,<br>> id, vlan... Identifiers for the network.<br>> Maybe I'm missing something but it seems natural to me that the port<br>> mirroring will be at nic and not at the profile.<br>> <br><div><br></div>I'm not sure how port mirroring is commonly used to enable it on vnic level.<br>Having the port mirroring on vnic profile level allows to control the network<br>usage in a concentrated place.<br><div><br></div>In both cases, we're a bit late on schedule, therefore changes would be done <br>later on if required.<br><div><br></div>> I'll really appreciate comments.<br>> Thank you for your time.<br>> Amihay Winter<br>> <br>> ----- Original Message -----<br>> <br>> > ----- Forwarded Message -----<br>> > From: "Livnat Peer" <lpeer@redhat.com><br>> > To: "Moti Asayag" <masayag@redhat.com><br>> > Cc: "engine-devel" <engine-devel@ovirt.org>, "Ofri Masad"<br>> > <omasad@redhat.com>, "Mike Kolesnik" <mkolesni@redhat.com>, "Oved Ourfalli"<br>> > <oourfali@redhat.com><br>> > Sent: Monday, July 8, 2013 10:11:15 AM<br>> > Subject: Re: VNIC profiles<br>> <br>> > On 07/08/2013 12:36 AM, Moti Asayag wrote:<br>> > > I've updated the wiki accordingly and added few comments inline.<br>> > ><br>> > > ----- Original Message -----<br>> > >> From: "Livnat Peer" <lpeer@redhat.com><br>> > >> To: "Moti Asayag" <masayag@redhat.com><br>> > >> Cc: "engine-devel" <engine-devel@ovirt.org>, "Ofri Masad"<br>> > >> <omasad@redhat.com>, "Mike Kolesnik" <mkolesni@redhat.com>,<br>> > >> "Oved Ourfalli" <oourfali@redhat.com><br>> > >> Sent: Sunday, July 7, 2013 2:59:34 PM<br>> > >> Subject: Re: VNIC profiles<br>> > >><br>> > >> On 07/07/2013 01:59 PM, Moti Asayag wrote:<br>> > >>> Hi,<br>> > >>><br>> > >>> I've updated the wiki with the feedbacks from this thread, added a<br>> > >>> backend<br>> > >>> section naming the affected commands and also add added few questions<br>> > >>> of<br>> > >>> my own embedded in the pastedtext below.<br>> > >>><br>> > >><br>> > >> Hi Moti,<br>> > >> A good and comprehensive description of the feature behavior.<br>> > >> See my comments bellow -<br>> > >><br>> > >>> In addition, another question here:<br>> > >>><br>> > >>> The units within the UI mockups are Mb and Mbps. The libvirt APIs<br>> > >>> expects<br>> > >>> the units to be in kb and kbps. Which component is responsible to<br>> > >>> convert<br>> > >>> them to the expect units ? engine or VDSM ?<br>> > >><br>> > >> Giuseppe mentioned that in a previous thread on this subject.<br>> > >> Ofri and Giuseppe agreed that the translation would be done on the<br>> > >> engine level.<br>> > >><br>> > >><br>> > >>><br>> > >>> Copied text from the wiki:<br>> > >>><br>> > >>> Adding a Profile<br>> > >>><br>> > >>> The network administrator could create several VNIC Profiles for each<br>> > >>> network. He could then grant a users with the permission to use<br>> > >>> (consume)<br>> > >>> each profile. The user will only be able to use profiles which he was<br>> > >>> granted access to.<br>> > >>><br>> > >>> For example: the network admin will create two VNIC profiles for<br>> > >>> network "blue":<br>> > >>><br>> > >>> Profile "Gold" - with better QoS and with port mirroring<br>> > >>> Profile "Silver" with lower QoS and without port mirroring.<br>> > >>><br>> > >><br>> > >> I would use other names for the profiles to avoid confusion.<br>> > >> Gold and Silver are likely to be QoS object names, a more typical name<br>> > >> for a network profile is - teachers-blue and students-blue<br>> > >><br>> > >> The different profiles can have different QoS (teachers-blue would get<br>> > >> Gold QoS while Students-blue will have Silver).<br>> > >><br>> > >><br>> > >>> He will then define the user-group "students" as user of profile<br>> > >>> "Silver" and user-group "teachers" as user of profile "Gold". In this<br>> > >>> case the teachers will enjoy better quality of service then the<br>> > >>> students. When a teacher will add/edit a virtual NIC he could select<br>> > >>> profile "Gold" for that NIC - the VNIC will be connected to network<br>> > >>> "blue" with high QoS and with port mirroring.<br>> > >>><br>> > >>> Question: In the same matter we allowed via the UI to grant<br>> > >>> 'NetworkUser'<br>> > >>> to 'everyone' user, wouldn't it ease the use of Profiles if we support<br>> > >>> it<br>> > >>> in this context as well?<br>> > >><br>> > >> The ease of use could be that when creating a network we'll display in<br>> > >> the UI all VNIC-QoS-objects and the users could tick next to the QoS<br>> > >> they are interested in, for each QoS that was chosen a profile would be<br>> > >> created.<br>> > >><br>> > >> I would enhance that with youe suggestion above and display next to the<br>> > >> QoS that was checked the option to mark 'Allow All users' like we have<br>> > >> today for making a network public, this option would give permission to<br>> > >> everyone on that profile.<br>> > >><br>> > >><br>> > >>><br>> > >>> Editing a Profile<br>> > >>><br>> > >>> A user should be able to edit the profile properties (including profile<br>> > >>> name) while VMs are attached and are using this Profile (reference<br>> > >>> should be done by id).<br>> > >>> Changing the network of a vNic profile will be allowed only if no VMs<br>> > >>> are using the profile.<br>> > >><br>> > >> It would be better if we can limit this to no running VM is using the<br>> > >> profile (or more simple to implement if all VMs that are using this<br>> > >> profile are in status down).<br>> > ><br>> > > Allowing to delete a vnic profile when used by vms is asymmetric to the<br>> > > network removal<br>> > > when it is used by vms or templates. Today the update network operation<br>> > > is<br>> > > blocked for that.<br>> > > In addition, with the suggest simplification to remove a profile when no<br>> > > running vms, the user<br>> > > will have to find for himself if the profile is being used prior to its<br>> > > removal since the<br>> > > operation will not be blocked.<br>> > ><br>> > > If we allow to delete a vnic profile, when a vm is using it (regardless<br>> > > the<br>> > > VM status)<br>> > > we'll have to update the VM entity as well in that operation: since we do<br>> > > not support a<br>> > > network with 'none' profile, we'll have to delete the network as well.<br>> > ><br>> > > If we'll remove a vnic profile in 3.1 cluster, used by vms in status<br>> > > down,<br>> > > we'd find a case<br>> > > in which a VM is attached to a 'none' network. This is unsupported in 3.1<br>> > > cluster. We can block<br>> > > such operation, but this is another motivation why we'd better not to<br>> > > allow<br>> > > removing a used profile.<br>> > ><br>> <br>> > The context above is about editing not deleting :)<br>> > I agree with what you wrote if the context was remove.<br>> <br>> > >><br>> > >>> Since we have no way to distinguish between running and current<br>> > >>> configurations, the expected behavior of such a change is<br>> > >>> unpredictable and less intuitive to the user (especially since<br>> > >>> dynamic wiring is supported).<br>> > >>> The changes will seep down to all VNICs using the profile.<br>> > >>> In case VNIC using the edited profile are connected to running VMs,<br>> > >>> the change will apply only on the VM next run.<br>> > >>><br>> > >>> Question: What about Hibernate/Suspend VM ? will the resume VM action<br>> > >>> uses<br>> > >>> the original configuration for the vnics when the VM was started ?<br>> > >><br>> > >> Currently profile includes: network, port-mirroring, custom property,<br>> > >> QoS<br>> > >><br>> > >> Changing any of the above (except for network) requires a VM reboot, so<br>> > >> I think that we can start with the following statement - the profile<br>> > >> change would only apply after next VM reboot.<br>> > >><br>> > >> There are 2 problems with the above:<br>> > >> - Today we support network wiring, with VNIC profiles we are asking the<br>> > >> users to create a new profile and attach the VMs to the new profile, I<br>> > >> can see the RFE coming - we can report that ourselves ;)<br>> > >><br>> > >> - We don't reflect with which configuration the VM is running, e.g we<br>> > >> edited the profile QoS but I'm not sure with which QoS the VM is<br>> > >> currently running. (The RFE for differentiating between current<br>> > >> configuration and running configuration was already asked for by<br>> > >> numerous users)<br>> > >><br>> > >> The above is a general issue that we need to solve and I would not limit<br>> > >> editing VNIC profiles because of it.<br>> > >> We can mitigate this specifically for QoS like described bellow.<br>> > >><br>> > >><br>> > >><br>> > >>> Deleting a Profile<br>> > >>><br>> > >>> VNIC Profiles could not be deleted from the engine as long as one or<br>> > >>> more<br>> > >>> VM/Templates are using those profiles.<br>> > >><br>> > >>> Reporting vNic actual configuration<br>> > >>><br>> > >>> The engine will retrieve the actual configuration of the profile<br>> > >>> properties on the VNIC from VDSM (using the network statistics<br>> > >>> mechanism) and the networked administrator will be presented with the<br>> > >>> state of each VNIC (synched/unsynched).<br>> > >>><br>> > >><br>> > >> Will the admin be able to see the actual values? I think the synced<br>> > >> property is not enough (I'm not sure how interesting this property is to<br>> > >> start with).<br>> > ><br>> > > We can extend the VmGuestAgentInterface to contain the actual value, so<br>> > > they<br>> > > will be presented for each vnic in the 'guest data' sub-tab.<br>> > ><br>> <br>> > AFAIU this info does not come from the guest it is info we retrieve from<br>> > libvirt.<br>> > The VmGuestAgentInterface should be used only for information reported<br>> > by the guest, information whose credibility can be questioned.<br>> <br>> > >><br>> > >>> Editing a VNIC / Changing a VNIC profile<br>> > >>><br>> > >>> Changing the profile a VM is using while the VM is running should<br>> > >>> behave like dynamic wiring (changing the VM network while it is<br>> > >>> running).<br>> > >>> Hot-plug of a vnic will will use will use the updated profile connected<br>> > >>> to the VNIC.<br>> > >>><br>> > >><br>> > >> Not sure I fully understand the sentence above.<br>> > >> Hot plug will be fully supported, you can choose any profile (you have<br>> > >> permissions on) while plugging a new device.<br>> > >><br>> > ><br>> > > That was the intention. seems like an edgy hand syndrome :)<br>> > > Changed to:<br>> > > * Hot plug will be fully supported: the user can choose any permitted<br>> > > profile while plugging a new device or when activating an existing one.<br>> > ><br>> > >>> Adding a Network<br>> > >>><br>> > >>> When adding a network, a user can provide an option to create a vNic<br>> > >>> Profile for it.<br>> > >>><br>> > >>> Question: Is it s default profile ? what are its properties ?<br>> > >>> Question: What about 'Public Use' option ? Are they still relevant in<br>> > >>> the<br>> > >>> context of adding new networks or we should eliminate them and move it<br>> > >>> only to 'Add vNic Profile' dialog?<br>> > >>><br>> > >><br>> > >> see previous comments<br>> > >> In addition when creating a profile we should have 'Allow all' for<br>> > >> implicitly creating permissions, like we have today for network.<br>> > >><br>> > >>> Updating a Network<br>> > >>><br>> > >>> When a network role is modified to be a 'non-VM network', all vNic<br>> > >>> profiles<br>> > >>> associated with it should be deleted.<br>> > >><br>> > >> And permissions associated with these profiles<br>> > >><br>> > >>> Removing a Network<br>> > >>><br>> > >>> Should remove all profiles on that network<br>> > >>><br>> > >><br>> > >> And associated permissions<br>> > >><br>> > >>> Adding an Empty Data-Center<br>> > >>><br>> > >>> Currently, When creating a new Data-Center, the management network is<br>> > >>> automatically created.<br>> > >>> From 3.3, a default vNic profile will be created for the management<br>> > >>> network.<br>> > >>><br>> > >>> VM snapshot/import/export<br>> > >>><br>> > >>> We should handle VMs that are pointing to a network directly for<br>> > >>> backward compatibility.<br>> > >>> We need to select first profile that is on that network that the user<br>> > >>> has permissions on.<br>> > >>><br>> > >>> Question: Do we wish to support it export from 3.3 and import to 3.2 or<br>> > >>> below?<br>> > >><br>> > >> That means that when you write a VM in the OVF you need to write network<br>> > >> in addition to profile.<br>> > >><br>> > ><br>> > > The network name is already there, so when importing a vnic from 3.3 to<br>> > > an<br>> > > earlier version<br>> > > the profile name will be ignored.<br>> > ><br>> > >><br>> > >>> Question: A user can import/export a VM/Template even if he doesn't<br>> > >>> have<br>> > >>> permissions on the networks. Is the next flow valid ?<br>> > >>><br>> > >>> The profile name should be saved in the OVF (in addition to the network<br>> > >>> name which is saved today).<br>> > >>> During import, if both (network name, profile name) exist on the target<br>> > >>> DC, the vnic will get the profile id.<br>> > >>> If the network exists in the Data-Center, but has no profile as<br>> > >>> specified in the OVF, the user will be notified (event log) and the<br>> > >>> VNIC will be connected to a default minimal profile defined in the<br>> > >>> system, regardless the permissions the user has on the network.<br>> > >>><br>> > >><br>> > >> What is a 'default minimal profile' ? I would rather have a VNIC with no<br>> > >> profile associated with it.<br>> > ><br>> > > The 'default minimal profile' refers to a vnic profile with the lower<br>> > > average bandwidth.<br>> > ><br>> > > With the approach you've suggested, any imported VM/Template from an<br>> > > earlier to 3.3 version<br>> > > will require a manual intervention in order to configure a network to the<br>> > > VM.<br>> <br>> > I should have elaborated some more -<br>> <br>> > If a VM has a profile then we should look up this specific profile, if<br>> > such a profile does not exists then import the VM with profile none like<br>> > we do today for VM's with reference to a network that does not exist on<br>> > the setup.<br>> <br>> > If a VM does not have a profile (3.2 and lower versions) we should look<br>> > into the network name, if this network exist and we have a profile with<br>> > permissions to the user then use this profile (if there is more than one<br>> > choose one randomly).<br>> <br>> > > And for 3.1 we'll have to drop such vnics since network 'none' isn't<br>> > > supported.<br>> > ><br>> > >><br>> > >>> If failed to find any matching vNic profile, the vnic's profile will be<br>> > >>> set<br>> > >>> with 'none'.<br>> > >>><br>> > >>> When a Template is created from a VM the VNIC Profile will be kept<br>> > >>> along with the VNIC. When a VM is created from template the VNIC<br>> > >>> Profiles will be taken from the template's VNICs.<br>> > >>><br>> > >>> ----- Original Message -----<br>> > >>>> From: "Livnat Peer" <lpeer@redhat.com><br>> > >>>> To: "engine-devel" <engine-devel@ovirt.org>, "Ofri Masad"<br>> > >>>> <omasad@redhat.com><br>> > >>>> Cc: "Mike Kolesnik" <mkolesni@redhat.com>, "Moti Asayag"<br>> > >>>> <masayag@redhat.com>, "Oved Ourfalli" <oourfali@redhat.com><br>> > >>>> Sent: Sunday, June 30, 2013 3:59:37 PM<br>> > >>>> Subject: VNIC profiles<br>> > >>>><br>> > >>>> Hi,<br>> > >>>><br>> > >>>> We are working on adding VNIC profiles as part of the work to add VNIC<br>> > >>>> QoS.<br>> > >>>><br>> > >>>> http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles<br>> > >>>><br>> > >>>> We need to define some of the system behavior followed by this change,<br>> > >>>> here is my take -<br>> > >>>><br>> > >>>> Editing a profile -<br>> > >>>> --------------------<br>> > >>>> A user should be able to edit the profile properties (including<br>> > >>>> profile<br>> > >>>> name) while VMs are attached and are using this Profile (reference<br>> > >>>> should be done by id).<br>> > >>>><br>> > >>>> Changing the network though is a bit more tricky as long as we don't<br>> > >>>> have a way to distinguish between running and current configurations I<br>> > >>>> think it could be very confusing to the user. Especially since we<br>> > >>>> support dynamic wiring so the behavior IMO is unpredictable.<br>> > >>>> I think it should be blocked at this point.<br>> > >>>><br>> > >>>><br>> > >>>> Edit a VNIC / change a VNIC profile -<br>> > >>>> ------------------------------------<br>> > >>>> Changing the profile a VM is using while the VM is running should<br>> > >>>> behave<br>> > >>>> like dynamic wiring (changing the VM network while it is running).<br>> > >>>><br>> > >>>><br>> > >>>> Remove a Profile -<br>> > >>>> -------------------<br>> > >>>> Is only valid if all VMs that are using this profile are in status<br>> > >>>> down.<br>> > >>>> It should update all VMs to point to no profile which should behave<br>> > >>>> like<br>> > >>>> none network today.<br>> > >>>><br>> > >>>> I see no reason to support a profile on a none network at this point.<br>> > >>>><br>> > >>>> The above is also relevant for upgrade flow (upgrading none network to<br>> > >>>> point to no profile)<br>> > >>>><br>> > >>>><br>> > >>>> Removing a Network -<br>> > >>>> ----------------------<br>> > >>>> should remove all profiles on that network<br>> > >>>><br>> > >>>><br>> > >>>> VM snapshot/import/export -<br>> > >>>> --------------------------<br>> > >>>> We should handle VMs that are pointing to a network directly for b/w<br>> > >>>> compatibility.<br>> > >>>> we need to select first profile that is on that network that the user<br>> > >>>> has permissions on.<br>> > >>>><br>> > >>>><br>> > >>>> I assume there are more, comments are welcome<br>> > >>>><br>> > >>>> Thanks, Livnat<br>> > >>>><br>> > >>>><br>> > >><br>> > >><br>> <br></blockquote><div><br></div></div></body></html>