XCP-ng
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login
    1. Home
    2. Popular
    Log in to post
    • All Time
    • Day
    • Week
    • Month
    • All Topics
    • New Topics
    • Watched Topics
    • Unreplied Topics

    • All categories
    • R

      Incremental backup fails on a 3 TB qcow2 disk: value is out of range ... <= 4294967295 in computeVhdBatAndFileSize

      Watching Ignoring Scheduled Pinned Locked Moved Unsolved Backup
      4
      1 Votes
      4 Posts
      148 Views
      R
      Update: switching the remote to “multiple data blocks” fixed the 2 TiB overflow. The full backup now succeeds (≈1.1M blocks, 13 h) and file restore works. However, the next incremental always falls back to a full The delta export request gets no data for exactly 5 minutes, then undici’s body timeout fires. So “can’t compute delta” is actually a timeout. My guess is that the host takes more than 5 min to compute the qcow2 delta of a 3 TB disk before sending the first byte (single SATA SMR disk, local EXT SR). XapiQcow2StreamSource.close() throws because the source was never initialized. In earlier attempts, this may have left tapdisks for the qcow2 snapshots stuck and attached to dom0 (tap-ctl close timing out, SR_BACKEND_FAILURE_1200). I had to kill them manually before the VBDs could be unplugged. CBT is disabled on all VDIs. Is there a way to increase this timeout for qcow2 delta exports, or is a fix planned (e.g. keep-alive while the delta is computed)? Is the close() error on an uninitialized source a known bug? Same environment as above (XO from sources 3923756ff, XCP-ng 8.3.0, sm-3.2.12-25.1).
    • TeddyAstieT

      Enabling Intel APICv for better performance

      Watching Ignoring Scheduled Pinned Locked Moved Development
      2
      3 Votes
      2 Posts
      253 Views
      T
      Sharing some results. I enabled this on my homelab server, a Dell R630 with Intel Xeon E5-2630 v4 (Broadwell). No adverse impact noticed. The CDM results on Windows is higher than previous runs however, I do not go in depth with I/O benchmarking. (I am using the latest win-pv-drivers on Windows and the rust-based guest tools on Linux) Controller is in HBA mode. VM SR is using SMAPIv3 (ZFS, RAID-0, noop scheduler) [image: R630_XCP-ng_APICv.png] CDM results. Windows Server 2019 4 vCPU/8GB RAM/single VHD: [image: 2610_WIN2019_ZFS.png] I installed ScyllaDB on Alma Linux 10.2 (4 vCPU/8GB RAM & two VHDs, ScyllaDB uses a dedicated drive for data) with io_uring enabled and noop scheduler set on VM. Here are the IOTune results from the ScyllaDB installation: Measuring sequential write bandwidth: 826 MiB/s (deviation 13%) Measuring sequential read bandwidth: 1061 MiB/s (deviation 6%) Measuring random write IOPS: 50791 IOPS (deviation 11%) Measuring random read IOPS: 62977 IOPS (deviation 16%)