<html><body><div style="font-family: times new roman, new york, times, serif; 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="auto">Device 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 please bear with me :)<br></div><div><div><br></div><div>I want to talk about two things:<br></div><div>1. Sending an updateDevice verb whenever clicking 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) it 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> I'll describe a Scenario:</div><div> Creating profile A with property speed = 500 <br></div><div> Setting vnic2 on vm to have profile A (using Hotplugnic)</div><div> Changing (in the profile) speed = 700</div><div> According to the Vnic_Profiles's wiki, only when I restart my vm I'll get my setting right.</div><div> 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.<br></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 maybe stopping others' work.<br></div><div> I think that restarting 1000 vms because I want to set a property is not something that an admin would want to do.<br></div><div> </div><div> One way to implement it is to send a verb "updateDevice" each time we open the the "Edit" window and clicking "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 verb, 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><div>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.</div><div> 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.</div><div> In my opinion, Profile's properties may have: max_mtu, min_mtu, mtu, speed, id, vlan... Identifiers for the network.</div><div> Maybe I'm missing 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 id="result_box" class="short_text" lang="en"><span class="hps alt-edited">I'll really appreciate comments.</span></span></div><div><span id="result_box" class="short_text" lang="en"><span class="hps alt-edited">Thank you for your time.</span></span></div><div>Amihay Winter<br> </div><br></div><hr id="zwchr"><blockquote style="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;">----- Forwarded Message -----<br>From: "Livnat Peer" <lpeer@redhat.com><br>To: "Moti Asayag" <masayag@redhat.com><br>Cc: "engine-devel" <engine-devel@ovirt.org>, "Ofri Masad" <omasad@redhat.com>, "Mike Kolesnik" <mkolesni@redhat.com>, "Oved Ourfalli" <oourfali@redhat.com><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, Moti Asayag wrote:<br>> I've updated the wiki accordingly and added few comments inline.<br>> <br>> ----- Original Message -----<br>>> From: "Livnat Peer" <lpeer@redhat.com><br>>> To: "Moti Asayag" <masayag@redhat.com><br>>> Cc: "engine-devel" <engine-devel@ovirt.org>, "Ofri Masad" <omasad@redhat.com>, "Mike Kolesnik" <mkolesni@redhat.com>,<br>>> "Oved Ourfalli" <oourfali@redhat.com><br>>> Sent: Sunday, July 7, 2013 2:59:34 PM<br>>> Subject: Re: VNIC profiles<br>>><br>>> On 07/07/2013 01:59 PM, Moti Asayag wrote:<br>>>> Hi,<br>>>><br>>>> I've updated the 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 description of the feature behavior.<br>>> See my comments bellow -<br>>><br>>>> In addition, another question here:<br>>>><br>>>> The units within the UI mockups are Mb and Mbps. The libvirt APIs expects<br>>>> the units to be in kb and kbps. Which component is responsible to convert<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 agreed that the translation 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 network administrator could create several VNIC Profiles for each<br>>>> 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 profiles for<br>>>> network "blue":<br>>>><br>>>> Profile "Gold" - with better 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 profiles to avoid confusion.<br>>> Gold and Silver are likely to be QoS object names, a more typical name<br>>> for a network profile is - teachers-blue and students-blue<br>>><br>>> The different profiles can have different QoS (teachers-blue would get<br>>> Gold QoS while Students-blue will have Silver).<br>>><br>>><br>>>> He will 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 better 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 network<br>>>> "blue" with high QoS and with port mirroring.<br>>>><br>>>> Question: In the same matter we allowed via the UI to grant 'NetworkUser'<br>>>> to 'everyone' user, wouldn't it ease the use of Profiles if we support it<br>>>> in this 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 display 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, this option would give permission to<br>>> everyone on that profile.<br>>><br>>><br>>>><br>>>> Editing a Profile<br>>>><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>>>> Changing 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>>> profile (or more simple to implement if all VMs that are using this<br>>> 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 blocked 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 himself if the profile is being used prior to its removal since the <br>> operation 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 have to update the VM entity as well in that operation: since we do not support 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, used by vms in status down, we'd find a case <br>> in which a VM is attached 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 above is about editing not deleting :)<br>I agree with what you wrote if the context was remove.<br><div><br></div>>><br>>>> Since we have no way to distinguish between running and current<br>>>> configurations, the expected behavior of such a change is<br>>>> unpredictable and less intuitive to the user (especially since<br>>>> dynamic wiring is supported).<br>>>> The changes will seep down to all VNICs using the profile.<br>>>> In case VNIC using the edited profile are connected to running VMs,<br>>>> the change will apply only on the VM next run.<br>>>><br>>>> Question: What about Hibernate/Suspend VM ? will the resume VM action uses<br>>>> the original configuration for the vnics when the VM was started ?<br>>><br>>> Currently profile includes: network, port-mirroring, custom property, QoS<br>>><br>>> Changing any 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 the RFE coming - we can report that ourselves ;)<br>>><br>>> - We don't reflect with which configuration the VM is running, e.g we<br>>> 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>>> configuration and running configuration was already 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 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/Templates are using those profiles.<br>>><br>>>> Reporting vNic actual configuration<br>>>><br>>>> The engine will retrieve the actual configuration of the profile<br>>>> 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 (synched/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>>> start with).<br>> <br>> We can extend the VmGuestAgentInterface to contain the actual value, so they<br>> will be presented for each vnic in the '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 VmGuestAgentInterface should be used only for information reported<br>by the guest, information whose credibility can be questioned.<br><div><br></div><br>>><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 will use the updated profile connected<br>>>> 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 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>>>> Adding a Network<br>>>><br>>>> When adding a network, a user can provide an option to create a vNic<br>>>> 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 permissions, like we have today for network.<br>>><br>>>> Updating a Network<br>>>><br>>>> When a network role is modified to be a 'non-VM network', all vNic profiles<br>>>> associated with 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 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 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 import 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 addition 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>>>> Question: A user can import/export a VM/Template even if he doesn't have<br>>>> 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 saved today).<br>>>> During import, if both (network name, profile name) exist on the target<br>>>> DC, the vnic will get the profile 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 will be connected to a default minimal profile defined in the<br>>>> 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 average bandwidth.<br>> <br>> With the approach you've suggested, any imported VM/Template from an earlier to 3.3 version <br>> will require a manual intervention in order to configure a network to the VM.<br><div><br></div>I should have elaborated some more -<br><div><br></div>If a VM has a profile then we should look up this specific profile, if<br>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 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>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><div><br></div><br>> And for 3.1 we'll have to drop such vnics since network 'none' isn't supported.<br>> <br>>><br>>>> If failed to find any matching vNic profile, the vnic's profile will be set<br>>>> with 'none'.<br>>>><br>>>> When a Template is created from a VM the VNIC Profile will be kept<br>>>> along with the VNIC. When a VM is created from template the VNIC<br>>>> Profiles will be taken from the template's VNICs.<br>>>><br>>>> ----- Original Message -----<br>>>>> From: "Livnat Peer" <lpeer@redhat.com><br>>>>> To: "engine-devel" <engine-devel@ovirt.org>, "Ofri Masad"<br>>>>> <omasad@redhat.com><br>>>>> Cc: "Mike Kolesnik" <mkolesni@redhat.com>, "Moti Asayag"<br>>>>> <masayag@redhat.com>, "Oved Ourfalli" <oourfali@redhat.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 VNIC profiles as part of the work to add VNIC<br>>>>> QoS.<br>>>>><br>>>>> http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles<br>>>>><br>>>>> We need to define some of the system behavior followed by this change,<br>>>>> here is my take -<br>>>>><br>>>>> Editing a profile -<br>>>>> --------------------<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>>>>><br>>>>> 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 configurations I<br>>>>> think it could be very confusing to the user. Especially since we<br>>>>> support dynamic wiring so the behavior IMO is unpredictable.<br>>>>> I think it should be blocked at this point.<br>>>>><br>>>>><br>>>>> Edit a VNIC / change a VNIC profile -<br>>>>> ------------------------------------<br>>>>> Changing the profile a VM is using while the VM is running should behave<br>>>>> like dynamic wiring (changing the VM network while it is running).<br>>>>><br>>>>><br>>>>> Remove a Profile -<br>>>>> -------------------<br>>>>> Is only valid if all VMs that are using this profile are in status down.<br>>>>> It should update all VMs to point to no profile which should behave like<br>>>>> none network today.<br>>>>><br>>>>> I see no reason to support a profile on a none network at this point.<br>>>>><br>>>>> The above is also relevant for upgrade flow (upgrading none network to<br>>>>> point to no profile)<br>>>>><br>>>>><br>>>>> Removing a Network -<br>>>>> ----------------------<br>>>>> should remove all profiles on that network<br>>>>><br>>>>><br>>>>> VM snapshot/import/export -<br>>>>> --------------------------<br>>>>> We should handle VMs that are pointing to a network 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><br></div></div></body></html>