On 07/07/2013 01:59 PM, Moti Asayag wrote:
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
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
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
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
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
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).
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
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
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.
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
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
From 3.3, a default vNic profile will be created for the management network.
We should handle VMs that are pointing to a network directly for backward
We need to select first profile that is on that network that the user has permissions
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.
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
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.
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
----- Original Message -----
> From: "Livnat Peer" <lpeer(a)redhat.com>
> To: "engine-devel" <engine-devel(a)ovirt.org>, "Ofri Masad"
> Cc: "Mike Kolesnik" <mkolesni(a)redhat.com>, "Moti Asayag"
<masayag(a)redhat.com>, "Oved Ourfalli" <oourfali(a)redhat.com>
> Sent: Sunday, June 30, 2013 3:59:37 PM
> Subject: VNIC profiles
> We are working on adding VNIC profiles as part of the work to add VNIC QoS.
> 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
> 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