@stormi I've placed the tarballs here https://student.oedu.se/~peder/xcp-ng/
I changed the static min to 512M, to match the Fedora case, but it still failed.
Olivier, I'm not using Xen Storage motion but I am using two old Lenovo L430 Thinkpads as "servers" so that could be part of the problem.
I'll install a new C7 guest and see if the problem persists.
Stopping xo-server before compiling shouldn't be necessary unless someone tries to use XO while it's building.
That said, I would recommend building the source under /usr/src or ~/src or something and then moving the files ( mv * ) to something like /opt/xen-orchestra-DATE (or git revision)
Then use "stow" to create symlinks in /usr/local, like this
stow -d /opt/ -t /usr/local xen-orchestra-DATE
The stow command is in the CentOS repository or can be downloaded and compiled separately from any GNU mirror.
Make sure the /etc/xo-server/ config points to the relevant symlinks in /usr/local and restart xo-server
This way you can keep a number of different XO versions available in /opt and if there's a problem with any one of them you simply run
stow -D -d /opt -t /usr/local xen-orchestra-BADVERSION
to delete the symlinks to the bad version and
stow -d /opt -t /usr/local xen-orchestra-GOODVERSION
to create links to the old, good one and then restart xo-server
When it's time to update the XO build go to the, now seemingly empty, source folder and run
git reset HEAD --hard
to repopulate the working directory and then
git pull && yarn && yarn build
Stopping xo-server before compiling shouldn't be necessary unless someone tries to use XO while it's building.
That said, I would recommend building the source under /usr/src or ~/src or something and then moving the files ( mv * ) to something like /opt/xen-orchestra-DATE (or git revision)
Then use "stow" to create symlinks in /usr/local, like this
stow -d /opt/ -t /usr/local xen-orchestra-DATE
The stow command is in the CentOS repository or can be downloaded and compiled separately from any GNU mirror.
Make sure the /etc/xo-server/ config points to the relevant symlinks in /usr/local and restart xo-server
This way you can keep a number of different XO versions available in /opt and if there's a problem with any one of them you simply run
stow -D -d /opt -t /usr/local xen-orchestra-BADVERSION
to delete the symlinks to the bad version and
stow -d /opt -t /usr/local xen-orchestra-GOODVERSION
to create links to the old, good one and then restart xo-server
When it's time to update the XO build go to the, now seemingly empty, source folder and run
git reset HEAD --hard
to repopulate the working directory and then
git pull && yarn && yarn build
Did you remember to restart xo-server after the build had finished?
If you're compiling the new version in the same directory as the old one it's good practice to save a copy of the old one first, before doing the git pull.
I did do it on my install, that's why I'm suggesting it.
The default values made me thing I had a semi-transparent film all over my display.
My install is on a physical machine (a laptop) so I don't know how I'd take a proper screenshot.
I don't think a phone photo would show the difference.
Unless it's an environmental decision to make the xsconsole as dim and washed out as possible, to save power, my humble suggestion would be to multiply the fgBright values by 1.249 to get 999,431,372, if my math is correct, and set fgNormal to something like 930,930,930
fgDark could either remain at its current values or be set to fbBright
I used tgt and no authentication before so I can't say.
I decided to try targetcli and authentication when I installed 8 beta.
No, it's probably not a blocker.
Connecting an iSCSI SR in xsconsole fails if there's a discovery password.
It works if I disable the authentication.
It works in XenOrchestra if I attach it as a new SR (With auth) AND have the same discovery username and password in the ACL of the iqn.
That still doesn't work in xsconsole.
My iscsi server uses targetcli-fb/LIO.
I see, there IS a reattach feature but it's not entirely obvious.
When I click on the white chain, blue background "Reattach SR" icon it creates an iSCSI SR named "[object HTMLInputElement]" and the xsconsole says it's "detached and not usable by this host".
So it doesn't appear to work as intended, at least not in git version e88848c44 from a few days back.
If I click the "Create" button after having clicked "Reattach" I get a warning about existing VDIs will be deleted and that's also what happens when I go through with it.
I also suggest placing button next to the "Create" one. Like this
AFAIK XO can only create a new storage repository, it would be nice to being able to attach an existing one as well.
@olivierlambert The actual values I posted aren't that important, it was the overall look I was going for.
I don't have commit rights to anything so I can only come up with ideas.
If you decide to use your colors I can't do anything about it, except for modifying my own copy of the program, and if you choose to go with my suggestion you can adjust any specific value to taste and theme-fidelity.
Last suggestion.
Replacing the current /usr/lib64/xsconsole/XConsoleConfig.py values with the ones in the insert gives something like below.
It accents the red/brownish color seen on the website.
