Bug 858654 - engine: VM with optional network should be launched on a host which does not have this network
engine: VM with optional network should be launched on a host which does not ...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
3.1.0
Unspecified Linux
high Severity high
: ---
: ---
Assigned To: Muli Salem
GenadiC
network
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-19 06:41 EDT by itzikb
Modified: 2016-02-10 14:54 EST (History)
11 users (show)

See Also:
Fixed In Version: SI20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-04 15:07:50 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Network
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description itzikb 2012-09-19 06:41:17 EDT
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:
Comment 3 Muli Salem 2012-09-20 02:26:23 EDT
Proposed fix in:

http://gerrit.ovirt.org/#/c/7992/3
Comment 4 Simon Grinberg 2012-09-20 06:05:36 EDT
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.
Comment 5 RHEL Product and Program Management 2012-09-20 06:25:53 EDT
Product Management has reviewed and declined this request.
You may appeal this decision by reopening this request.
Comment 6 Simon Grinberg 2012-09-23 09:52:53 EDT
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.
Comment 10 Muli Salem 2012-09-23 11:04:08 EDT
Patch restored in:

http://gerrit.ovirt.org/#/c/7992/3
Comment 12 GenadiC 2012-10-11 04:37:31 EDT
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

Note You need to log in before you can comment on or make changes to this bug.