XCP-ng 8.1.0 beta now available!



  • @stormi
    Your help is much appreciated!
    I was able to yum install sm-additional-drivers. Excellent. I rebooted and the fstab was still saying ext3. This is shown below. To test further, I deleted my SR (a 6TB disk) which was EXT3; used parted and other commands to create a new partition which was EXT4 (shown below) and then used the following:
    xe sr-create content-type=user name-label="Store1" shared=false device-config:device=/dev/sdc1 type=ext

    It created EXT3 LVM2_member type storage repository.

    So, that's my question. How to create an EXT4 SR?

    Thanks.

    I hope my testing shown below is helpful.

    You asked where I found the outdated docs. I found the outdated instructions I used the first time around at the top of the page in https://xcp-ng.org/forum/topic/839/new-ext4-driver-please-test-it
    +++++++++++++++++++++++++++++++++++++++++++++++
    (updated on 2019-02-07 to add installation of updated sm and sm-rawhba packages)

    We introduced in testing, a new extra driver, using ext4. Please test it and give your feedback. To install it:

    yum install sm-additional-drivers sm sm-rawhba --enablerepo='xcp-ng-updates_testing'
    xe-toolstack-restart
    

    My testing follows:
    Removing the SR Storage Repository since it was installed as EXT3.

    [19:05 xcpng ~]# xe sr-list name-label=Store1
    uuid ( RO) : d3f2dfbc-9682-cd51-79c2-be4e1d6c0923
    name-label ( RW): Store1
    name-description ( RW):
    host ( RO): xcpng
    type ( RO): ext
    content-type ( RO): user

    [19:05 xcpng ~]# xe pbd-list sr-uuid=d3f2dfbc-9682-cd51-79c2-be4e1d6c0923
    uuid ( RO) : 0bd2ecc8-78d4-4479-57db-45634b317bd3
    host-uuid ( RO): 67782a24-14f6-4a91-bc53-23d1bb3bfb62
    sr-uuid ( RO): d3f2dfbc-9682-cd51-79c2-be4e1d6c0923
    device-config (MRO): device: /dev/sdc1
    currently-attached ( RO): true

    [19:09 xcpng ~]# xe pbd-unplug uuid=0bd2ecc8-78d4-4479-57db-45634b317bd3

    [19:12 xcpng ~]# xe sr-forget uuid=d3f2dfbc-9682-cd51-79c2-be4e1d6c0923

    Rebooted server

    [19:26 xcpng ~]# cat /etc/fstab
    LABEL=root-glwhel / ext3 defaults 1 1
    LABEL=BOOT-GLWHEL /boot/efi vfat defaults 0 2
    LABEL=swap-glwhel swap swap defaults 0 0
    LABEL=logs-glwhel /var/log ext3 defaults 0 2

    [19:31 xcpng ~]# parted /dev/sdc mklabel gpt
    Warning: The existing disk label on /dev/sdc will be destroyed and all data on
    this disk will be lost. Do you want to continue?
    Yes/No? yes
    Information: You may need to update /etc/fstab.

    [19:34 xcpng ~]# parted -a opt /dev/sdc mkpart primary ext4 0% 100%
    Information: You may need to update /etc/fstab.

    [19:35 xcpng ~]# mkfs.ext4 -L STORE1 /dev/sdc1
    mke2fs 1.42.9 (28-Dec-2013)
    Filesystem label=STORE1
    OS type: Linux
    Block size=4096 (log=2)
    Fragment size=4096 (log=2)
    Stride=0 blocks, Stripe width=0 blocks
    183144448 inodes, 1465130240 blocks
    73256512 blocks (5.00%) reserved for the super user
    First data block=0
    Maximum filesystem blocks=3613392896
    44713 block groups
    32768 blocks per group, 32768 fragments per group
    4096 inodes per group
    Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
    102400000, 214990848, 512000000, 550731776, 644972544

    Allocating group tables: done
    Writing inode tables: done
    Creating journal (32768 blocks): done
    Writing superblocks and filesystem accounting information: done

    [19:36 xcpng ~]# lsblk -f
    NAME FSTYPE LABEL UUID MOUNTPOINT
    nvme0n1
    ??nvme0n1p1 LVM2_mem hmjtFc-J03x-cGWz-60no-nQMY-WAcs-yfYuCK
    ??XSLocalEXT--b64be29d--7b4e--4c35--23ad--c2835d6d68c9-b64be29d--7b4e--4c35--23ad--c2835d6d68c9
    ext3 4932e44b-06ab-45d6-944c-f95c57aa40c0 /run/sr-mo
    sdd
    ??sdd1 ext4 STORE2 d6b13b13-4066-4470-add7-ffe978b24a50

    sdc
    ??sdc1 ext4 STORE1 80901059-41fa-4089-aa8f-65e6929afea6
    sda LVM2_mem DzdKkZ-zud3-MXhE-GFCS-hzB4-a6K5-NU2qoQ
    ??XSLocalEXT--dd84c28d--6d39--ac03--28d3--99c18c24aa68-dd84c28d--6d39--ac03--28d3--99c18c24aa68
    ext3 ebd0226e-01da-4ec6-8dd4-1bdb007bcb92 /run/sr-mo
    [19:37 xcpng ~]#
    [19:40 xcpng ~]# lsblk -d -fs /dev/sdc1
    NAME FSTYPE LABEL UUID MOUNTPOINT
    sdc1 ext4 STORE1 80901059-41fa-4089-aa8f-65e6929afea6

    [19:45 xcpng ~]# xe sr-create content-type=user name-label="Store1" shared=false device-config:device=/dev/sdc1 type=ext
    2cd1c746-c5aa-1376-66bb-5fb9d89ad689

    [19:48 xcpng ~]# lsblk -d -fs /dev/sdc1
    NAME FSTYPE LABEL UUID MOUNTPOINT
    sdc1 LVM2_member Oe9xwf-UqrZ-FeNI-CZwI-7Sn0-ua21-nvDPGy


  • XCP-ng Team

    Hi,

    Please use the correct Markdown syntax (code blocks) so it would be easier to read you.



  • @stormi said in 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
    

  • XCP-ng Team

    What files do you have in /etc/yum.repos.d? Does /etc/yum.repos.d/xcp-ng.repo correctly point at 8.1? Is there another repo file there that points à 8.0?



  • @stormi

    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:
    SR_HAS_NO_PBDS(OpaqueRef:d259a8f1-6bbe-46bb-b135-447bb352e888)

    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.


  • XCP-ng Team

    31c5e1ae-11d3-4bae-af37-004af53ca2e7-image.png


  • XCP-ng Team

    @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 ext SR.

    That SR was created as ext4. No need for sm-additional-drivers for 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 ext local SRs, XCP-ng uses an LVM layer on top, hence the output of lsblk.


  • XCP-ng Team

    About VM autostart: as @r1 found out, there's a missing symlink in an XCP-ng updated via yum. That's a bug in the upgrade scripts that is present in CH 8.1 too, and we reported it to them.

    Here's the fix:

    systemctl enable xapi-wait-init-complete.service
    


  • @stormi @r1

    great find! I tested this, and it appears to at least correct the issue with autostart.
    Thanks


  • XCP-ng Team

    Thanks for the feedback 🙂



  • @stormi @r1 thank you! I do not have the equipment to test with ch8.1 but this is solved already I see. great catch


  • XCP-ng Team

    Indeed, also we reported the problem to Citrix, they might provide a fix one way or another.


  • XCP-ng Team

    Announcement about our former experimental ext4 SR driver:

    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.

    The sm-additional-drivers package 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-create command on purpose. Any attempt to create a SR of type ext4 will result in an error with a message that explains that you need to use the ext type instead.

    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.



  • @stormi
    what's the status of the xfs driver? Are you expecting that to be removed/deprecated as well?


  • XCP-ng Team

    No, it's still there and still working but not officially supported.


  • XCP-ng Team

    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).




Log in to reply
 

XCP-ng Pro Support