[Engine-devel] VNIC profiles & Device Custom Properties

[Amihay Winter]

Hi Moti, 

Thanks for the quick response, 

Please look down at the comment. 

Amihay 
----- Original Message -----

> From: "Moti Asayag" <masayag at redhat.com>
> To: "Amihay Winter" <awinter at redhat.com>
> Cc: engine-devel at ovirt.org, "Livnat Peer" <lpeer at 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" <awinter at redhat.com>
> > To: engine-devel at ovirt.org
> > Cc: "Moti Asayag" <masayag at redhat.com>, "Livnat Peer" <lpeer at 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" <lpeer at redhat.com>
> > > To: "Moti Asayag" <masayag at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>, "Ofri Masad"
> > > <omasad at redhat.com>, "Mike Kolesnik" <mkolesni at redhat.com>, "Oved
> > > Ourfalli"
> > > <oourfali at 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 at redhat.com>
> > > >> To: "Moti Asayag" <masayag at redhat.com>
> > > >> Cc: "engine-devel" <engine-devel at ovirt.org>, "Ofri Masad"
> > > >> <omasad at redhat.com>, "Mike Kolesnik" <mkolesni at redhat.com>,
> > > >> "Oved Ourfalli" <oourfali at 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 at redhat.com>
> > > >>>> To: "engine-devel" <engine-devel at ovirt.org>, "Ofri Masad"
> > > >>>> <omasad at redhat.com>
> > > >>>> Cc: "Mike Kolesnik" <mkolesni at redhat.com>, "Moti Asayag"
> > > >>>> <masayag at redhat.com>, "Oved Ourfalli" <oourfali at 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
> > > >>>>
> > > >>>>
> > > >>
> > > >>
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130729/21e622b1/attachment.html>