10:12 p.m.
------=_Part_11407198_1454246753.1374581565910
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
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.
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'll really appreciate comments.
Thank you for your time.
Amihay Winter
----- Original Message -----
----- Forwarded Message -----
From: "Livnat Peer" <lpeer(a)redhat.com>
To: "Moti Asayag" <masayag(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Ofri Masad"
<omasad(a)redhat.com>, "Mike Kolesnik" <mkolesni(a)redhat.com>,
"Oved Ourfalli"
<oourfali(a)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(a)redhat.com>
>> To: "Moti Asayag" <masayag(a)redhat.com>
>> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Ofri
Masad"
>> <omasad(a)redhat.com>, "Mike Kolesnik"
<mkolesni(a)redhat.com>,
>> "Oved Ourfalli" <oourfali(a)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(a)redhat.com>
>>>> To: "engine-devel" <engine-devel(a)ovirt.org>, "Ofri
Masad"
>>>> <omasad(a)redhat.com>
>>>> 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
>>>>
>>>> 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
>>>>
>>>>
>>
>>
------=_Part_11407198_1454246753.1374581565910
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><body><div style=3D"font-family: times new roman, new york,
times, se=
rif; font-size: 12pt; color:
#000000"><div><br></div><div>Hi
all,<br></div>=
<div><br></div><div>I'm building a TCMS plan for the <span
dir=3D"auto">Dev=
ice Custom Properties feature and I came across some
questions.</span><br><=
/div><div>I'm sorry that I'm a little late with my thoughts but I hope
you'=
ll still hear them out.<br></div><div>Also, I know It's a little
long but p=
lease bear with me
:)<br></div><div><div><br></div><div>I want to
talk abou=
t two things:<br></div><div>1. Sending an updateDevice verb whenever
clicki=
ng on "Edit" and than "OK".<br></div><div>2. Setting
Port Mirroring at the =
configuring of a nic and not at the
profile.<br></div><div><br></div><div>1=
.According to the Vnic_Profiles's wiki (in the Editing a profile section) i=
t says:</div><div> "The changes
will seep down to =
all VNICs using the profile.</div><div>
 =
; In case VNIC using the edited profile are connected to running VMs, =
the change will apply only on the VM next
run."<br></div><div> &=
nbsp; I'll describe a
Scenario:</div><div> &nb=
sp; Creating profile A with property speed =3D 500
<br></div><div> &nb=
sp; Setting vnic2 on vm to have profile A (using
Ho=
tplugnic)</div><div>
Changing (in the profil=
e) speed =3D 700</div><div> According to the
Vnic_Profile=
s's wiki, only when I restart my vm I'll get my setting
right.</div><div>&n=
bsp; In my opinion, If we could enable the update of those sett=
ing LIVE we will give the clients a better solution in the Vnic Profiles.<b=
r></div><div> 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 m=
aybe stopping others'
work.<br></div><div> I think that r=
estarting 1000 vms because I want to set a property is not something that a=
n admin would want to
do.<br></div><div>  =
; </div><div> One way to
implement it is to se=
nd a verb "updateDevice" each time we open the the "Edit" window and
clicki=
ng "OK"</div><div> 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 ver=
b, otherwise, he would have pressed on "Edit" &
"Cancel".</div><div><br=
</div><div> 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.</div><div><br></div><d=
iv>2. I'll start with saying that in my opinion, the Vnic Profile feature w=
as created to give the client a *more dynamic network environment* and I su=
pport.</div><div> But, I think that the
statical var=
iables like MAC, Un/Pluged and Port Mirroring which always exist should be =
at the nic and not in the profile.</div><div> In
my opini=
on, Profile's properties may have: max_mtu, min_mtu, mtu, speed, id, vlan..=
. Identifiers for the network.</div><div> Maybe
I'm missi=
ng something but it seems natural to me that the port mirroring will be at =
nic and not at the
profile.</div><div><br></div><div><br></div><div><span
i=
d=3D"result_box" class=3D"short_text"
lang=3D"en"><span class=3D"hps alt-ed=
ited">I'll really appreciate
comments.</span></span></div><div><span id=3D"=
result_box" class=3D"short_text" lang=3D"en"><span
class=3D"hps alt-edited"=
Thank you for your
time.</span></span></div><div>Amihay
Winter<br> &n=
bsp;  =
; </div><br></div><hr
id=3D"zwchr"><blockquote style=3D"border-left:2p=
x solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:nor=
mal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans=
-serif;font-size:12pt;">----- Forwarded Message -----<br>From: "Livnat
Peer=
" &lt;lpeer(a)redhat.com&gt;<br>To: "Moti Asayag"
&lt;masayag(a)redhat.com&gt;<=
br>Cc: "engine-devel" &lt;engine-devel(a)ovirt.org&gt;, "Ofri
Masad" <omas=
ad(a)redhat.com&gt;, "Mike Kolesnik" &lt;mkolesni(a)redhat.com&gt;,
"Oved Ourfa=
lli" &lt;oourfali(a)redhat.com&gt;<br>Sent: Monday, July 8, 2013 10:11:15
AM<=
br>Subject: Re: VNIC profiles<br><div><br></div>On 07/08/2013
12:36 AM, Mot=
i Asayag wrote:<br>> I've updated the wiki accordingly and added few
com=
ments inline.<br>> <br>> ----- Original Message
-----<br>>> Fro=
m: "Livnat Peer" &lt;lpeer(a)redhat.com&gt;<br>&gt;&gt; To:
"Moti Asayag" <=
;masayag(a)redhat.com&gt;<br>&gt;&gt; Cc: "engine-devel"
<engine-devel@ovi=
rt.org>, "Ofri Masad" &lt;omasad(a)redhat.com&gt;, "Mike
Kolesnik" <mko=
lesni(a)redhat.com&gt;,<br>&gt;&gt; "Oved Ourfalli"
&lt;oourfali(a)redhat.com&g=
t;<br>>> Sent: Sunday, July 7, 2013 2:59:34
PM<br>>> Subject: R=
e: VNIC profiles<br>>><br>>> On 07/07/2013 01:59
PM, Moti Asaya=
g wrote:<br>>>>
Hi,<br>>>><br>>>> I've updated
t=
he wiki with the feedbacks from this thread, added a
backend<br>>>>=
; section naming the affected commands and also add added few questions of<=
br>>>> my own embedded in the pastedtext
below.<br>>>><br=
>><br>>> Hi
Moti,<br>>> A good and comprehensive descrip=
tion of the
feature behavior.<br>>> See my comments bellow
-<br>>&=
gt;<br>>>> In addition, another question
here:<br>>>><br>=
>>> The units within the UI mockups are Mb and Mbps. The libvirt A=
PIs expects<br>>>> the units to be in kb and kbps. Which
component=
is responsible to convert<br>>>> them to the expect units ?
engin=
e or VDSM ?<br>>><br>>> Giuseppe mentioned that in
a previous t=
hread on this subject.<br>>> Ofri and Giuseppe agreed that the
transl=
ation would be done on the<br>>> engine
level.<br>>><br>>>=
;<br>>>><br>>>> Copied text from the
wiki:<br>>>>=
;<br>>>> Adding a
Profile<br>>>><br>>>> The netw=
ork administrator could create several VNIC Profiles for
each<br>>>&g=
t; network. He could then grant a users with the permission to use (consume=
)<br>>>> each profile. The user will only be able to use
profiles =
which he was<br>>>> granted access
to.<br>>>><br>>>=
> For example: the network admin will create two VNIC prof=
iles for<br>>>> network
"blue":<br>>>><br>&=
gt;>> Profile "Gold" -
with better QoS an=
d with port mirroring<br>>>>
Profile "=
Silver" with lower QoS and without port
mirroring.<br>>>><br>>&=
gt;<br>>> I would use other names for the profiles to avoid
confusion=
.<br>>> Gold and Silver are likely to be QoS object names, a
mo=
re typical name<br>>> for a network profile is - teachers-blue and
st=
udents-blue<br>>><br>>> The different profiles can
have differe=
nt QoS (teachers-blue would get<br>>> Gold QoS while Students-blue
wi=
ll have
Silver).<br>>><br>>><br>>>>
He w=
ill then define the user-group "students" as user of
profile<br>>>>=
; "Silver" and user-group "teachers" as user of
profile "Gold=
". In this<br>>>> case the teachers
will enjoy bette=
r quality of service then the<br>>>>
students. When =
a teacher will add/edit a virtual NIC he could select<br>>>>
 =
; profile "Gold" for that NIC - the VNIC will be connected to
networ=
k<br>>>> "blue" with high QoS
and with port mirrorin=
g.<br>>>><br>>>> Question: In the
same matter we allowed =
via the UI to grant 'NetworkUser'<br>>>> to
'everyone' user, would=
n't it ease the use of Profiles if we support it<br>>>> in
this co=
ntext as well?<br>>><br>>> The ease of use could
be that when c=
reating a network we'll display in<br>>> the UI all
VNIC-QoS-objects =
and the users could tick next to the QoS<br>>> they are interested
in=
, for each QoS that was chosen a profile would be<br>>>
created.<br>&=
gt;><br>>> I would enhance that with youe suggestion above and
dis=
play next to the<br>>> QoS that was checked the option to mark
'Allow=
All users' like we have<br>>> today for making a network public,
thi=
s option would give permission to<br>>> everyone on that
profile.<br>=
>><br>>><br>>>><br>>>>
Editing a Profile<br>&=
gt;>><br>>>> A user should
be able to edit the=
profile properties (including profile<br>>>>
name) =
while VMs are attached and are using this Profile
(reference<br>>>>=
; should be done by id).<br>>>>
Changi=
ng the network of a vNic profile will be allowed only if no
VMs<br>>>=
> are using the
profile.<br>>><br>>> It would =
be better if we can limit this to no running VM is using the<br>>>
pr=
ofile (or more simple to implement if all VMs that are using
this<br>>&g=
t; profile are in status down).<br>> <br>> Allowing to delete a
vnic =
profile when used by vms is asymmetric to the network removal<br>> when =
it is used by vms or templates. Today the update network operation is block=
ed for that.<br>> In addition, with the suggest simplification to remove=
a profile when no running vms, the user<br>> will have to find for hims=
elf if the profile is being used prior to its removal since the <br>> op=
eration will not be blocked.<br>> <br>> If we allow to delete a
vnic =
profile, when a vm is using it (regardless the VM status) <br>> we'll
ha=
ve to update the VM entity as well in that operation: since we do not suppo=
rt a<br>> network with 'none' profile, we'll have to delete the
network =
as well.<br>> <br>> If we'll remove a vnic profile in 3.1
cluster, us=
ed by vms in status down, we'd find a case <br>> in which a VM is
attach=
ed to a 'none' network. This is unsupported in 3.1 cluster. We can block<br=
> such operation, but this is another motivation why we'd
better not to=
allow removing a used profile.<br>>
<br><div><br></div>The context abov=
e is about editing not deleting :)<br>I agree with what you wrote if the co=
ntext was
remove.<br><div><br></div>>><br>>>>
=
Since we have no way to distinguish between running and curre=
nt<br>>>>
configurations, the expected=
behavior of such a change is<br>>>>
u=
npredictable and less intuitive to the user (especially
since<br>>>&g=
t; dynamic wiring is
supported).<br>>>>=
; The changes will seep down to all VNICs using the profile.<=
br>>>> In case VNIC
using the edited p=
rofile are connected to running VMs,<br>>>>
&=
nbsp; the change will apply only on the VM next
run.<br>>>><br>>=
;>> Question: What about Hibernate/Suspend VM ? will the resume VM ac=
tion uses<br>>>> the original configuration for the vnics when
the=
VM was started ?<br>>><br>>> Currently profile
includes: netwo=
rk, port-mirroring, custom property,
QoS<br>>><br>>> Changing a=
ny of the above (except for network) requires a VM reboot, so<br>>>
I=
think that we can start with the following statement - the profile<br>>=
> change would only apply after next VM
reboot.<br>>><br>>> =
There are 2 problems with the above:<br>>> - Today we support
network=
wiring, with VNIC profiles we are asking the<br>>> users to create
a=
new profile and attach the VMs to the new profile, I<br>>> can see
t=
he RFE coming - we can report that ourselves
;)<br>>><br>>> - W=
e don't reflect with which configuration the VM is running, e.g
we<br>>&=
gt; edited the profile QoS but I'm not sure with which QoS the VM
is<br>>=
;> currently running. (The RFE for differentiating between
current<br>&g=
t;> configuration and running configuration was already asked for by<br>=
>> numerous users)<br>>><br>>> The
above is a general iss=
ue that we need to solve and I would not limit<br>>> editing VNIC
pro=
files because of it.<br>>> We can mitigate this specifically for QoS
=
like described
bellow.<br>>><br>>><br>>><br>>>>
=
Deleting a Profile<br>>>><br>>>>
VNIC Profiles could not =
be deleted from the engine as long as one or more<br>>>>
VM/Templa=
tes are using those profiles.<br>>><br>>>>
Reporting vNic ac=
tual configuration<br>>>><br>>>>
The engine=
will retrieve the actual configuration of the profile<br>>>>
&nbs=
p; properties on the VNIC from VDSM (using the network statistics<br=
>>> mechanism) and the
networked administrator will=
be presented with
the<br>>>> state of each VNIC (sy=
nched/unsynched).<br>>>><br>>><br>>>
Will the admin be=
able to see the actual values? I think the synced<br>>> property is
=
not enough (I'm not sure how interesting this property is to<br>>>
st=
art with).<br>> <br>> We can extend the VmGuestAgentInterface to
cont=
ain the actual value, so they<br>> will be presented for each vnic in th=
e 'guest data' sub-tab.<br>>
<br><div><br></div>AFAIU this info does not=
come from the guest it is info we retrieve from<br>libvirt.<br>The VmGuest=
AgentInterface should be used only for information reported<br>by the guest=
, information whose credibility can be
questioned.<br><div><br></div><br>&g=
t;><br>>>> Editing a VNIC / Changing a VNIC
profile<br>>>=
><br>>>> Changing the profile a VM
is using while=
the VM is running should<br>>>> behave
like dynamic=
wiring (changing the VM network while it is<br>>>>
=
running).<br>>>> Hot-plug of a vnic will
will use wi=
ll use the updated profile connected<br>>>>
to the V=
NIC.<br>>>><br>>><br>>>
Not sure I fully understand th=
e sentence above.<br>>> Hot plug will be fully supported, you can
cho=
ose any profile (you have<br>>> permissions on) while plugging a new
=
device.<br>>><br>> <br>> That was the
intention. seems like an =
edgy hand syndrome :)<br>> Changed to:<br>> * Hot plug
will be =
fully supported: the user can choose any permitted profile while plugging a=
new device or when activating an existing one.<br>>
<br>>>> Ad=
ding a Network<br>>>><br>>>>
When adding a =
network, a user can provide an option to create a vNic<br>>>>
&nbs=
p; Profile for
it.<br>>>><br>>>> Question: Is it
s=
default profile ? what are its properties ?<br>>>> Question:
What=
about 'Public Use' option ? Are they still relevant in
the<br>>>>=
context of adding new networks or we should eliminate them and move it<br>=
>>> only to 'Add vNic Profile'
dialog?<br>>>><br>>>=
<br>>> see previous comments<br>>> In addition
when creating a =
profile we should have 'Allow all' for<br>>> implicitly
creating perm=
issions, like we have today for
network.<br>>><br>>>> Updati=
ng a Network<br>>>><br>>>> When a
network role is modifie=
d to be a 'non-VM network', all vNic profiles<br>>>>
associated wi=
th it should be deleted.<br>>><br>>> And
permissions associated=
with these profiles<br>>><br>>>> Removing
a Network<br>>=
>><br>>>> Should remove all
profiles on that n=
etwork<br>>>><br>>><br>>>
And associated permissions<b=
r>>><br>>>> Adding an Empty
Data-Center<br>>>><br>&=
gt;>> Currently, When creating a new Data-Center, the
m=
anagement network is<br>>>> automatically
created.<b=
r>>>> From 3.3, a default vNic profile will
be creat=
ed for the management<br>>>>
network.<br>>>>=
;<br>>>> VM
snapshot/import/export<br>>>><br>>>>=
We should handle VMs that are pointing to a network directly=
for<br>>>> backward
compatibility.<br>>>> =
We need to select first profile that is on that network that =
the user<br>>>> has permissions
on.<br>>>><=
br>>>> Question: Do we wish to support it export from 3.3 and
impo=
rt to 3.2 or<br>>>>
below?<br>>><br>>> That means that=
when you write a VM in the OVF you need to write network<br>>> in
ad=
dition to profile.<br>>><br>> <br>> The
network name is already=
there, so when importing a vnic from 3.3 to an earlier version<br>> the=
profile name will be ignored.<br>>
<br>>><br>>>> Questio=
n: A user can import/export a VM/Template even if he doesn't
have<br>>&g=
t;> permissions on the networks. Is the next flow valid
?<br>>>>=
;<br>>>> The profile name should be saved
in the OVF=
(in addition to the network<br>>>> name
which is sa=
ved today).<br>>>> During import, if both
(network n=
ame, profile name) exist on the target<br>>>>
DC, th=
e vnic will get the profile id.<br>>>> If
the networ=
k exists in the Data-Center, but has no profile as<br>>>>
&=
nbsp; specified in the OVF, the user will be notified (event log) and the<b=
r>>>> VNIC will be connected to a default
minimal pr=
ofile defined in the<br>>>> system,
regardless the p=
ermissions the user has on the
network.<br>>>><br>>><br>>=
> What is a 'default minimal profile' ? I would rather have a VNIC with =
no<br>>> profile associated with it.<br>>
<br>> The 'default mi=
nimal profile' refers to a vnic profile with the lower average bandwidth.<b=
r>> <br>> With the approach you've suggested, any imported
VM/Templat=
e from an earlier to 3.3 version <br>> will require a manual interventio=
n in order to configure a network to the VM.<br><div><br></div>I
should hav=
e elaborated some more -<br><div><br></div>If a VM has a profile
then we sh=
ould look up this specific profile, if<br>such a profile does not exists th=
en import the VM with profile none like<br>we do today for VM's with refere=
nce to a network that does not exist on<br>the
setup.<br><div><br></div>If =
a VM does not have a profile (3.2 and lower versions) we should look<br>int=
o the network name, if this network exist and we have a profile with<br>per=
missions to the user then use this profile (if there is more than one<br>ch=
oose one randomly).<br><div><br></div><br>> And for
3.1 we'll have to dr=
op such vnics since network 'none' isn't supported.<br>>
<br>>><br=
>>> If failed to find any matching vNic profile,
the vnic's profi=
le will be set<br>>>> with
'none'.<br>>>><br>>>>=
When a Template is created from a VM the VNIC Profile will b=
e kept<br>>>> along with the VNIC. When a
VM is crea=
ted from template the VNIC<br>>>>
Profiles will be t=
aken from the template's
VNICs.<br>>>><br>>>> ----- Origi=
nal Message -----<br>>>>> From: "Livnat Peer"
&lt;lpeer(a)redhat.=
com><br>>>>> To: "engine-devel"
&lt;engine-devel(a)ovirt.org&g=
t;, "Ofri Masad"<br>>>>>
&lt;omasad(a)redhat.com&gt;<br>&gt;&gt;&=
gt;> Cc: "Mike Kolesnik" &lt;mkolesni(a)redhat.com&gt;, "Moti
Asayag"<br>&=
gt;>>> &lt;masayag(a)redhat.com&gt;, "Oved Ourfalli"
<oourfali@re=
dhat.com><br>>>>> Sent: Sunday, June 30, 2013
3:59:37 PM<br>=
>>>> Subject: VNIC
profiles<br>>>>><br>>>>=
>
Hi,<br>>>>><br>>>>> We
are working on adding V=
NIC profiles as part of the work to add VNIC<br>>>>>
QoS.<br>&g=
t;>>><br>>>>>
http://www.ovirt.org/Features/Network_Qo=
S#VNIC_Profiles<br>>>>><br>>>>>
We need to define s=
ome of the system behavior followed by this
change,<br>>>>> her=
e is my take
-<br>>>>><br>>>>>
Editing a profile -<=
br>>>>>
--------------------<br>>>>> A user should =
be able to edit the profile properties (including
profile<br>>>>&g=
t; name) while VMs are attached and are using this Profile (reference<br>&g=
t;>>> should be done by
id).<br>>>>><br>>>>&g=
t; Changing the network though is a bit more tricky as long as we don't<br>=
>>>> have a way to distinguish between running and current
conf=
igurations I<br>>>>> think it could be very confusing to
the us=
er. Especially since we<br>>>>> support dynamic wiring
so the b=
ehavior IMO is unpredictable.<br>>>>> I think it should
be bloc=
ked at this
point.<br>>>>><br>>>>><br>>>>&=
gt; Edit a VNIC / change a VNIC profile -<br>>>>>
-------------=
-----------------------<br>>>>> Changing the profile a
VM is us=
ing while the VM is running should behave<br>>>>> like
dynamic =
wiring (changing the VM network while it is
running).<br>>>>><b=
r>>>>><br>>>>> Remove a
Profile -<br>>>>&g=
t; -------------------<br>>>>> Is only valid if all VMs
that ar=
e using this profile are in status down.<br>>>>> It
should upda=
te all VMs to point to no profile which should behave
like<br>>>>&=
gt; none network
today.<br>>>>><br>>>>>
I see no re=
ason to support a profile on a none network at this
point.<br>>>>&=
gt;<br>>>>> The above is also relevant for upgrade flow
(upgrad=
ing none network to<br>>>>> point to no
profile)<br>>>>=
;><br>>>>><br>>>>>
Removing a Network -<br>>&=
gt;>> ----------------------<br>>>>>
should remove all pr=
ofiles on that
network<br>>>>><br>>>>><br>>>&=
gt;> VM snapshot/import/export -<br>>>>>
-------------------=
-------<br>>>>> We should handle VMs that are pointing
to a net=
work directly for b/w<br>>>>>
compatibility.<br>>>>>=
; we need to select first profile that is on that network that the user<br>=
>>>> has permissions
on.<br>>>>><br>>>>>=
;<br>>>>> I assume there are more, comments are
welcome<br>>=
>>><br>>>>> Thanks,
Livnat<br>>>>><br>>=
>>><br>>><br>>><br><div><br></div></blockquote><div><b=
r></div></div></body></html>
------=_Part_11407198_1454246753.1374581565910--
10:33 p.m.
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(a)redhat.com>
To: engine-devel(a)ovirt.org
Cc: "Moti Asayag" <masayag(a)redhat.com>, "Livnat Peer"
<lpeer(a)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.
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(a)redhat.com>
> To: "Moti Asayag" <masayag(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Ofri Masad"
> <omasad(a)redhat.com>, "Mike Kolesnik" <mkolesni(a)redhat.com>,
"Oved Ourfalli"
> <oourfali(a)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(a)redhat.com>
> >> To: "Moti Asayag" <masayag(a)redhat.com>
> >> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Ofri
Masad"
> >> <omasad(a)redhat.com>, "Mike Kolesnik"
<mkolesni(a)redhat.com>,
> >> "Oved Ourfalli" <oourfali(a)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(a)redhat.com>
> >>>> To: "engine-devel" <engine-devel(a)ovirt.org>,
"Ofri Masad"
> >>>> <omasad(a)redhat.com>
> >>>> 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
> >>>>
> >>>> 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
> >>>>
> >>>>
> >>
> >>
11:57 p.m.
------=_Part_17897434_1769683215.1375106264138
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Hi Moti,
Thanks for the quick response,
Please look down at the comment.
Amihay
----- Original Message -----
From: "Moti Asayag" <masayag(a)redhat.com>
To: "Amihay Winter" <awinter(a)redhat.com>
Cc: engine-devel(a)ovirt.org, "Livnat Peer" <lpeer(a)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(a)redhat.com>
> To: engine-devel(a)ovirt.org
> Cc: "Moti Asayag" <masayag(a)redhat.com>, "Livnat Peer"
<lpeer(a)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(a)redhat.com>
> > To: "Moti Asayag" <masayag(a)redhat.com>
> > Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Ofri
Masad"
> > <omasad(a)redhat.com>, "Mike Kolesnik"
<mkolesni(a)redhat.com>, "Oved
> > Ourfalli"
> > <oourfali(a)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(a)redhat.com>
> > >> To: "Moti Asayag" <masayag(a)redhat.com>
> > >> Cc: "engine-devel" <engine-devel(a)ovirt.org>,
"Ofri Masad"
> > >> <omasad(a)redhat.com>, "Mike Kolesnik"
<mkolesni(a)redhat.com>,
> > >> "Oved Ourfalli" <oourfali(a)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(a)redhat.com>
> > >>>> To: "engine-devel" <engine-devel(a)ovirt.org>,
"Ofri Masad"
> > >>>> <omasad(a)redhat.com>
> > >>>> 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
> > >>>>
> > >>>> 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
> > >>>>
> > >>>>
> > >>
> > >>
>
------=_Part_17897434_1769683215.1375106264138
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><body><div style=3D"font-family: times new roman, new york,
times, se=
rif; font-size: 12pt; color: #000000"><div>Hi
Moti,<br></div><div><br></div=
<div>Thanks for the quick
response,<br></div><div><br></div><div>Please lo=
ok down at the
comment.<br></div><div><br></div><div><br></div><div>Amihay<=
br></div><hr id=3D"zwchr"><blockquote
style=3D"border-left:2px solid #1010F=
F;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style=
:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-si=
ze:12pt;"><b>From: </b>"Moti Asayag"
&lt;masayag(a)redhat.com&gt;<br><b>To: <=
/b>"Amihay Winter" &lt;awinter(a)redhat.com&gt;<br><b>Cc:
</b>engine-devel@ov=
irt.org, "Livnat Peer" &lt;lpeer(a)redhat.com&gt;<br><b>Sent:
</b>Sunday, Jul=
y 28, 2013 3:33:27 PM<br><b>Subject: </b>Re: VNIC profiles &
Device Cus=
tom Properties<br><div><br></div>Hi
Amihay,<br><div><br></div>Thank you for=
your inputs on the feature. See answers in-line for each of the raised iss=
ues.<br><div><br></div>----- Original Message
-----<br>> From: "Amihay W=
inter" &lt;awinter(a)redhat.com&gt;<br>&gt; To:
engine-devel(a)ovirt.org<br>&gt=
; Cc: "Moti Asayag" &lt;masayag(a)redhat.com&gt;, "Livnat Peer"
<lpeer@red=
hat.com><br>> Sent: Tuesday, July 23, 2013 3:12:45
PM<br>> Subject=
: VNIC profiles & Device Custom Properties<br>> <br>> Hi
all,<br>=
> <br>> I'm building a TCMS plan for the Device Custom Properties
fea=
ture and I came<br>> across some questions.<br>> I'm sorry
that I'm a=
little late with my thoughts but I hope you'll still<br>> hear them
out=
.<br>> Also, I know It's a little long but please bear with me
:)<br>>=
; <br>> I want to talk about two things:<br>> 1. Sending an
updateDev=
ice verb whenever clicking on "Edit" and than "OK".<br>>
2. Setting Port=
Mirroring at the configuring of a nic and not at the profile.<br>>
<br>=
> 1.According to the Vnic_Profiles's wiki (in the Editing a profile sect=
ion) it<br>> says:<br>> "The changes will seep down to all
VNICs usin=
g the profile.<br>> In case VNIC using the edited profile are connected =
to running VMs, the<br>> change will apply only on the VM next
run."<br>=
> I'll describe a Scenario:<br>> Creating profile A with property
spe=
ed =3D 500<br>> Setting vnic2 on vm to have profile A (using Hotplugnic)=
<br>> Changing (in the profile) speed =3D 700<br>> According to
the V=
nic_Profiles's wiki, only when I restart my vm I'll get my<br>>
setting =
right.<br>> In my opinion, If we could enable the update of those settin=
g LIVE we will<br>> give the clients a better solution in the Vnic Profi=
les.<br>> I will be able to update all of my 1000 vms in a few minutes w=
ith a single<br>> script instead of restarting them all and maybe stoppi=
ng others' work.<br>> I think that restarting 1000 vms because I want
to=
set a property is not<br>> something that an admin would want to do.<br=
> One way to implement it is to send a verb
"updateDevice" each time we=
open<br>> the the
"Edit" window and clicking "OK"<br>> I guess that =
when the design of update device was made, we tried to send<br>> minimal=
verbs, but in this case, I think that if a user clicked on "Edit"
&<br=
> "OK" then he wanted to send the verb, otherwise, he
would have presse=
d on<br>> "Edit" &
"Cancel".<br>> <br>> Sending this verb will=
allow us to keep the vms update with, in my opinion,<br>> minimum cost =
and with great profit - Giving the client a "more correct<br>>
environme=
nt" LIVE.<br><div><br></div>The engine-vdsm has a verb for
updating a devic=
e. It is sent when the engine<br>detect a change in the state of the vnic w=
hich requires updating the device.<br>However, the engine doesn't store the=
vnic profile definition used to activate<br>the
vnic.<br><div><br></div>In=
stead of restarting the VM, the user can plug-unplug the specific device, i=
f<br>it already
activated.</blockquote><div><br></div><div>I know that
plug=
/unplug the specific device will propagate the change but why use only the =
hotplug &<br></div><div>hotunplug verbs? why not using the
updateDevice=
verb as well?<br></div><div>Isn't LIVE (without losing connectivity
to vm =
(because the hotunplug)) is
better?<br></div><div><br></div><blockquote sty=
le=3D"border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:=
#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:=
Helvetica,Arial,sans-serif;font-size:12pt;"><div><br></div>>
<br>> 2.=
I'll start with saying that in my opinion, the Vnic Profile feature was<br=
> created to give the client a *more dynamic network
environment* and I=
<br>> support.<br>> But, I think that
the statical variables like MAC=
, Un/Pluged and Port<br>> Mirroring which always exist should be at the =
nic and not in the profile.<br>> In my opinion, Profile's properties
may=
have: max_mtu, min_mtu, mtu, speed,<br>> id, vlan... Identifiers for th=
e network.<br>> Maybe I'm missing something but it seems natural to me
t=
hat the port<br>> mirroring will be at nic and not at the
profile.<br>&g=
t; <br><div><br></div>I'm not sure how port mirroring is
commonly used to e=
nable it on vnic level.<br>Having the port mirroring on vnic profile level =
allows to control the network<br>usage in a concentrated
place.<br><div><br=
</div>In both cases, we're a bit late on schedule, therefore
changes would=
be done <br>later on if
required.<br><div><br></div>> I'll really appre=
ciate comments.<br>> Thank you for your time.<br>> Amihay
Winter<br>&=
gt; <br>> ----- Original Message -----<br>> <br>>
> ----- Forwa=
rded Message -----<br>> > From: "Livnat Peer"
&lt;lpeer(a)redhat.com&gt=
;<br>> > To: "Moti Asayag"
&lt;masayag(a)redhat.com&gt;<br>&gt; > Cc=
: "engine-devel" &lt;engine-devel(a)ovirt.org&gt;, "Ofri
Masad"<br>> > =
&lt;omasad(a)redhat.com&gt;, "Mike Kolesnik"
&lt;mkolesni(a)redhat.com&gt;, "Ov=
ed Ourfalli"<br>> >
&lt;oourfali(a)redhat.com&gt;<br>&gt; > Sent: Mo=
nday, July 8, 2013 10:11:15 AM<br>> > Subject: Re: VNIC
profiles<br>&=
gt; <br>> > On 07/08/2013 12:36 AM, Moti Asayag
wrote:<br>> > &=
gt; I've updated the wiki accordingly and added few comments
inline.<br>>=
; > ><br>> > > ----- Original Message
-----<br>> > >=
;> From: "Livnat Peer" &lt;lpeer(a)redhat.com&gt;<br>&gt;
> >> To=
: "Moti Asayag" &lt;masayag(a)redhat.com&gt;<br>&gt; >
>> Cc: "engin=
e-devel" &lt;engine-devel(a)ovirt.org&gt;, "Ofri
Masad"<br>> > >>=
&lt;omasad(a)redhat.com&gt;, "Mike Kolesnik"
&lt;mkolesni(a)redhat.com&gt;,<br=
> > >> "Oved Ourfalli"
&lt;oourfali(a)redhat.com&gt;<br>&gt; >=
; >>
Sent: Sunday, July 7, 2013 2:59:34 PM<br>> > >> Subj=
ect: Re: VNIC profiles<br>> > >><br>>
> >> On 07/07=
/2013 01:59 PM, Moti Asayag wrote:<br>> > >>>
Hi,<br>> &g=
t; >>><br>> > >>> I've
updated the wiki with the fe=
edbacks from this thread, added a<br>> > >>>
backend<br>>=
> >>> section naming the affected commands and also add added
=
few questions<br>> > >>> of<br>>
> >>> my own=
embedded in the pastedtext below.<br>> >
>>><br>> > &=
gt;><br>> > >> Hi Moti,<br>>
> >> A good and com=
prehensive description of the feature behavior.<br>> >
>> See m=
y comments bellow -<br>> > >><br>> >
>>> In addi=
tion, another question here:<br>> >
>>><br>> > >>=
;> The units within the UI mockups are Mb and Mbps. The libvirt APIs<br>=
> > >>> expects<br>> >
>>> the units to be in=
kb and kbps. Which component is responsible to<br>> >
>>> c=
onvert<br>> > >>> them to the expect units ?
engine or VDSM =
?<br>> > >><br>> > >>
Giuseppe mentioned that in a =
previous thread on this subject.<br>> > >> Ofri and
Giuseppe ag=
reed that the translation would be done on the<br>> > >>
engine=
level.<br>> > >><br>> >
>><br>> > >>&g=
t;<br>> > >>> Copied text from the
wiki:<br>> > >&g=
t;><br>> > >>> Adding a
Profile<br>> > >>>=
<br>> > >>> The network administrator could
create several V=
NIC Profiles for each<br>> > >>> network. He
could then gran=
t a users with the permission to use<br>> > >>>
(consume)<br=
> > >>> each profile. The user will
only be able to use pro=
files which he was<br>> >
>>> granted access to.<br>> >=
; >>><br>> > >>> For
example: the network admin wil=
l create two VNIC profiles for<br>> > >>> network
"blue":<br=
> > >>><br>> >
>>> Profile "Gold" - with bet=
ter QoS and with port
mirroring<br>> > >>> Profile "Silver"
=
with lower QoS and without port mirroring.<br>> >
>>><br>>=
; > >><br>> > >> I would use other
names for the profi=
les to avoid confusion.<br>> > >> Gold and Silver are
likely to=
be QoS object names, a more typical name<br>> > >> for
a netwo=
rk profile is - teachers-blue and students-blue<br>> >
>><br>&g=
t; > >> The different profiles can have different QoS (teachers-bl=
ue would get<br>> > >> Gold QoS while Students-blue will
have S=
ilver).<br>> > >><br>> >
>><br>> > >>&g=
t; He will then define the user-group "students" as user of
profile<br>>=
> >>> "Silver" and user-group "teachers"
as user of profile "G=
old". In this<br>> > >>> case the teachers
will enjoy better=
quality of service then the<br>> > >>> students.
When a tea=
cher will add/edit a virtual NIC he could select<br>> >
>>> =
profile "Gold" for that NIC - the VNIC will be connected to
network<br>>=
> >>> "blue" with high QoS and with port
mirroring.<br>> &g=
t; >>><br>> > >>> Question:
In the same matter we a=
llowed via the UI to grant<br>> > >>>
'NetworkUser'<br>> =
> >>> to 'everyone' user, wouldn't it ease the use
of Profiles =
if we support<br>> > >>> it<br>>
> >>> in thi=
s context as well?<br>> > >><br>> >
>> The ease of =
use could be that when creating a network we'll display in<br>> >
>=
;> the UI all VNIC-QoS-objects and the users could tick next to the QoS<=
br>> > >> they are interested in, for each QoS that was
chosen =
a profile would be<br>> > >> created.<br>>
> >><br>=
> > >> I would enhance that with youe suggestion above and
disp=
lay next to the<br>> > >> QoS that was checked the
option to ma=
rk 'Allow All users' like we have<br>> > >>
today for making a =
network public, this option would give permission to<br>> >
>> =
everyone on that profile.<br>> > >><br>>
> >><br>&g=
t; > >>><br>> > >>>
Editing a Profile<br>> &g=
t; >>><br>> > >>> A user
should be able to edit the=
profile properties (including profile<br>> > >>>
name) whil=
e VMs are attached and are using this Profile (reference<br>> >
>&=
gt;> should be done by id).<br>> > >>>
Changing the netwo=
rk of a vNic profile will be allowed only if no VMs<br>> >
>>&g=
t; are using the profile.<br>> > >><br>>
> >> It wo=
uld be better if we can limit this to no running VM is using the<br>>
&g=
t; >> profile (or more simple to implement if all VMs that are using =
this<br>> > >> profile are in status
down).<br>> > ><b=
r>> > > Allowing to delete a vnic profile when used by vms is
asym=
metric to the<br>> > > network removal<br>>
> > when it i=
s used by vms or templates. Today the update network operation<br>>
>=
> is<br>> > > blocked for that.<br>>
> > In addition,=
with the suggest simplification to remove a profile when no<br>> >
&=
gt; running vms, the user<br>> > > will have to find for
himself i=
f the profile is being used prior to its<br>> > > removal since
th=
e<br>> > > operation will not be blocked.<br>>
> ><br>>=
; > > If we allow to delete a vnic profile, when a vm is using it (re=
gardless<br>> > > the<br>> > > VM
status)<br>> > &g=
t; we'll have to update the VM entity as well in that operation: since we d=
o<br>> > > not support a<br>> > >
network with 'none' pro=
file, we'll have to delete the network as well.<br>> >
><br>> &=
gt; > If we'll remove a vnic profile in 3.1 cluster, used by vms in stat=
us<br>> > > down,<br>> > > we'd
find a case<br>> > =
> in which a VM is attached to a 'none' network. This is unsupported in =
3.1<br>> > > cluster. We can block<br>> >
> such operatio=
n, but this is another motivation why we'd better not to<br>> >
> =
allow<br>> > > removing a used profile.<br>>
> ><br>> =
<br>> > The context above is about editing not deleting
:)<br>> &g=
t; I agree with what you wrote if the context was remove.<br>>
<br>> =
> >><br>> > >>> Since we
have no way to distinguish=
between running and current<br>> > >>>
configurations, the =
expected behavior of such a change is<br>> > >>>
unpredictab=
le and less intuitive to the user (especially since<br>> >
>>&g=
t; dynamic wiring is supported).<br>> > >>> The
changes will=
seep down to all VNICs using the profile.<br>> >
>>> In cas=
e VNIC using the edited profile are connected to running VMs,<br>> >
=
>>> the change will apply only on the VM next run.<br>>
> &g=
t;>><br>> > >>> Question: What
about Hibernate/Suspend=
VM ? will the resume VM action<br>> > >>>
uses<br>> >=
>>> the original configuration for the vnics when the VM was star=
ted ?<br>> > >><br>> >
>> Currently profile include=
s: network, port-mirroring, custom property,<br>> > >>
QoS<br>&=
gt; > >><br>> > >> Changing any of
the above (except f=
or network) requires a VM reboot, so<br>> > >> I think
that we =
can start with the following statement - the profile<br>> >
>> =
change would only apply after next VM reboot.<br>> >
>><br>>=
> >> There are 2 problems with the above:<br>> >
>> -=
Today we support network wiring, with VNIC profiles we are asking the<br>&=
gt; > >> users to create a new profile and attach the VMs to the n=
ew profile, I<br>> > >> can see the RFE coming - we can
report =
that ourselves ;)<br>> > >><br>> >
>> - We don't re=
flect with which configuration the VM is running, e.g we<br>> >
>&=
gt; edited the profile QoS but I'm not sure with which QoS the VM
is<br>>=
; > >> currently running. (The RFE for differentiating between cur=
rent<br>> > >> configuration and running configuration
was alre=
ady asked for by<br>> > >> numerous
users)<br>> > >>=
;<br>> > >> The above is a general issue that we need to
solve =
and I would not limit<br>> > >> editing VNIC profiles
because o=
f it.<br>> > >> We can mitigate this specifically for
QoS like =
described bellow.<br>> > >><br>> >
>><br>> > =
>><br>> > >>> Deleting a
Profile<br>> > >>=
><br>> > >>> VNIC Profiles could not be
deleted from the =
engine as long as one or<br>> > >>>
more<br>> > >&g=
t;> VM/Templates are using those profiles.<br>> >
>><br>>=
> >>> Reporting vNic actual configuration<br>>
> >>=
;><br>> > >>> The engine will retrieve the
actual configu=
ration of the profile<br>> > >>> properties on
the VNIC from=
VDSM (using the network statistics<br>> > >>>
mechanism) an=
d the networked administrator will be presented with the<br>> >
>&=
gt;> state of each VNIC (synched/unsynched).<br>> >
>>><b=
r>> > >><br>> > >> Will
the admin be able to see th=
e actual values? I think the synced<br>> > >> property
is not e=
nough (I'm not sure how interesting this property is to<br>> >
>&g=
t; start with).<br>> > ><br>> > > We
can extend the VmGue=
stAgentInterface to contain the actual value, so<br>> > >
they<br>=
> > > will be presented for each vnic in the 'guest data'
sub-tab.=
<br>> > ><br>> <br>> > AFAIU
this info does not come from=
the guest it is info we retrieve from<br>> >
libvirt.<br>> > T=
he VmGuestAgentInterface should be used only for information reported<br>&g=
t; > by the guest, information whose credibility can be
questioned.<br>&=
gt; <br>> > >><br>> >
>>> Editing a VNIC / Chang=
ing a VNIC profile<br>> > >>><br>>
> >>> Chan=
ging the profile a VM is using while the VM is running should<br>> >
=
>>> behave like dynamic wiring (changing the VM network while it i=
s<br>> > >>> running).<br>> >
>>> Hot-plug of=
a vnic will will use will use the updated profile connected<br>> >
&=
gt;>> to the VNIC.<br>> >
>>><br>> > >><br=
> > >> Not sure I fully understand the
sentence above.<br>>=
> >> Hot plug will be fully
supported, you can choose any profile=
(you have<br>> > >> permissions on) while plugging a
new devic=
e.<br>> > >><br>> >
><br>> > > That was the i=
ntention. seems like an edgy hand syndrome :)<br>> > > Changed
to:=
<br>> > > * Hot plug will be fully supported: the user can
choose =
any permitted<br>> > > profile while plugging a new device or
when=
activating an existing one.<br>> > ><br>>
> >>> Ad=
ding a Network<br>> > >>><br>>
> >>> When add=
ing a network, a user can provide an option to create a vNic<br>> >
&=
gt;>> Profile for it.<br>> >
>>><br>> > >>=
> Question: Is it s default profile ? what are its properties ?<br>>
=
> >>> Question: What about 'Public Use' option ? Are
they still=
relevant in<br>> > >>> the<br>>
> >>> contex=
t of adding new networks or we should eliminate them and move it<br>>
&g=
t; >>> only to 'Add vNic Profile' dialog?<br>>
> >>>=
;<br>> > >><br>> > >>
see previous comments<br>>=
> >> In addition when creating a profile we should have 'Allow
al=
l' for<br>> > >> implicitly creating permissions,
like we have =
today for network.<br>> > >><br>> >
>>> Updating=
a Network<br>> > >>><br>> >
>>> When a netwo=
rk role is modified to be a 'non-VM network', all vNic<br>> >
>>=
;> profiles<br>> > >>> associated with it
should be delet=
ed.<br>> > >><br>> >
>> And permissions associated =
with these profiles<br>> > >><br>> >
>>> Removin=
g a Network<br>> > >>><br>> >
>>> Should remo=
ve all profiles on that network<br>> >
>>><br>> > >=
><br>> > >> And associated
permissions<br>> > >>=
<br>> > >>> Adding an Empty
Data-Center<br>> > >>=
;><br>> > >>> Currently, When creating a
new Data-Center,=
the management network is<br>> > >>>
automatically created.=
<br>> > >>> From 3.3, a default vNic profile will
be created=
for the management<br>> > >>>
network.<br>> > >>=
;><br>> > >>> VM
snapshot/import/export<br>> > >=
>><br>> > >>> We should handle VMs
that are pointing t=
o a network directly for<br>> > >>> backward
compatibility.<=
br>> > >>> We need to select first profile that is
on that n=
etwork that the user<br>> > >>> has permissions
on.<br>> =
> >>><br>> > >>>
Question: Do we wish to support=
it export from 3.3 and import to 3.2 or<br>> >
>>> below?<b=
r>> > >><br>> > >> That
means that when you write a=
VM in the OVF you need to write network<br>> > >> in
addition =
to profile.<br>> > >><br>> >
><br>> > > The n=
etwork name is already there, so when importing a vnic from 3.3 to<br>> =
> > an<br>> > > earlier version<br>>
> > the profil=
e name will be ignored.<br>> > ><br>> >
>><br>> >=
; >>> Question: A user can import/export a VM/Template even if he =
doesn't<br>> > >>> have<br>>
> >>> permission=
s on the networks. Is the next flow valid ?<br>> >
>>><br>&g=
t; > >>> The profile name should be saved in the OVF (in
additi=
on to the network<br>> > >>> name which is saved
today).<br>=
> > >>> During import, if both (network name, profile
name) =
exist on the target<br>> > >>> DC, the vnic will
get the pro=
file id.<br>> > >>> If the network exists in the
Data-Center=
, but has no profile as<br>> > >>> specified in
the OVF, the=
user will be notified (event log) and the<br>> >
>>> VNIC w=
ill be connected to a default minimal profile defined in the<br>> >
&=
gt;>> system, regardless the permissions the user has on the network.=
<br>> > >>><br>> >
>><br>> > >> What=
is a 'default minimal profile' ? I would rather have a VNIC with
no<br>>=
; > >> profile associated with it.<br>> >
><br>> > =
> The 'default minimal profile' refers to a vnic profile with the
lower<=
br>> > > average bandwidth.<br>> >
><br>> > > Wi=
th the approach you've suggested, any imported VM/Template from an<br>>
=
> > earlier to 3.3 version<br>> > > will require
a manual in=
tervention in order to configure a network to the<br>> > >
VM.<br>=
> <br>> > I should have elaborated some more
-<br>> <br>> &g=
t; If a VM has a profile then we should look up this specific profile, if<b=
r>> > such a profile does not exists then import the VM with profile =
none like<br>> > we do today for VM's with reference to a network
tha=
t does not exist on<br>> > the setup.<br>>
<br>> > If a VM d=
oes not have a profile (3.2 and lower versions) we should look<br>>
>=
into the network name, if this network exist and we have a profile with<br=
> > permissions to the user then use this profile (if
there is more =
than one<br>> > choose one
randomly).<br>> <br>> > > And =
for 3.1 we'll have to drop such vnics since network 'none'
isn't<br>> &g=
t; > supported.<br>> > ><br>> >
>><br>> > >=
;>> If failed to find any matching vNic profile, the vnic's profile w=
ill be<br>> > >>> set<br>> >
>>> with 'none'.=
<br>> > >>><br>> >
>>> When a Template is cre=
ated from a VM the VNIC Profile will be kept<br>> >
>>> alon=
g with the VNIC. When a VM is created from template the VNIC<br>> >
&=
gt;>> Profiles will be taken from the template's
VNICs.<br>> > =
>>><br>> > >>> -----
Original Message -----<br>>=
> >>>> From: "Livnat Peer"
&lt;lpeer(a)redhat.com&gt;<br>&gt;=
> >>>> To: "engine-devel"
&lt;engine-devel(a)ovirt.org&gt;, "=
Ofri Masad"<br>> > >>>>
&lt;omasad(a)redhat.com&gt;<br>&gt;=
> >>>> Cc: "Mike Kolesnik"
&lt;mkolesni(a)redhat.com&gt;, "Mo=
ti Asayag"<br>> > >>>>
&lt;masayag(a)redhat.com&gt;, "Oved =
Ourfalli" &lt;oourfali(a)redhat.com&gt;<br>&gt; >
>>>> Sent: S=
unday, June 30, 2013 3:59:37 PM<br>> >
>>>> Subject: VNIC=
profiles<br>> > >>>><br>>
> >>>> Hi,<b=
r>> > >>>><br>> >
>>>> We are working o=
n adding VNIC profiles as part of the work to add VNIC<br>> >
>>=
;>> QoS.<br>> >
>>>><br>> >
>>>> =
http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles<br>> >
>&g=
t;>><br>> > >>>> We need to
define some of the syst=
em behavior followed by this change,<br>> >
>>>> here is =
my take -<br>> > >>>><br>>
> >>>> Editi=
ng a profile -<br>> > >>>>
--------------------<br>> &=
gt; >>>> A user should be able to edit the profile properties
(=
including<br>> > >>>>
profile<br>> > >>>&g=
t; name) while VMs are attached and are using this Profile (reference<br>&g=
t; > >>>> should be done by id).<br>>
> >>>&g=
t;<br>> > >>>> Changing the network though
is a bit more =
tricky as long as we don't<br>> > >>>>
have a way to dist=
inguish between running and current configurations I<br>> >
>>&=
gt;> think it could be very confusing to the user. Especially since we<b=
r>> > >>>> support dynamic wiring so the
behavior IMO is =
unpredictable.<br>> > >>>> I think it
should be blocked a=
t this point.<br>> >
>>>><br>> >
>>>><b=
r>> > >>>> Edit a VNIC / change a VNIC
profile -<br>> =
> >>>>
------------------------------------<br>> > >=
;>>> Changing the profile a VM is using while the VM is running sh=
ould<br>> > >>>> behave<br>>
> >>>> lik=
e dynamic wiring (changing the VM network while it is running).<br>>
>=
; >>>><br>> >
>>>><br>> >
>>>&=
gt; Remove a Profile -<br>> > >>>>
-------------------<br=
> > >>>> Is only valid if
all VMs that are using this pr=
ofile are in status<br>> >
>>>> down.<br>> > >&g=
t;>> It should update all VMs to point to no profile which should beh=
ave<br>> > >>>> like<br>>
> >>>> none n=
etwork today.<br>> >
>>>><br>> >
>>>> I=
see no reason to support a profile on a none network at this point.<br>>=
; > >>>><br>> >
>>>> The above is also rel=
evant for upgrade flow (upgrading none network to<br>> >
>>>=
> point to no profile)<br>> >
>>>><br>> > >&g=
t;>><br>> > >>>> Removing a
Network -<br>> > =
>>>> ----------------------<br>> >
>>>> shoul=
d remove all profiles on that network<br>> >
>>>><br>>=
> >>>><br>> >
>>>> VM snapshot/import/exp=
ort -<br>> > >>>>
--------------------------<br>> >=
>>>> We should handle VMs that are pointing to a network
direc=
tly for b/w<br>> > >>>>
compatibility.<br>> > >&=
gt;>> we need to select first profile that is on that network that th=
e user<br>> > >>>> has permissions
on.<br>> > >&=
gt;>><br>> >
>>>><br>> >
>>>> I a=
ssume there are more, comments are welcome<br>> >
>>>><br=
> > >>>> Thanks,
Livnat<br>> > >>>><br=
> > >>>><br>> >
>><br>> > >><br>=
>
<br></blockquote><div><br></div></div></body></html>
------=_Part_17897434_1769683215.1375106264138--
12:07 a.m.
----- Original Message -----
From: "Amihay Winter" <awinter(a)redhat.com>
To: "Moti Asayag" <masayag(a)redhat.com>
Cc: engine-devel(a)ovirt.org, "Livnat Peer" <lpeer(a)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(a)redhat.com>
> To: "Amihay Winter" <awinter(a)redhat.com>
> Cc: engine-devel(a)ovirt.org, "Livnat Peer" <lpeer(a)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(a)redhat.com>
> > To: engine-devel(a)ovirt.org
> > Cc: "Moti Asayag" <masayag(a)redhat.com>, "Livnat Peer"
<lpeer(a)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(a)redhat.com>
> > > To: "Moti Asayag" <masayag(a)redhat.com>
> > > Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Ofri
Masad"
> > > <omasad(a)redhat.com>, "Mike Kolesnik"
<mkolesni(a)redhat.com>, "Oved
> > > Ourfalli"
> > > <oourfali(a)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(a)redhat.com>
> > > >> To: "Moti Asayag" <masayag(a)redhat.com>
> > > >> Cc: "engine-devel" <engine-devel(a)ovirt.org>,
"Ofri Masad"
> > > >> <omasad(a)redhat.com>, "Mike Kolesnik"
<mkolesni(a)redhat.com>,
> > > >> "Oved Ourfalli" <oourfali(a)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(a)redhat.com>
> > > >>>> To: "engine-devel"
<engine-devel(a)ovirt.org>, "Ofri Masad"
> > > >>>> <omasad(a)redhat.com>
> > > >>>> 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
> > > >>>>
> > > >>>> 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
> > > >>>>
> > > >>>>
> > > >>
> > > >>
> >
3927
days inactive
3933
days old
3 comments
2 participants
participants (2)
-
Amihay Winter -
Moti Asayag