[Engine-devel] VNIC profiles & Device Custom Properties

Mon Jul 29 14:07:34 UTC 2013

----- Original Message -----
> From: "Amihay Winter" <awinter at redhat.com>
> To: "Moti Asayag" <masayag at redhat.com>
> Cc: engine-devel at ovirt.org, "Livnat Peer" <lpeer at redhat.com>
> Sent: Monday, July 29, 2013 4:57:44 PM
> Subject: Re: VNIC profiles & Device Custom Properties
> 
> 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?

I agree updating the device is a proper way of doing it, however we do not
maintain the vnic profile configuration used to run the VM.
Basically, the vnic profile contains network name (not modifiable), port 
mirroring (not modifiable if the profile is used by vms) and custom properties
which are only relevant when the vm is being started or when a device is plugged.
We may reconsider it once the vnic profile is integrated with the QoS, than
we should be able to compare the actual (running) qos settings against the
qos of the vnic profile and upon discrepancy to issue an update device. 

> 
> > >
> > > 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
> > > > >>>>
> > > > >>>>
> > > > >>
> > > > >>
> > >
> 