Hi Moti, Thanks for the quick response,
Please look down at the comment. Amihay ----- Original Message ----- > From: "Moti Asayag" <masa...@redhat.com> > To: "Amihay Winter" <awin...@redhat.com> > Cc: engine-devel@ovirt.org, "Livnat Peer" <lp...@redhat.com> > Sent: Sunday, July 28, 2013 3:33:27 PM > Subject: Re: VNIC profiles & Device Custom Properties > Hi Amihay, > Thank you for your inputs on the feature. See answers in-line for each of the > raised issues. > ----- Original Message ----- > > From: "Amihay Winter" <awin...@redhat.com> > > To: engine-devel@ovirt.org > > Cc: "Moti Asayag" <masa...@redhat.com>, "Livnat Peer" <lp...@redhat.com> > > Sent: Tuesday, July 23, 2013 3:12:45 PM > > Subject: VNIC profiles & Device Custom Properties > > > > Hi all, > > > > I'm building a TCMS plan for the Device Custom Properties feature and I > > came > > across some questions. > > I'm sorry that I'm a little late with my thoughts but I hope you'll still > > hear them out. > > Also, I know It's a little long but please bear with me :) > > > > I want to talk about two things: > > 1. Sending an updateDevice verb whenever clicking on "Edit" and than "OK". > > 2. Setting Port Mirroring at the configuring of a nic and not at the > > profile. > > > > 1.According to the Vnic_Profiles's wiki (in the Editing a profile section) > > it > > says: > > "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." > > I'll describe a Scenario: > > Creating profile A with property speed = 500 > > Setting vnic2 on vm to have profile A (using Hotplugnic) > > Changing (in the profile) speed = 700 > > According to the Vnic_Profiles's wiki, only when I restart my vm I'll get > > my > > setting right. > > In my opinion, If we could enable the update of those setting LIVE we will > > give the clients a better solution in the Vnic Profiles. > > I will be able to update all of my 1000 vms in a few minutes with a single > > script instead of restarting them all and maybe stopping others' work. > > I think that restarting 1000 vms because I want to set a property is not > > something that an admin would want to do. > > One way to implement it is to send a verb "updateDevice" each time we open > > the the "Edit" window and clicking "OK" > > I guess that when the design of update device was made, we tried to send > > minimal verbs, but in this case, I think that if a user clicked on "Edit" & > > "OK" then he wanted to send the verb, otherwise, he would have pressed on > > "Edit" & "Cancel". > > > > Sending this verb will allow us to keep the vms update with, in my opinion, > > minimum cost and with great profit - Giving the client a "more correct > > environment" LIVE. > The engine-vdsm has a verb for updating a device. It is sent when the engine > detect a change in the state of the vnic which requires updating the device. > However, the engine doesn't store the vnic profile definition used to > activate > the vnic. > Instead of restarting the VM, the user can plug-unplug the specific device, > if > it already activated. I know that plug/unplug the specific device will propagate the change but why use only the hotplug & hotunplug verbs? why not using the updateDevice verb as well? Isn't LIVE (without losing connectivity to vm (because the hotunplug)) is better? > > > > 2. I'll start with saying that in my opinion, the Vnic Profile feature was > > created to give the client a *more dynamic network environment* and I > > support. > > But, I think that the statical variables like MAC, Un/Pluged and Port > > Mirroring which always exist should be at the nic and not in the profile. > > In my opinion, Profile's properties may have: max_mtu, min_mtu, mtu, speed, > > id, vlan... Identifiers for the network. > > Maybe I'm missing something but it seems natural to me that the port > > mirroring will be at nic and not at the profile. > > > I'm not sure how port mirroring is commonly used to enable it on vnic level. > Having the port mirroring on vnic profile level allows to control the network > usage in a concentrated place. > In both cases, we're a bit late on schedule, therefore changes would be done > later on if required. > > I'll really appreciate comments. > > Thank you for your time. > > Amihay Winter > > > > ----- Original Message ----- > > > > > ----- Forwarded Message ----- > > > From: "Livnat Peer" <lp...@redhat.com> > > > To: "Moti Asayag" <masa...@redhat.com> > > > Cc: "engine-devel" <engine-devel@ovirt.org>, "Ofri Masad" > > > <oma...@redhat.com>, "Mike Kolesnik" <mkole...@redhat.com>, "Oved > > > Ourfalli" > > > <oourf...@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" <lp...@redhat.com> > > > >> To: "Moti Asayag" <masa...@redhat.com> > > > >> Cc: "engine-devel" <engine-devel@ovirt.org>, "Ofri Masad" > > > >> <oma...@redhat.com>, "Mike Kolesnik" <mkole...@redhat.com>, > > > >> "Oved Ourfalli" <oourf...@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" <lp...@redhat.com> > > > >>>> To: "engine-devel" <engine-devel@ovirt.org>, "Ofri Masad" > > > >>>> <oma...@redhat.com> > > > >>>> Cc: "Mike Kolesnik" <mkole...@redhat.com>, "Moti Asayag" > > > >>>> <masa...@redhat.com>, "Oved Ourfalli" <oourf...@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 > > > >>>> > > > >>>> > > > >> > > > >> > >
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
