XCP-ng 8.1.0 beta now available!

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)

stormi

Please create an issue there: https://github.com/xcp-ng/xenadmin/issues

olivierlambert

What's the info reported by xe sr-param-list uuid=<UUID OF THIS SR>?

onur

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

What's the info reported by xe sr-param-list uuid=<UUID OF THIS SR>?

xe sr-param-list uuid=3fe64d91-5349-ac86-d9b7-aa9dcf813cea
uuid ( RO)                    : 3fe64d91-5349-ac86-d9b7-aa9dcf813cea
              name-label ( RW): ssd240Toshiba
        name-description ( RW):
                    host ( RO): OB1
      allowed-operations (SRO): VDI.enable_cbt; VDI.list_changed_blocks; unplug; plug; PBD.create; VDI.disable_cbt; update; PBD.destroy; VDI.resize; VDI.clone; VDI.data_destroy; scan; VDI.snapshot; VDI.mirror; VDI.create; VDI.destroy; VDI.set_on_boot
      current-operations (SRO):
                    VDIs (SRO): 5da0c967-657f-43f2-8e4a-7cb80b7938ef; 2dd44491-b458-4119-a024-a48ace2a23e3; 05910aa1-8c5e-4af7-8ffc-11dbdcae5116; 60a7602d-ec61-4ef4-9db1-0f3fdbcd43f9
                    PBDs (SRO): 96e685a7-f5cc-32fa-8289-b10e4a8ea4f5
      virtual-allocation ( RO): 481036337152
    physical-utilisation ( RO): 153255415808
           physical-size ( RO): 192280748032
                    type ( RO): ext
            content-type ( RO): user
                  shared ( RW): false
           introduced-by ( RO): <not in database>
             is-tools-sr ( RO): false
            other-config (MRW): i18n-original-value-name_label: Local storage; i18n-key: local-storage
               sm-config (MRO): devserial: scsi-3500080dc0133cdc2
                   blobs ( RO):
     local-cache-enabled ( RO): true
                    tags (SRW):
               clustered ( RO): false

stormi

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

type ( RO): ext

As expected. The ext type has no information of the FS version in its name.

onur

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

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

type ( RO): ext

As expected. The ext type has no information of the FS version in its name.
already created bug for XCP-ng center, but it looks like system is not reporting ext type

olivierlambert

Yes, it was just to be sure it's a XCP-ng Center issue Now we are 100% sure.

borzel

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

I think we should not trust I assume the ext4 uses internally the same xapi-ID like the old ext.

stormi

A better label would just be "ext" so that it works both for ext3 and ext4.

pnunn

Running two hosts on the beta in my lab and so far have had no issues at all (touch wood). Looking forward to this hitting production.

P.

olivierlambert

Thanks for the feedback!

cnaumer

Same here, a single host as well as two host pool are running fine so far. All upgraded via yum from 7.6.

nikade

Did anyone try the performance of VM export/import yet?
I am really excited to see the increase since this was one of the improvements mentioned by Citrix.

pnunn

I've not imported full VM's but have imported a number of disks and they worked reasonably quickly I guess, although I have only very limited reference from another much more powerful setup to compare with.

Peter.

stormi

This thread is now dead, long live the 8.1 RC thread!