Hi Olivier. Thank you for taking your time to respond. I highly appreciate the effort you and your team put into these projects.
I'm sorry, I haven't been able to update myself enough lately.
Is XO6 released already?
Also: XO Lite comes with 8.3, doesn't it? We're not there yet, still on 8.2.1.
I reverted to reinstalling the machine I wasn't able to login to. Then I was able to set a password without any "special characters", and the "old" terminal worked good enough.
Thank you.
Issue with Logging into RedHat Systems via Xen Orchestra Console
We’re trying to host RedHat systems (RHEL 9) using XCP-ng and Xen Orchestra. During installation, we typically set a root password generated by a password manager, which tends to be complex. Since SSH root login is disabled by default, the first login must happen via Xen Orchestra’s Console tab.
Problem:
1. Entering complex passwords is impossible due to issues with modifier keys (e.g., Shift, AltGr, Opt/Alt, Caps Lock). These keys seem to “stick” randomly, making it difficult to type certain characters accurately.
2. The console seems to misinterpret or reject certain characters as invalid at the password prompt, further complicating login attempts.
3. This issue makes it impossible to log in and use Xen Orchestra with RedHat 9 systems. However, the same process works without issue on Debian 12.
Details:
• XO Version: Commit 21f06
• XCP-ng Version: 8.2.1 release/yangtze/master/58 (updating is not an option at this time)
• Keyboard Setup:
• Default: Swedish keyboard layout, macOS (Chrome browser)
• Also tried: US keyboard layout, Windows 11 (Chrome browser)
• No success with any combination.
At the time of writing, this issue seems to specifically affect RedHat 9 systems in this environment. Any suggestions or workarounds to resolve this problem?
Thanks, yes of course. I got excited about fixing my problems and reported too early 
Well, the VM has been working fine since the export / import. I can see both drives.
Although the VM running fine, since the last post I had to address two related VDIs that had been connected to the Control Domain. One being million_D and the other million_D (with a camera icon). These probably ended up here because of a aborted / faulty snapshot or backup. I disconnected them .. checked a few things ... and then forgot them. Everything is running fine now.
For future googlers: During the problem solving, I found out some pretty helpful info using tail -f /var/log/SMlog.
To me, this issue is solved. Thank you all for the feedback.
After export and import I can actually see a reference to both drives. Although they seem to be disconnected.
I'll see what I can do about it.
For me it was here:
On my (only) host: /run/sr-mount/35ecc7ae-4e98-58c1-5ed3-2c22c649bd32
(where 35ecc etc is one of my SRs)
There was a file named coalesce_ followed by a VDI UUID.
I moved this file out of the directory, rather than deleting it .. moving slowly.
@Darkbeldin
I actually solved the coalesce issue yesterday. After removing a certain VDI (not related) and a coalesce lock file, SR Stor 15K managed to process the coalesce backlog. After that the backups started to process again.
Due to poor performance I choose to postpone exporting or backing up the million VM. When I do, I'll see if I can restore it with both XVDA and XVDB.
I'll copy the important contents from the million VM before I do anything. That way I can improvise and dare to move forward in anyway i need to - even if I'll have to reinstall the VM. But first I always try to make an attempt at resolving the problem rather than just throwing away and redo from start. That way I learn more about the platform.
While troubleshooting something else, backups also struggling, me and my friend found out that the host doesn't seem to coalesce successfully on the SR Stor 15K:
Sep 22 22:27:16 ninja SMGC: [1630] In cleanup
Sep 22 22:27:16 ninja SMGC: [1630] SR 35ec ('Stor 15K') (44 VDIs in 5 VHD trees):
Sep 22 22:27:16 ninja SMGC: [1630] *3fc6e297(40.000G/85.000K)
Sep 22 22:27:16 ninja SMGC: [1630] *4cce0cbb(100.000G/88.195G)
Sep 22 22:27:16 ninja SMGC: [1630] *81341eac(40.000G/85.000K)
Sep 22 22:27:16 ninja SMGC: [1630] *0377b389(40.000G/85.000K)
Sep 22 22:27:16 ninja SMGC: [1630] *b891bcb0(40.000G/85.000K)
Sep 22 22:27:16 ninja SMGC: [1630]
Sep 22 22:27:16 ninja SMGC: [1630] *~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
Sep 22 22:27:16 ninja SMGC: [1630] ***********************
Sep 22 22:27:16 ninja SMGC: [1630] * E X C E P T I O N *
Sep 22 22:27:16 ninja SMGC: [1630] ***********************
Sep 22 22:27:16 ninja SMGC: [1630] gc: EXCEPTION <class 'util.SMException'>, Parent VDI 6b13ce6a-b809-4a50-81b2-508be9dc606a of d36a5cb0-564a-4abb-920e-a6367741 574a not found
Sep 22 22:27:16 ninja SMGC: [1630] File "/opt/xensource/sm/cleanup.py", line 3379, in gc
Sep 22 22:27:16 ninja SMGC: [1630] _gc(None, srUuid, dryRun)
Sep 22 22:27:16 ninja SMGC: [1630] File "/opt/xensource/sm/cleanup.py", line 3264, in _gc
Sep 22 22:27:16 ninja SMGC: [1630] _gcLoop(sr, dryRun)
Sep 22 22:27:16 ninja SMGC: [1630] File "/opt/xensource/sm/cleanup.py", line 3174, in _gcLoop
Sep 22 22:27:16 ninja SMGC: [1630] sr.scanLocked()
Sep 22 22:27:16 ninja SMGC: [1630] File "/opt/xensource/sm/cleanup.py", line 1606, in scanLocked
Sep 22 22:27:16 ninja SMGC: [1630] self.scan(force)
Sep 22 22:27:16 ninja SMGC: [1630] File "/opt/xensource/sm/cleanup.py", line 2357, in scan
Sep 22 22:27:16 ninja SMGC: [1630] self._buildTree(force)
Sep 22 22:27:16 ninja SMGC: [1630] File "/opt/xensource/sm/cleanup.py", line 2313, in _buildTree
Sep 22 22:27:16 ninja SMGC: [1630] "found" % (vdi.parentUuid, vdi.uuid))
Sep 22 22:27:16 ninja SMGC: [1630]
Sep 22 22:27:16 ninja SMGC: [1630] *~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
Sep 22 22:27:16 ninja SMGC: [1630] * * * * * SR 35ecc7ae-4e98-58c1-5ed3-2c22c649bd32: ERROR
Maybe my problem is related to the host rather than XO? Back to troubleshooting .. and any input is appreciated.
I appreciate your effort to help.
Seems like this is an odd one. Maybe the backup / restore strategy is the most efficient way forward here, as long as the backup sees both drives.
Interesting, and a bit strange that XVDA (million_C) is-a-snapshot ( RO): true when earlier I wasn't able to list it as a snapshot at all. Oh, maybe the command makes a difference between VM snapshot and a VDI snapshot. Still learning. It returned:
XVDA:
XVDB:
Obviously there are some differences regarding the snapshot info but also million_C is missing info regarding vhd-parent. Not that I understand yet what that means.
Thank you.
@Danp said in VM, missing disk:
@MRisberg OIC. I got confused when looking at this earlier. My suspicion is that the
is-a-snapshotparameter has been erroneously set on the VDI.
Interesting. Do you know of a way to check what parameters have been set for a VDI on the host?
Running the xe snapshot-list command did not return XVDA or million_C as having a snapshot, although XO indicates this with the camera icon.
Edit: Also, how did you get "is-a-snapshot" show up highlighted as in your post? Looked nice
I built a new XO machine, compiled from sources with build f1ab62524 (xo-server 5.102.3, xo-web 5.103.0 as per 2022-09-21 17:00). Made no difference in regards to being able to see the XVDA drive.
The host knows the drive is there, XO doesn't.
I've already tried this: reset toolstack + restart the host.
Is there a way of resetting the interface / API on the host that XO talks to? (Not sure what API that would be.)
@Darkbeldin said in VM, missing disk:
@MRisberg What is weird is that we don't see xvda on the VM, could you show us the disks inside the VM?
Thank you @Darkbeldin for chiming in.
Disks and drivers inside of the VM:
And the result of this command on your host
xe vm-disk-list uuid=UUID of your VM
The command you provided returned this:
Here we can see XVDA (named million_C because it's the C drive within the VM).
So .. the hosts knows it's there, obviously, as I can boot the machine. Is there something other I can do than restarting both the toolstack and XO that you can come up with?
XO interface trouble?
I have a VM that boots and operates okay. But I'm not able to migrate the attached disks from one storage to another.
VM, Disks: Missing boot drive, xvda. VM is still able to boot from it though.
VM, Stats: Clearly showing stats for both a xvda (C:) and xvdb (D:).
Storage, Disks: Showing the specific disk missing from the VM.
There's a camera icon probably indicating there should be a snapshot of the drive in question. I'm trying to work with that, finding the snapshot and merging or deleting it, solving the problem myself.
As limited my knowledge is around Xen, I'm not able to find out where to go from this situation though. I've tried a few things in the terminal of the host but Xen and XO seem to be conflicting as when the commands below doesnt acknowledge there's a snapshot for the machine above at all, only another one:
I'm a bit lost: Can anyone point me in the direction of commands to run to trouble shoot this kind of problem?
Kind regards,
MRisberg
@olivierlambert Well, for now, I'm mostly playing around with this tech to teach myself about it, gaining experience and coming up with ideas. Maybe someday I'll be able to return some profit with the business I'm building / trying to figure out (hosting game servers). Then I'll sign up for some Pro support - and maybe then we can work on the concept of HA XO 
I understand what you're saying. I think I can come up with a good enough way of achieving the HA I'm looking for.
Anyway, thanks for takning the time to respond. I understand your schedule is busy.
@olivierlambert Hi and thank you for your answer.
I don't understand why you say high availability for XO is not a point. I've set up two XOs for the XCP-ng hosts we have. Whenever I want to do service on one of the XO machines, like installing updates or rebooting for other purposes, the management GUI is instead made to be presented from the other XO machine.
We really want this, works great for us. The only question to us here is if the export and import feature is to be used and relied on or if there is another way to synchronize the two - as the changes to the configuration increases.
Redeploying a new machine whenever a primary XO goes down is not good enough strategy for our business model as that could easily take hours or even days if the right people are not present should the XO go down for instance.
What are the best practices regarding achieving a synchronized configuration of multiple Xen Orchestra machines?
(I'm thinking a little bit of two domain controllers that serves one AD configuration, achieving high availability ...)
I have two separate machines serving XO, offering redundancy when updating and rebooting for instance. I'm somewhat concerned about making mistakes when time is of essence and all the ACL configurations is needed to be done twice, every time.
Is it Settings > Export and a job that copies and imports on the other machine, or is there another, "more refined", way?
They need to be able to get users / groups using LDAP.
Lurker for quite some time. First post I guess. Thank you so much for maintaining Xen / XCP-ng. Looking forward to supporting the project moneywise as soon as I start making enough money with my newborn business.
