----- 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: 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. >
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" <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