Bug 1532686 - [RFE] Enable host console on alternate ovirt host IP
Summary: [RFE] Enable host console on alternate ovirt host IP
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: Host-Deploy
Version: 4.2.0.2
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
: ---
Assignee: bugs@ovirt.org
QA Contact: Lukas Svaty
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-01-09 15:21 UTC by jas
Modified: 2020-06-26 16:38 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2020-04-01 14:47:38 UTC
oVirt Team: Virt
Embargoed:
rbarry: ovirt-4.5?
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?


Attachments (Terms of Use)

Description jas 2018-01-09 15:21:25 UTC
In my oVirt setup,after kickstarting each oVirt host, the host is solely on a private network.  I then add the hosts to engine, and additional networks are enabled (eg. an external network).  The host from which I'm accessing engine is on the external network, but not on the internal host network.

The new "Host Console" feature in oVirt tries to access the ovirt Host using its "hostname", but in my case, that hostname is on a private network that the client cannot access.  I would like to request that when configuring ovirt host that an optional "external hostname" or "console hostname" be allowed, which, when defined, would be used instead of the default "hostname" when accessing host console. 

Without similar functionality for "display" network, I wouldn't be able to access console on my VMs, but because the display network is defined as the external network, I can get at my display network from my office, or, because of the firewall, from my home IP.

I can't make my ovirt host default network the external network because I am using an 802.11ad network bond for the external network, and this must be configured from within ovirt before it can be used.

Comment 1 Michal Skrivanek 2018-01-11 13:31:22 UTC
I'd rather reuse the Host Display Address Override feature for that. Should be ok without any further changes

Comment 2 Tomas Jelinek 2018-01-11 14:31:29 UTC
yep, considering it will be properly renamed.

Comment 3 jas 2018-01-11 15:34:25 UTC
Actually, I can withdraw this RFE.  If ovirt-cockpit-sso is working properly (which it wasn't at the time when I tried), then I can access host console from my web browser, even though my local host does not have access to the private network.  That being said, if I was not using ovirt-cockpit-sso, then this would be a desirable feature because my browser *would* need direct access to the private network in order to view host console.

Comment 4 Dan Kenigsberg 2018-04-01 13:13:05 UTC
(In reply to jas from comment #0)
> I can't make my ovirt host default network the external network because I am
> using an 802.11ad network bond for the external network, and this must be
> configured from within ovirt before it can be used.

Would you elaborate on that? in ovirt-4.2, particularly if you are using ovirt-node, it should be fine to define the bond via cockpit and later consume it by ovirt.

Moving to virt, to decide if we need to exptend "Host Console" feature.

Comment 5 jas 2018-04-12 12:55:52 UTC
My hosts are kickstarted CentOS 7.4 with oVirt installed.  I configure the external network bond through engine, then after the hosts are kickstarted, and added manually to engine, the external network is configured to each host.  This creates a chicken and egg problem if I want to use the external network as my main ovirt network.  I want to use ovirt to configure the bond, but I need the bond activate to access the host.

I haven't tried changing the default network to the external one but I'd prefer to leave the default network as a private network for now.  I still think that the name that ovirt uses to access the host console should be configurable just like the display network.  I just don't necessarily need to depend on that functionality anymore because of cockpit.

Comment 7 Ryan Barry 2018-11-06 22:35:40 UTC
Moving out because there's an easy workaround, though this may be desirable later

Comment 8 Michal Skrivanek 2020-03-18 15:47:01 UTC
This bug didn't get any attention for a while, we didn't have the capacity to make any progress. If you deeply care about it or want to work on it please assign/target accordingly

Comment 9 Michal Skrivanek 2020-03-18 15:51:46 UTC
This bug didn't get any attention for a while, we didn't have the capacity to make any progress. If you deeply care about it or want to work on it please assign/target accordingly

Comment 10 Michal Skrivanek 2020-04-01 14:47:38 UTC
Closing old bug. Please reopen if still relevant/you want to work on it.


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