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.
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 ?
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.
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?
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.
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 ?
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).
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.
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?
Updating a Network
When a network role is modified to be a 'non-VM network', all vNic profiles
associated with it should be deleted.
Removing a Network
Should remove all profiles on that network
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?
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.
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
