Hi Alona, I reviewed the DD of wired/unwired and I have a few questions/comments - 1. update vnic while the VM is running should be limited to cluster 3.2 (except for plug/unplug) 2. RunVM - why do we need to pass the 'linkState' property to VDSM? I think that if the link is down we should pass none as the network and if the link is up we should pass the network name, like we did so far. the link-state is internal implementation detail in the engine. 3. looking on the VDSM API - * why do we need 'type' ? * why do we need 'device'? * why do we need 'alias'? * As I wrote I think we don't need 'linkState' 4. I am missing the error handling description when the user performs - Update Vnic while changing the type for example. What is the behavior if we succeed to unplug but not plug after that, etc. 5. Updated APIs section -This section is based on the fact that we pass linkstate to vdsm which is not needed IMO, so if we change that this section should be updated accordingly. 6. The EVENT section is empty, what events should be issued to audit log? I think we should have an even for update vnic and if plug/unplug is required a second event should be issued. 7. why does link state is varchar in DB? you expect to support other option in addition to up/Down (which can be represented by 1 bit), maybe n/a status? 8. About the open issues- * About deprecation of ActivateDeactivateVmNic command - I think that we should remove this command from the backend to avoid duplicate flows and bugs etc. for Backwards compatibility we should update the clients to use the new UpdateVmNetworkInterface. the down side for that is we have to make the can do action validation more complicated (according to cluster level etc.) * If we remove ActivateDeactivateVmNic there is no need to rename it ;) Thanks, Livnat