<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>&nbsp;&nbsp;&nbsp; &nbsp; "The changes will seep down to all VNICs using the profile.</div><div>&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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;&nbsp;&nbsp; I'll describe a Scenario:</div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Creating profile A with property speed = 500 <br></div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Setting vnic2 on vm to have profile A (using Hotplugnic)</div><div>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; Changing (in the profile) speed = 700</div><div>&nbsp;&nbsp;&nbsp; According to the Vnic_Profiles's wiki, only when I restart my vm I'll get my setting right.</div><div>&nbsp;&nbsp;&nbsp; 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>&nbsp;&nbsp;&nbsp; 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>&nbsp;&nbsp;&nbsp; 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>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</div><div>&nbsp;&nbsp;&nbsp; One way to implement it is to send a verb "updateDevice" each time we open the the "Edit" window and clicking "OK"</div><div>&nbsp;&nbsp;&nbsp; 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" &amp; "OK" then he wanted to send the verb, otherwise, he would have pressed on "Edit" &amp; "Cancel".</div><div><br></div><div>&nbsp;&nbsp;&nbsp; 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"&nbsp; 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>&nbsp;&nbsp;&nbsp;&nbsp;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>&nbsp;&nbsp;&nbsp; In my opinion, Profile's properties may have: max_mtu, min_mtu, mtu, speed, id, vlan... Identifiers for the network.</div><div>&nbsp;&nbsp;&nbsp; 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>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</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" &lt;lpeer@redhat.com&gt;<br>To: "Moti Asayag" &lt;masayag@redhat.com&gt;<br>Cc: "engine-devel" &lt;engine-devel@ovirt.org&gt;, "Ofri Masad" &lt;omasad@redhat.com&gt;, "Mike Kolesnik" &lt;mkolesni@redhat.com&gt;, "Oved Ourfalli" &lt;oourfali@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, Moti Asayag wrote:<br>&gt; I've updated the wiki accordingly and added few comments inline.<br>&gt; <br>&gt; ----- Original Message -----<br>&gt;&gt; From: "Livnat Peer" &lt;lpeer@redhat.com&gt;<br>&gt;&gt; To: "Moti Asayag" &lt;masayag@redhat.com&gt;<br>&gt;&gt; Cc: "engine-devel" &lt;engine-devel@ovirt.org&gt;, "Ofri Masad" &lt;omasad@redhat.com&gt;, "Mike Kolesnik" &lt;mkolesni@redhat.com&gt;,<br>&gt;&gt; "Oved Ourfalli" &lt;oourfali@redhat.com&gt;<br>&gt;&gt; Sent: Sunday, July 7, 2013 2:59:34 PM<br>&gt;&gt; Subject: Re: VNIC profiles<br>&gt;&gt;<br>&gt;&gt; On 07/07/2013 01:59 PM, Moti Asayag wrote:<br>&gt;&gt;&gt; Hi,<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; I've updated the wiki with the feedbacks from this thread, added a backend<br>&gt;&gt;&gt; section naming the affected commands and also add added few questions of<br>&gt;&gt;&gt; my own embedded in the pastedtext below.<br>&gt;&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; Hi Moti,<br>&gt;&gt; A good and comprehensive description of the feature behavior.<br>&gt;&gt; See my comments bellow -<br>&gt;&gt;<br>&gt;&gt;&gt; In addition, another question here:<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; The units within the UI mockups are Mb and Mbps. The libvirt APIs expects<br>&gt;&gt;&gt; the units to be in kb and kbps. Which component is responsible to convert<br>&gt;&gt;&gt; them to the expect units ? engine or VDSM ?<br>&gt;&gt;<br>&gt;&gt; Giuseppe mentioned that in a previous thread on this subject.<br>&gt;&gt; Ofri and Giuseppe agreed that the translation would be done on the<br>&gt;&gt; engine level.<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Copied text from the wiki:<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Adding a Profile<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; The network administrator could create several VNIC Profiles for each<br>&gt;&gt;&gt; network. He could then grant a users with the permission to use (consume)<br>&gt;&gt;&gt; each profile. The user will only be able to use profiles which he was<br>&gt;&gt;&gt; granted access to.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; &nbsp; &nbsp; For example: the network admin will create two VNIC profiles for<br>&gt;&gt;&gt; &nbsp; &nbsp; network "blue":<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; Profile "Gold" - with better QoS and with port mirroring<br>&gt;&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; Profile "Silver" with lower QoS and without port mirroring.<br>&gt;&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; I would use other names for the profiles to avoid confusion.<br>&gt;&gt; Gold and Silver are likely to be QoS object names, &nbsp;a more typical name<br>&gt;&gt; for a network profile is - teachers-blue and students-blue<br>&gt;&gt;<br>&gt;&gt; The different profiles can have different QoS (teachers-blue would get<br>&gt;&gt; Gold QoS while Students-blue will have Silver).<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;&gt; &nbsp; &nbsp; He will then define the user-group "students" as user of profile<br>&gt;&gt;&gt; &nbsp; &nbsp; "Silver" and user-group "teachers" as user of profile "Gold". In this<br>&gt;&gt;&gt; &nbsp; &nbsp; case the teachers will enjoy better quality of service then the<br>&gt;&gt;&gt; &nbsp; &nbsp; students. When a teacher will add/edit a virtual NIC he could select<br>&gt;&gt;&gt; &nbsp; &nbsp; profile "Gold" for that NIC - the VNIC will be connected to network<br>&gt;&gt;&gt; &nbsp; &nbsp; "blue" with high QoS and with port mirroring.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Question: In the same matter we allowed via the UI to grant 'NetworkUser'<br>&gt;&gt;&gt; to 'everyone' user, wouldn't it ease the use of Profiles if we support it<br>&gt;&gt;&gt; in this context as well?<br>&gt;&gt;<br>&gt;&gt; The ease of use could be that when creating a network we'll display in<br>&gt;&gt; the UI all VNIC-QoS-objects and the users could tick next to the QoS<br>&gt;&gt; they are interested in, for each QoS that was chosen a profile would be<br>&gt;&gt; created.<br>&gt;&gt;<br>&gt;&gt; I would enhance that with youe suggestion above and display next to the<br>&gt;&gt; QoS that was checked the option to mark 'Allow All users' like we have<br>&gt;&gt; today for making a network public, this option would give permission to<br>&gt;&gt; everyone on that profile.<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Editing a Profile<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; &nbsp; &nbsp; A user should be able to edit the profile properties (including profile<br>&gt;&gt;&gt; &nbsp; &nbsp; name) while VMs are attached and are using this Profile (reference<br>&gt;&gt;&gt; &nbsp; &nbsp; should be done by id).<br>&gt;&gt;&gt; &nbsp; &nbsp; Changing the network of a vNic profile will be allowed only if no VMs<br>&gt;&gt;&gt; &nbsp; &nbsp; are using the profile.<br>&gt;&gt;<br>&gt;&gt; It would be better if we can limit this to no running VM is using the<br>&gt;&gt; profile (or more simple to implement if all VMs that are using this<br>&gt;&gt; profile are in status down).<br>&gt; <br>&gt; Allowing to delete a vnic profile when used by vms is asymmetric to the network removal<br>&gt; when it is used by vms or templates. Today the update network operation is blocked for that.<br>&gt; In addition, with the suggest simplification to remove a profile when no running vms, the user<br>&gt; will have to find for himself if the profile is being used prior to its removal since the <br>&gt; operation will not be blocked.<br>&gt; <br>&gt; If we allow to delete a vnic profile, when a vm is using it (regardless the VM status) <br>&gt; we'll have to update the VM entity as well in that operation: since we do not support a<br>&gt; network with 'none' profile, we'll have to delete the network as well.<br>&gt; <br>&gt; If we'll remove a vnic profile in 3.1 cluster, used by vms in status down, we'd find a case <br>&gt; in which a VM is attached to a 'none' network. This is unsupported in 3.1 cluster. We can block<br>&gt; such operation, but this is another motivation why we'd better not to allow removing a used profile.<br>&gt; <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>&gt;&gt;<br>&gt;&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; Since we have no way to distinguish between running and current<br>&gt;&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; configurations, the expected behavior of such a change is<br>&gt;&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; unpredictable and less intuitive to the user (especially since<br>&gt;&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; dynamic wiring is supported).<br>&gt;&gt;&gt; &nbsp; &nbsp; The changes will seep down to all VNICs using the profile.<br>&gt;&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; In case VNIC using the edited profile are connected to running VMs,<br>&gt;&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; the change will apply only on the VM next run.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Question: What about Hibernate/Suspend VM ? will the resume VM action uses<br>&gt;&gt;&gt; the original configuration for the vnics when the VM was started ?<br>&gt;&gt;<br>&gt;&gt; Currently profile includes: network, port-mirroring, custom property, QoS<br>&gt;&gt;<br>&gt;&gt; Changing any of the above (except for network) requires a VM reboot, so<br>&gt;&gt; I think that we can start with the following statement - the profile<br>&gt;&gt; change would only apply after next VM reboot.<br>&gt;&gt;<br>&gt;&gt; There are 2 problems with the above:<br>&gt;&gt; - Today we support network wiring, with VNIC profiles we are asking the<br>&gt;&gt; users to create a new profile and attach the VMs to the new profile, I<br>&gt;&gt; can see the RFE coming - we can report that ourselves ;)<br>&gt;&gt;<br>&gt;&gt; - We don't reflect with which configuration the VM is running, e.g we<br>&gt;&gt; edited the profile QoS but I'm not sure with which QoS the VM is<br>&gt;&gt; currently running. (The RFE for differentiating between current<br>&gt;&gt; configuration and running configuration was already asked for by<br>&gt;&gt; numerous users)<br>&gt;&gt;<br>&gt;&gt; The above is a general issue that we need to solve and I would not limit<br>&gt;&gt; editing VNIC profiles because of it.<br>&gt;&gt; We can mitigate this specifically for QoS like described bellow.<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;&gt; Deleting a Profile<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; VNIC Profiles could not be deleted from the engine as long as one or more<br>&gt;&gt;&gt; VM/Templates are using those profiles.<br>&gt;&gt;<br>&gt;&gt;&gt; Reporting vNic actual configuration<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; &nbsp; &nbsp; The engine will retrieve the actual configuration of the profile<br>&gt;&gt;&gt; &nbsp; &nbsp; properties on the VNIC from VDSM (using the network statistics<br>&gt;&gt;&gt; &nbsp; &nbsp; mechanism) and the networked administrator will be presented with the<br>&gt;&gt;&gt; &nbsp; &nbsp; state of each VNIC (synched/unsynched).<br>&gt;&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; Will the admin be able to see the actual values? I think the synced<br>&gt;&gt; property is not enough (I'm not sure how interesting this property is to<br>&gt;&gt; start with).<br>&gt; <br>&gt; We can extend the VmGuestAgentInterface to contain the actual value, so they<br>&gt; will be presented for each vnic in the 'guest data' sub-tab.<br>&gt; <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>&gt;&gt;<br>&gt;&gt;&gt; Editing a VNIC / Changing a VNIC profile<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; &nbsp; &nbsp; Changing the profile a VM is using while the VM is running should<br>&gt;&gt;&gt; &nbsp; &nbsp; behave like dynamic wiring (changing the VM network while it is<br>&gt;&gt;&gt; &nbsp; &nbsp; running).<br>&gt;&gt;&gt; &nbsp; &nbsp; Hot-plug of a vnic will will use will use the updated profile connected<br>&gt;&gt;&gt; &nbsp; &nbsp; to the VNIC.<br>&gt;&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; Not sure I fully understand the sentence above.<br>&gt;&gt; Hot plug will be fully supported, you can choose any profile (you have<br>&gt;&gt; permissions on) while plugging a new device.<br>&gt;&gt;<br>&gt; <br>&gt; That was the intention. seems like an edgy hand syndrome :)<br>&gt; Changed to:<br>&gt; &nbsp;* 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>&gt; <br>&gt;&gt;&gt; Adding a Network<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; &nbsp; &nbsp; When adding a network, a user can provide an option to create a vNic<br>&gt;&gt;&gt; &nbsp; &nbsp; Profile for it.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Question: Is it s default profile ? what are its properties ?<br>&gt;&gt;&gt; Question: What about 'Public Use' option ? Are they still relevant in the<br>&gt;&gt;&gt; context of adding new networks or we should eliminate them and move it<br>&gt;&gt;&gt; only to 'Add vNic Profile' dialog?<br>&gt;&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; see previous comments<br>&gt;&gt; In addition when creating a profile we should have 'Allow all' for<br>&gt;&gt; implicitly creating permissions, like we have today for network.<br>&gt;&gt;<br>&gt;&gt;&gt; Updating a Network<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; When a network role is modified to be a 'non-VM network', all vNic profiles<br>&gt;&gt;&gt; associated with it should be deleted.<br>&gt;&gt;<br>&gt;&gt; And permissions associated with these profiles<br>&gt;&gt;<br>&gt;&gt;&gt; Removing a Network<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; &nbsp; &nbsp; Should remove all profiles on that network<br>&gt;&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; And associated permissions<br>&gt;&gt;<br>&gt;&gt;&gt; Adding an Empty Data-Center<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; &nbsp; &nbsp; Currently, When creating a new Data-Center, the management network is<br>&gt;&gt;&gt; &nbsp; &nbsp; automatically created.<br>&gt;&gt;&gt; &nbsp; &nbsp; From 3.3, a default vNic profile will be created for the management<br>&gt;&gt;&gt; &nbsp; &nbsp; network.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; VM snapshot/import/export<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; &nbsp; &nbsp; We should handle VMs that are pointing to a network directly for<br>&gt;&gt;&gt; &nbsp; &nbsp; backward compatibility.<br>&gt;&gt;&gt; &nbsp; &nbsp; We need to select first profile that is on that network that the user<br>&gt;&gt;&gt; &nbsp; &nbsp; has permissions on.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Question: Do we wish to support it export from 3.3 and import to 3.2 or<br>&gt;&gt;&gt; below?<br>&gt;&gt;<br>&gt;&gt; That means that when you write a VM in the OVF you need to write network<br>&gt;&gt; in addition to profile.<br>&gt;&gt;<br>&gt; <br>&gt; The network name is already there, so when importing a vnic from 3.3 to an earlier version<br>&gt; the profile name will be ignored.<br>&gt; <br>&gt;&gt;<br>&gt;&gt;&gt; Question: A user can import/export a VM/Template even if he doesn't have<br>&gt;&gt;&gt; permissions on the networks. Is the next flow valid ?<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; &nbsp; &nbsp; The profile name should be saved in the OVF (in addition to the network<br>&gt;&gt;&gt; &nbsp; &nbsp; name which is saved today).<br>&gt;&gt;&gt; &nbsp; &nbsp; During import, if both (network name, profile name) exist on the target<br>&gt;&gt;&gt; &nbsp; &nbsp; DC, the vnic will get the profile id.<br>&gt;&gt;&gt; &nbsp; &nbsp; If the network exists in the Data-Center, but has no profile as<br>&gt;&gt;&gt; &nbsp; &nbsp; specified in the OVF, the user will be notified (event log) and the<br>&gt;&gt;&gt; &nbsp; &nbsp; VNIC will be connected to a default minimal profile defined in the<br>&gt;&gt;&gt; &nbsp; &nbsp; system, regardless the permissions the user has on the network.<br>&gt;&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; What is a 'default minimal profile' ? I would rather have a VNIC with no<br>&gt;&gt; profile associated with it.<br>&gt; <br>&gt; The 'default minimal profile' refers to a vnic profile with the lower average bandwidth.<br>&gt; <br>&gt; With the approach you've suggested, any imported VM/Template from an earlier to 3.3 version <br>&gt; 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>&gt; And for 3.1 we'll have to drop such vnics since network 'none' isn't supported.<br>&gt; <br>&gt;&gt;<br>&gt;&gt;&gt; If failed to find any matching vNic profile, the vnic's profile will be set<br>&gt;&gt;&gt; with 'none'.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; &nbsp; &nbsp; When a Template is created from a VM the VNIC Profile will be kept<br>&gt;&gt;&gt; &nbsp; &nbsp; along with the VNIC. When a VM is created from template the VNIC<br>&gt;&gt;&gt; &nbsp; &nbsp; Profiles will be taken from the template's VNICs.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; ----- Original Message -----<br>&gt;&gt;&gt;&gt; From: "Livnat Peer" &lt;lpeer@redhat.com&gt;<br>&gt;&gt;&gt;&gt; To: "engine-devel" &lt;engine-devel@ovirt.org&gt;, "Ofri Masad"<br>&gt;&gt;&gt;&gt; &lt;omasad@redhat.com&gt;<br>&gt;&gt;&gt;&gt; Cc: "Mike Kolesnik" &lt;mkolesni@redhat.com&gt;, "Moti Asayag"<br>&gt;&gt;&gt;&gt; &lt;masayag@redhat.com&gt;, "Oved Ourfalli" &lt;oourfali@redhat.com&gt;<br>&gt;&gt;&gt;&gt; Sent: Sunday, June 30, 2013 3:59:37 PM<br>&gt;&gt;&gt;&gt; Subject: VNIC profiles<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; Hi,<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; We are working on adding VNIC profiles as part of the work to add VNIC<br>&gt;&gt;&gt;&gt; QoS.<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; We need to define some of the system behavior followed by this change,<br>&gt;&gt;&gt;&gt; here is my take -<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; Editing a profile -<br>&gt;&gt;&gt;&gt; --------------------<br>&gt;&gt;&gt;&gt; A user should be able to edit the profile properties (including profile<br>&gt;&gt;&gt;&gt; name) while VMs are attached and are using this Profile (reference<br>&gt;&gt;&gt;&gt; should be done by id).<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; Changing the network though is a bit more tricky as long as we don't<br>&gt;&gt;&gt;&gt; have a way to distinguish between running and current configurations I<br>&gt;&gt;&gt;&gt; think it could be very confusing to the user. Especially since we<br>&gt;&gt;&gt;&gt; support dynamic wiring so the behavior IMO is unpredictable.<br>&gt;&gt;&gt;&gt; I think it should be blocked at this point.<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; Edit a VNIC / change a VNIC profile -<br>&gt;&gt;&gt;&gt; ------------------------------------<br>&gt;&gt;&gt;&gt; Changing the profile a VM is using while the VM is running should behave<br>&gt;&gt;&gt;&gt; like dynamic wiring (changing the VM network while it is running).<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; Remove a Profile -<br>&gt;&gt;&gt;&gt; -------------------<br>&gt;&gt;&gt;&gt; Is only valid if all VMs that are using this profile are in status down.<br>&gt;&gt;&gt;&gt; It should update all VMs to point to no profile which should behave like<br>&gt;&gt;&gt;&gt; none network today.<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; I see no reason to support a profile on a none network at this point.<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; The above is also relevant for upgrade flow (upgrading none network to<br>&gt;&gt;&gt;&gt; point to no profile)<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; Removing a Network -<br>&gt;&gt;&gt;&gt; ----------------------<br>&gt;&gt;&gt;&gt; should remove all profiles on that network<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; VM snapshot/import/export -<br>&gt;&gt;&gt;&gt; --------------------------<br>&gt;&gt;&gt;&gt; We should handle VMs that are pointing to a network directly for b/w<br>&gt;&gt;&gt;&gt; compatibility.<br>&gt;&gt;&gt;&gt; we need to select first profile that is on that network that the user<br>&gt;&gt;&gt;&gt; has permissions on.<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; I assume there are more, comments are welcome<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; Thanks, Livnat<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br><div><br></div></blockquote><div><br></div></div></body></html>