XCP-ng 8.1.0 beta now available!

stormi

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.

speedy01

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

stormi

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

stormi

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

0

stormi committed to xcp-ng-rpms/sm

New leaf coalesce logic with dynamic limits

Patches backported from master

_danielgurgel

@stormi plus this update?
https://support.citrix.com/article/CTX269586

Biggen

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

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.

dariosplit

When will the final version of XCP-ng 8.1.0. be available?

olivierlambert

RC should be there pretty soon. https://github.com/xcp-ng/xcp/issues/328

stormi created this issue in xcp-ng/xcp

closed XCP-ng 8.1 (meta issue) #328

Biggen

I’ll wait till 8.1 drops before I mess with changing SR storage types.

stormi

@_danielgurgel said in XCP-ng 8.1.0 beta now available!:

@stormi plus this update?
https://support.citrix.com/article/CTX269586

That kernel update is already available on 8.1 indeed, through yum update.

stormi

@nikade said in XCP-ng 8.1.0 beta now available!:

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.

Not yet but I'd be really grateful to anyone who could benchmark this!

stormi

So, the main remaining development before RC is an updated installer to allow it to boot the alternate kernel in cases where the main kernel has issues. And also an option to boot with only 2G of RAM to workaround Ryzen APU "black screen" issues.

onur

last week I installed a new server XCP-ng 8.1. But the filesystem is still Ext3. (by the way XO connects without problem but you need XCP-ng Center Development build to access)
Today I will install a new server, what should I do to get ext4 in the filesystem?
Thanks

olivierlambert

What do you mean? SR file system or root filesystem?

onur

@olivierlambert said in XCP-ng 8.1.0 beta now available!:

What do you mean? SR file system or root filesystem?

The Local Storage for VM.
![alt text]( Ek Açıklama 2020-02-28 124558.png image url)

stormi

I don't think you should trust XCP-ng Center on this. What do you think @borzel?

Check the output of mount instead.

onur

here is the output. So I assume ext4 should be default when selecting EXT on the setup.

@stormi said in XCP-ng 8.1.0 beta now available!:

I don't think you should trust XCP-ng Center on this. What do you think @borzel?

Check the output of mount instead.

 mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,size=1270132k,nr_inodes=317533,mode=755)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
configfs on /sys/kernel/config type configfs (rw,relatime)

/dev/sda1 on / type ext3 (rw,relatime)

debugfs on /sys/kernel/debug type debugfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
xenfs on /proc/xen type xenfs (rw,relatime)
xenstore on /var/lib/xenstored type tmpfs (rw,relatime,mode=755)

/dev/sda5 on /var/log type ext3 (rw,relatime)

/dev/mapper/XSLocalEXT--3fe64d91--5349--ac86--d9b7--aa9dcf813cea-3fe64d91--5349--ac86--d9b7--aa9dcf813cea on /run/sr-mount/3fe64d91-5349-ac86-d9b7-aa9dcf813cea type ext4 (rw,relatime)

tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=256416k,mode=700)

stormi

@onur said in XCP-ng 8.1.0 beta now available!:

/dev/mapper/XSLocalEXT--3fe64d91--5349--ac86--d9b7--aa9dcf813cea-3fe64d91--5349--ac86--d9b7--aa9dcf813cea on /run/sr-mount/3fe64d91-5349-ac86-d9b7-aa9dcf813cea type ext4 (rw,relatime)

It's ok, the SR is mounted as ext4 so this means it was created as ext4.

onur

@stormi said in XCP-ng 8.1.0 beta now available!:

@onur said in XCP-ng 8.1.0 beta now available!:

/dev/mapper/XSLocalEXT--3fe64d91--5349--ac86--d9b7--aa9dcf813cea-3fe64d91--5349--ac86--d9b7--aa9dcf813cea on /run/sr-mount/3fe64d91-5349-ac86-d9b7-aa9dcf813cea type ext4 (rw,relatime)

It's ok, the SR is mounted as ext4 so this means it was created as ext4.

great thank you very much @stormi . As you suspected, XCP-ng Center shows wrong format (I guess here is a bug for XCP-ng center devs)