XCP-ng 8.1.0 beta now available!
yum repolist --verbose
I just had the time to look at this and this is the output.
It is clear why I do not see the updates since the xcp-ng repo is still pointing to the 8.0
Only thing is I do not understand why it did not update to the 8.1 repo I wget before ....
xcp-ng-release-8.0.0-13.x86_64 [10:51 xenserver-2 ~]# yum repolist --verbose Loading "fastestmirror" plugin Config time: 0.833 Yum version: 3.4.3 Loading mirror speeds from cached hostfile Excluding mirror: updates.xcp-ng.org * xcp-ng-base: mirrors.xcp-ng.org Excluding mirror: updates.xcp-ng.org * xcp-ng-updates: mirrors.xcp-ng.org Setting up Package Sacks pkgsack time: 1.180 Repo-id : dell-system-update_dependent/7/x86_64 Repo-name : dell-system-update_dependent Repo-revision: 1568175395 Repo-updated : Wed Sep 11 06:16:38 2019 Repo-pkgs : 45 Repo-size : 173 M Repo-mirrors : https://linux.dell.com/repo/hardware/DSU_19.09.00/mirrors.cgi?osname=el7&basearch=x86_64&native=1 Repo-baseurl : https://linux.dell.com/repo/hardware/DSU_19.09.00/os_dependent/RHEL7_64/ Repo-expire : 21,600 second(s) (last: Wed Feb 5 22:39:17 2020) Filter : read-only:present Repo-filename: /etc/yum.repos.d/dell-system-update.repo Repo-id : dell-system-update_independent Repo-name : dell-system-update_independent Repo-revision: 1568175279 Repo-updated : Wed Sep 11 06:16:15 2019 Repo-pkgs : 697 Repo-size : 11 G Repo-baseurl : https://linux.dell.com/repo/hardware/DSU_19.09.00/os_independent/ Repo-expire : 21,600 second(s) (last: Wed Feb 5 22:39:18 2020) Filter : read-only:present Repo-exclude : dell-system-update*.i386 Repo-filename: /etc/yum.repos.d/dell-system-update.repo Repo-id : xcp-ng-base Repo-name : XCP-ng Base Repository Repo-revision: 1563798190 Repo-updated : Mon Jul 22 14:23:10 2019 Repo-pkgs : 2,073 Repo-size : 2.3 G Repo-baseurl : http://mirrors.xcp-ng.org/8/8.0/base/x86_64/, : http://updates.xcp-ng.org/8/8.0/base/x86_64/ Repo-expire : 21,600 second(s) (last: Wed Feb 5 22:39:20 2020) Filter : read-only:present Repo-filename: /etc/yum.repos.d/xcp-ng.repo Repo-id : xcp-ng-updates Repo-name : XCP-ng Updates Repository Repo-revision: 1576509411 Repo-updated : Mon Dec 16 16:16:51 2019 Repo-pkgs : 116 Repo-size : 199 M Repo-baseurl : http://mirrors.xcp-ng.org/8/8.0/updates/x86_64/, : http://updates.xcp-ng.org/8/8.0/updates/x86_64/ Repo-expire : 21,600 second(s) (last: Wed Feb 5 22:39:21 2020) Filter : read-only:present Repo-filename: /etc/yum.repos.d/xcp-ng.repo repolist: 2,931
What files do you have in
/etc/yum.repos.d/xcp-ng.repocorrectly point at 8.1? Is there another repo file there that points à 8.0?
I checked the /etc/ym.repos.d and there were repositories for CentOS-Base, -Debuginfo, -Sources, dell-system-update, epel and epel-testing. Only the dell repo was enabled, none of them contained references to xcp-ng
the other repo was like expected the xcp-ng.repo
This contained the reference to 8.0, not 8.1
I was able to make it work by again doing the copy command for the 8.1 repo I initially got with the wget from /root.
I checked and this time it did correctly replace the 8.0 repo to 8.1
I do not know why it did not do so before. There is no indication in the output the cp command did not do its' thing the first time.
Anyway, thanks for helping me and pointing in the right direction. Just started the update to 8.1 now
Ok, new issue after the update:
After the reboot of the server none of the VM's were started (including the VM with XO from the sources). I checked this in the status screen with a display connected to the server.
I downloaded the latest daily version of xcp-ng center. Was able to connect to the server but no vm's were started as suspected.
There I saw an error for my ISO repository that resides on my NAS (Samba). Trying to solve it from xcp-ng center did not work (
SM has thrown thrown a generic python exception).
I was able to start the XO vm and from there when trying to reconnect the ISO repository I got this error in the log:
When trying to reconnect from the console:
[13:21 xenserver-2 ~]# xe pbd-list uuid ( RO) : 46ee05c2-2f4d-ecbf-cbbd-5194384df464 host-uuid ( RO): 0092f4dd-09ae-41ba-98e6-2d45febf0e77 sr-uuid ( RO): ebc08968-b804-4cd5-7c1e-9e5f2c37e2de device-config (MRO): iso_path: /Xen; location: //n5550.home.xxx.yyy/Bestanden; type: cifs; vers: 3.0 currently-attached ( RO): false
[13:22 xenserver-2 ~]# xe pbd-plug uuid=46ee05c2-2f4d-ecbf-cbbd-5194384df464 Error code: SR_BACKEND_FAILURE_1200 Error parameters: , 'username',
Did some googeling and testing, but could not get the ISO repository to connect.
Finally simply deleted the repository and created a new one to the same samba share. That worked at once.
Think I might have created the issue myself bij not having ejected one "cd" from one of the vm's. Not sure is this was the cause, but will update my own documentation to eject all cd's first
- Another thing I noticed is my VM's I set to autostart at boot do not autostart anymore at all.
I already tried removing and setting the autostart option again for those vm's in XO, but after a reboot they still do not autostart
@olivierlambert Sorry. I'm new to this. Can you point me to a description of how it should look? Thanks. I appreciate your patience.
@gdixon so I just added a virtual disk to an XCP-ng 8.1 VM (I often use nested virtualisation for testing) that appeared as
sdc. I connected that XCP-ng host to Xen Orchestra and used XO to create an
That SR was created as ext4. No need for
sm-additional-driversfor ext4 in XCP-ng 8.1.
Extract from fstab
/dev/mapper/XSLocalEXT--d0866df5--f9fe--2c3a--1332--8d549468dce7-d0866df5--f9fe--2c3a--1332--8d549468dce7 on /run/sr-mount/d0866df5-f9fe-2c3a-1332-8d549468dce7 type ext4 (rw,relatime)
Note: even for
extlocal SRs, XCP-ng uses an LVM layer on top, hence the output of lsblk.
Here's the fix:
systemctl enable xapi-wait-init-complete.service
great find! I tested this, and it appears to at least correct the issue with autostart.
Thanks for the feedback
Indeed, also we reported the problem to Citrix, they might provide a fix one way or another.
Announcement about our former experimental
It is now deprecated in 8.1. For a good reason: in XCP-ng 8.1 and above, following upstream changes, the ext driver now formats new SRs as EXT4.
There is no easy way to convert an existing SR created with our driver, so those using it will need to move the VDIs out (to another SR or to export them), destroy the SR and create an EXT SR instead. Make sure to do this on XCP-ng 8.1.
sm-additional-driverspackage remains available in XCP-ng 8.1 in order to ease the transition (update: and also because it contains the XFS driver). However I've broken the
sr-createcommand on purpose. Any attempt to create a SR of type
ext4will result in an error with a message that explains that you need to use the
Our experimental driver will be completely removed in a later release, possibly XCP-ng 8.2. Unless someone convinces me to delay the removal for a good reason. I will accept reasons such as "I know I shouldn't have used the experimental driver in production, but I did and need more time to convert my SR while at the same time I really need feature xxx from XCP-ng 8.2", but I really would prefer to drop it in 8.2.
Feedback from people doing the transition is welcome to make sure we document the transition in the best way possible.
what's the status of the xfs driver? Are you expecting that to be removed/deprecated as well?
No, it's still there and still working but not officially supported.
New leaf coalesce logic using dynamic limits
I have backported patches from
sm's master branch, that implement a new, smarter, logic for leaf coalescing.
Just update your 8.1 beta, restart the toolstack, and that should be it.
Those interested in the patches, see https://github.com/xcp-ng-rpms/sm/commit/ed1a55d727846cf5777c8258e6a8f3b068e8a35b (python code).
_danielgurgel last edited by
All my SRs are using the ext4 driver.
So I just need to export the VMs, (to a NAS for example), destroy the SR, and recreate the SR, then import the VMs?
I guess I’ll need to use XCP Center for this since I use XO community running on the SR that needs to be destroyed/recreated in a Debian VM.
nikade last edited by
Did anyone try VM export/import to see how much the performance has been improved?
More interesting would be if someone tried it with 10G or making backups with XOA.