[Engine-devel] VNIC profiles
Moti Asayag
masayag at redhat.com
Mon Jul 8 08:21:21 UTC 2013
----- 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: 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.
>
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" <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
> >>>>
> >>>>
> >>
> >>
>
>
More information about the Engine-devel
mailing list