XO Lite: building an embedded UI in XCP-ng

olivierlambert

@saneece You do NOT (ie don't) need an internet connection.

buldamoosh

I've installed certificates for all of the hosts in my pool however - I still get the "Unreachable hosts" message when I sign in to the pool master. I assume that this is the case since it references the hosts by IP address rather than hostnames. Is there something I should be doing to reference the FQDN of the hosts rather than the IP address?

bnerickson

Hello,

XO Lite directs requests/comments here, so here are my first impressions after upgrading to 8.3:

The Good:

Very happy a builtin option for managing a host will be provided!
Worked well for basic tasks I needed to do post reinstall to version 8.3.
Interface is snappy and I like the look and feel so far.
Console view was VERY helpful.
The inclusion of the an XOA url at the top is a nice addition.

For the following, I'm coming at this from the perspective of "what do I need to be able to do if I can't get XOA started for reason X." I know some of this might fall into the "What XO Lite is NOT," but I still think that all of the following are host-specific and not pool-specific if that makes sense. So if it's a vm-on-a-host-based task, it's fair game, but if it's something like vm migration then it's not. Also, if the intent is for this to replace XCP-NG center for single-host deployments (which is a great goal imo), then some of the request below fit the bill of what XCP-NG Center supports, but are also in the "What XO Lite is NOT" list. There's a bit of an identity crisis. Also, apologies if anything below is present and I missed it.

The Missing/"Required":

Creating/Attaching/Detaching VDBs manually. I have one VM that, after upgrades, needs to have an SR re-attached that is not backed up. This may also be useful in instances when a troublesome VDB might need to be rebuilt or reattached in an emergency.
Configuring passthrough NICs on the host and passing them through to a VM would be nice, but I don't remember if XCP-NG Center did this or not. Similar to above, I have a VM that I passthrough a number of NICs to, and while it's scripted for now it'd be nice to be able to do as a one-off if needed.
Restoring From Snapshops. If my host crashes and one of my dependent VMs (maybe even the XOA VM) is corrupted, I want to be able to restore a snapshot to get back into working order ASAP.
Modifying the MAC address on VM interfaces is another emergency-based task I'd like. The MAC address can change when restoring a VM from backup, but if the environment depends on the MAC address staying the same for "reasons" (say the IPv6 address of the VM is derived from SLAAC), then being able to set this manually in XO Lite can mean the difference between a quick restore and a lengthy restoration effort while DNS is updated etc...
Likewise, being able to add/remove NICs to a VM is desired. So I guess this can be combined with the above bullet-point: Add/Remove/Modify NICs on a VM.
The ability to create and destroy a VM on the host.
The ability to backup and restore a VM from backup LOCALLY as one-offs (not scheduled). The use-case is a situation where XOA is accidentally blown away, then the administrator can mount the backup location on the host (via NFS/Samba) and kick-off a one-off restore where they specify the location on (remote) disk.

Nice To Have:

XCP-NG Center has a really nice view if you click on a Host and select the Search tab. It shows all of the VMs CPU/Memory statistics, so at-a-glance you can see if a VM is misbehaving. I very occasionally use this (relying on monitoring), but it has come in handy.
It'd be nice if XO Lite could be tied into LDAP for authentication like XOA can be while still "preferring" root login. This would help provide some level of auditing for organizations that want to make sure no funny business is being done on a host-level. Otherwise, I think organizations will block access to this after the host has started.
Since XO Lite is focused on the host-level, it'd be nice if certain host-specific configurations like SNMP and Syslog were configurable in XO Lite.
It'd be great if there were a tab to show the running/failed systemd services on the XCP-NG Host.
Similarly, it'd be nice if there were a host Logs tab to display logs at a configurable level (ERROR, WARN, INFO) for the host in-question.

The Small Improvements:

I wish the XOA link pointed to the XOA server's FQDN or is configurable as opposed to linking to the XOA server's IP address. Might be a quick fix?
Very ignorable and too late in the game, but I wish XO Lite had a different name. The "Lite" in the name gives it the likeness of being an intentionally neutered application. I'd have preferred something like "XCP-NG Local Host Manager" (XLHM) or similar that makes it clear the tool will be developed to allow configuring JUST the host in question.

Anyway, great work team. Looking forward to improvements to XO Lite in the future.

pdonias

Hi @bnerickson, thanks for the detailed feedback!

XO Lite is still in its early development phase, which means that most of your suggestions are actually already planned, including VBD management, editing MAC addresses, creating/deleting VMs and snapshots, and more generally everything that can be done through XAPI calls.

Regarding your other suggestions, keep in mind that XO Lite is running without a server behind. This means that the persistency is only in the browser. For instance, I'm not sure how an LDAP login would work, since the credentials you're entering in XO Lite are your host's credentials, and XO Lite needs that to communicate with XAPI.

Regarding XOA's FQDN, you can already do that by configuring the field publicUrl in your XOA's config:

[http]
# Public URL to connect to this XO
#
# This optional entry is used to communicate to external entities (e.g. XO Lite)
# how to connect to this XO.
#
# It SHOULD be defined in case the IP address of the current machine is not
# good enough (e.g. a domain name must be used or there is a reverse proxy).
publicUrl = 'https://xoa.company.lan'

In any case, I took note of your feedback and we'll have to discuss some of your other interesting suggestions, both for XO Lite and XO 6, like showing more of the host's logs, failed services, etc.
Thanks!

buldamoosh

This post is deleted!

john.c

@pdonias said in XO Lite: building an embedded UI in XCP-ng:

Hi @bnerickson, thanks for the detailed feedback!

XO Lite is still in its early development phase, which means that most of your suggestions are actually already planned, including VBD management, editing MAC addresses, creating/deleting VMs and snapshots, and more generally everything that can be done through XAPI calls.

Regarding your other suggestions, keep in mind that XO Lite is running without a server behind. This means that the persistency is only in the browser. For instance, I'm not sure how an LDAP login would work, since the credentials you're entering in XO Lite are your host's credentials, and XO Lite needs that to communicate with XAPI.

Regarding XOA's FQDN, you can already do that by configuring the field publicUrl in your XOA's config:
[http]
# Public URL to connect to this XO
#
# This optional entry is used to communicate to external entities (e.g. XO Lite)
# how to connect to this XO.
#
# It SHOULD be defined in case the IP address of the current machine is not
# good enough (e.g. a domain name must be used or there is a reverse proxy).
publicUrl = 'https://xoa.company.lan'
In any case, I took note of your feedback and we'll have to discuss some of your other interesting suggestions, both for XO Lite and XO 6, like showing more of the host's logs, failed services, etc.
Thanks!

The LDAP authentication could be implemented by having PAM use LDAP client authenticate against an LDAP backend. The necessary configuration and/or could be preserved or converted (as required) across each upgrade from ISO media.

Alternatively an OpenID client and server could be used for authentication on XCP-ng to handle federated authentication services for XCP-ng.

Also the XO Lite can be using LDAP if authentication, performed for XCP-ng is based on OpenID or PAM.

olivierlambert

It's a big no. We don't want cram the Dom0 with more components, if you want LDAP or external auth, you should use XO

bnerickson

@pdonias Thanks for the feedback and fix for the XOA FQDN thing! I figured most of my suggestions were pretty standard and already on the docket.

Regarding LDAP: I think @john-c put it best. XO-Lite would probably need to be integrated w/PAM in the backend for LDAP support. It sounds like the serverless (?) architecture of XO Lite runs counter to the request and said design may hinder future feature requests that ask for tighter host visibility. Regardless, XO Lite in its current form will definitely be invaluable as more and more of the items currently on the docket are implemented

john.c

@olivierlambert said in XO Lite: building an embedded UI in XCP-ng:

It's a big no. We don't want cram the Dom0 with more components, if you want LDAP or external auth, you should use XO

My suggestion during development of XCP-ng 8.3 of implementing the ability to lock down XCP-ng (thus XO Lite) so you can only login through XOA would, in this case be a good compromise, to handle the business deployments (especially large ones).

Especially if implementing LDAP support is a big no!

@bnerickson Would what I suggested above be a good compromise, to having LDAP on XCP-ng?

john.c

This post is deleted!

bnerickson

@john-c It sounds like you're suggesting that XO Lite should only allow login if XoA is unavailable. Otherwise, if XoA is available (and able to communicate via xapi with the host in question) then login to XO Lite on that host is blocked.

In theory as an optional feature for security-conscious organizations, maybe? I'm not sure how feasible the implementation would be though.

john.c

@bnerickson said in XO Lite: building an embedded UI in XCP-ng:

@john-c It sounds like you're suggesting that XO Lite should only allow login if XoA is unavailable. Otherwise, if XoA is available (and able to communicate via xapi with the host in question) then login to XO Lite on that host is blocked.

In theory as an optional feature for security-conscious organizations, maybe? I'm not sure how feasible the implementation would be though.

The suggestion was inspired by the lock down feature of VMware ESXi. It was first discussed when people were talking about alternative to VMware NSX to be used with Vates VMS.

To get the background checkout this link https://xcp-ng.org/forum/topic/8605/similar-product-to-vmware-nsx/.

@olivierlambert Would you care to comment on the feasibility of implementing my suggestion if LDAP is a no go?

olivierlambert

Lockdown is a possibility, in any case I would consider direct mgmt network access a no go. The role of XOA is to make that secure bridge to outside, without exposing mgmt.

I think you can already disable XO Lite UI if you want. Anyway, that's not a top priority now, there's 1000 things to do first.

john.c

@olivierlambert said in XO Lite: building an embedded UI in XCP-ng:

Lockdown is a possibility, in any case I would consider direct mgmt network access a no go. The role of XOA is to make that secure bridge to outside, without exposing mgmt.

I think you can already disable XO Lite UI if you want. Anyway, that's not a top priority now, there's 1000 things to do first.

With lockdown I mean having it disable XO Lite by disabling, not showing the login form and doing so while showing a message instead. Also the lockdown feature would disable SSH (as well as inhibit enabling it) as this would by pass Xen Orchestra on the XCP-ng host. For instance a message such as:-

"Logging into XO Lite is unavailable due to restrictions to only be able to login via Xen Orchestra. Please login to the Xen Orchestra instance managing this pool.

olivierlambert

Yes, that would be possible I think

john.c

@olivierlambert said in XO Lite: building an embedded UI in XCP-ng:

Yes, that would be possible I think

The disabling, not showing the login form while displaying the message would occur before even attempting the login. Don't forget the SSH and/or console would need disabling and/or inhibiting login to prevent by pass of Xen Orchestra as well as part of the lockdown.