Bug 1402433

Summary: Network type configured in Compute profiles not honoured during provisioning a new host in libvirt
Product: Red Hat Satellite Reporter: Peter Tselios <tselios.petros>
Component: ProvisioningAssignee: satellite6-bugs <satellite6-bugs>
Status: CLOSED ERRATA QA Contact: Sanket Jagtap <sjagtap>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.2.4CC: bbuckingham, bkearney, inecas, mhulan, sjagtap
Target Milestone: UnspecifiedKeywords: Triaged
Target Release: Unused   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Compute Profile
none
New Host
none
Interfaces of new host in WebUI
none
QE Compute profile
none
QE Host interfaces tab
none
QE Created host in libvirt none

Description Peter Tselios 2016-12-07 14:42:54 UTC
Created attachment 1229081 [details]
Compute Profile

Description of problem:
I have created a Compute profile named "100-Cluster Node". 
This profile has 2 network interfaces, both of them using NAT (the libvirt default network and an internal network for my nodes, see pic1). 

When I try to create a new host from the WebUI, I select the aforementioned Compute Profile (pic2). However, in the interfaces tab, I noticed that the network of the 1st interface is not the default NAT, but a Bridged interface (pic3)

Except of this problem, MAC address is empty. 

Version-Release number of selected component (if applicable):
6.2.4

How reproducible:
100%

Steps to Reproduce:
1. Follow the steps described above

Actual results:
New host interfaces are wrong.

Expected results:
New host interfaces should follow what is specified in the compute profile. 

Additional info:
If you try to build the host, if fails with the following error:

Failed to power up a compute Local KVM (Libvirt) instance z1.testenv: Call to virDomainCreateWithFlags failed: Cannot get interface MTU on '': No such device

The error makes perfect sense if you consider the fact that libvirt has no bridges configured. 

I suspect that this is only a WebUI bug. When I tried to create the host via the hammer, host was created:

hammer host create --hostgroup="Typical RHEL 7" --compute-resource="Local KVM" --compute-profile="100-Cluster Node" --location "Lab" --root-pass "pass" --organization-id 1 --lifecycle-environment="Production" --content-view "RHEL 7 Latest" --name z1

Host created

Checking the VM details the VM was created the way I want it.

Comment 1 Peter Tselios 2016-12-07 14:43:31 UTC
Created attachment 1229082 [details]
New Host

New host tab

Comment 2 Peter Tselios 2016-12-07 14:44:06 UTC
Created attachment 1229083 [details]
Interfaces of new host in WebUI

Comment 4 Peter Tselios 2017-02-16 11:55:20 UTC
I can confirm that I have the same issue when I provision hosts in vCenter. 
I can post a screenshot, but bofore doing so, please turn the attachments as private. I don't want to have them in the wild.

Comment 5 Bryan Kearney 2017-05-19 17:14:05 UTC
Peter, you can make the attachement private when you uplaod it.

Comment 6 Bryan Kearney 2017-05-19 17:14:13 UTC
Peter, you can make the attachement private when you uplaod it.

Comment 9 Sanket Jagtap 2017-11-29 13:07:02 UTC
Build: Satellite 6.3 snap 26

Verified.

PFA 

1) Compute profile with two NAT interface
2) Host had two NAT interface Host Interfaces tab
3) Host Info from libvirt

Comment 10 Sanket Jagtap 2017-11-29 13:07:34 UTC
Created attachment 1360296 [details]
QE Compute profile

Comment 11 Sanket Jagtap 2017-11-29 13:08:56 UTC
Created attachment 1360297 [details]
QE Host interfaces tab

Comment 12 Sanket Jagtap 2017-11-29 13:09:36 UTC
Created attachment 1360299 [details]
QE Created host in libvirt

Comment 13 Bryan Kearney 2018-02-21 17:32:51 UTC
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA.

For information on the advisory, and where to find the updated files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:0336

Comment 14 Bryan Kearney 2018-02-21 17:33:23 UTC
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA.

For information on the advisory, and where to find the updated files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:0336