Description of problem: When the engine chooses on which host to start the VM on, he chooses a host that reports has all the networks the guest need for starting the VM. If no such host exist then the engine does not start the VM. In a case the network is optional and the network is not attached to an interface on the Host the Host will not be chosen. There should be a way to tell the engine to choose a host even if the network is not attached so that On demand attachment will be available. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Proposed fix in: http://gerrit.ovirt.org/#/c/7992/3
No ack on this approach. This is a short term hack, and there are many things that may go wrong here that will translate to failure to run VM. Especially in a mixed environment. The proper short term solution would be something like: 1. Connect all the NICs of the VM to a network that exists on the host, this may be the rhevm network that always exists on all of the host. 2. Use the custom properties of the VM to indicate which of the NICs should be connected to Mellanox dynamic NIC (ignoring the network configured in RHEV Manager), and provide the network identification. 3. The hook should use this custom properties to convert the NIC in #1 to the required MACVTAP nic (new) and connect it to the dynamic nic (as it does today) This way: * No changes are required from RHEV Manager. * If the VM is started in any other environment, proper selection of the network to which the NIC originally connected (in RHEV Manager) may allow for mixed environments. We have taken this approach with CISCO UCS, which has similar requirements. An example hook will soon be uploaded to ovirt git.
Product Management has reviewed and declined this request. You may appeal this decision by reopening this request.
I had a face to face with Itzik today, Due to the holiday season, we may hit timing issues if we find out that the solution in comment #4 is not appropriate/hard to implement by Mellanox in a timely manner. So Let's have it done. However let's try to shoot for cluster level config. Can be done in two methods: 1. Cluster properties 2. A config parameter that accepts a list of clusters for which this behavior is allowed. I prefer two since this should not be the main line. This parameter comes with a disclaimer of use on your own risk or a certified partner solution (like Mellanox) running on these clusters. Muli, how complex is it to do? If it's too complex then we can go with the existing patch, however this must come with a disclaimer similar to the above for the entire system.
Patch restored in: http://gerrit.ovirt.org/#/c/7992/3
Verified in SI20 that if the "OnlyRequiredNetworksMandatoryForVdsSelection" parameter is configured as False, then running VM fails in engine component, otherwise (when the parameter is configured as True) running VM fails in VDSM component