Categories

  • All news regarding Xen and XCP-ng ecosystem

    145 Topics
    5k Posts
    Y
    @dinhngtu Yes, I've submitted a false positive report here: https://www.bitdefender.com/en-us/business/submit

  • Everything related to the virtualization platform

    1k Topics
    15k Posts
    samuelolavoS
    Hi, I am trying to understand whether I am hitting a bug, a known limitation, or a configuration issue when using a large QCOW2 VDI on an LVM SR. Environment I have an existing VM with several virtual disks. Most of the data disks are approximately 2 TiB and were created as VHD VDIs. They have been working correctly for a long time. Example: virtual-size: ~2 TiB image-format: vhd vdi_type: vhd Inside the guest, several of these disks are combined using LVM to provide a larger filesystem. The Xen Orchestra instance is built directly from source and kept up to date from the upstream source tree. The storage repository involved is an existing local LVM SR that has been in production for several years. It was not newly created for this test and has been used successfully with VHD VDIs over that period. I now need to add significantly more storage and would prefer to avoid continuing to add multiple ~2 TiB VHD disks. I therefore created a new 15 TiB virtual disk using the current Xen Orchestra build. The disk was automatically created as QCOW2: virtual-size: 16492674416640 image-format: qcow2 vdi_type: qcow2 Storage Repository The VDI is stored on the existing local LVM SR. The SR has approximately: Total size: ~44 TiB Free after creating the new VDI: ~4 TiB There was sufficient free space before creating the new 15 TiB VDI. At the LVM level, the QCOW2 LV is present and has the expected size: QCOW2-<uuid> ~15.00 TiB Problem When the 15 TiB QCOW2 disk is attached to the VM, the VM fails to start. Xen Orchestra reports: SR_BACKEND_FAILURE_46 The VDI is not available [opterr=['XENAPI_PLUGIN_FAILURE', 'make_chain_rw', 'CommandException', 'Input/output error']] The same VM starts normally when this QCOW2 VDI is removed or detached. All the existing VHD disks on the same SR continue to work normally. Relevant SMlog output The Storage Manager detects the QCOW2 LV and can query its size. For example: blockdev --getsize64 /dev/<VG>/QCOW2-<uuid> succeeds. It also executes: qemu-img measure \ -O qcow2 \ --output json \ -o cluster_size=65536 \ --size 16492674416640 successfully. The failure happens during VDI activation: BLKTAP2:<function VDI._activate_locked ...>: EXCEPTION <class 'XenAPI.Failure'>, ['XENAPI_PLUGIN_FAILURE', 'make_chain_rw', 'CommandException', 'Input/output error'] self._make_chain_rw() File "/opt/xensource/sm/LVMSR.py", line ..., in _make_chain_rw raise Failure(result['ErrorDescription']) Current VM disk layout Simplified layout: System disk VHD Home disk VHD ~2 TiB VHD ~2 TiB VHD ~2 TiB VHD ~2 TiB VHD ~2 TiB VHD ~2 TiB VHD ~2 TiB VHD ~2 TiB VHD 15 TiB QCOW2 <-- new disk causing the failure The existing VHD disks work correctly. The problem only appeared after adding the large QCOW2 VDI. Questions Is a 15 TiB QCOW2 VDI on an existing local LVM SR expected to work reliably on current XCP-ng 8.3? Is mixing VHD and QCOW2 VDIs on the same VM and on the same SR fully supported? Could the fact that this is an older LVM SR created several years ago make any difference with the newer QCOW2 support? Does the following error correspond to any known QCOW2/LVM issue? make_chain_rw CommandException Input/output error Are there specific minimum versions of xapi, sm, blktap, or other storage components required for large QCOW2 VDIs? Would a different SR type be recommended for VDIs of this size, or should this configuration work normally? The Xen Orchestra instance is built from source and kept current, so I am mainly trying to determine whether the issue is on the XCP-ng/storage side rather than the XO side. I can provide additional anonymized SMlog, package versions, qemu-img output and LVM diagnostics if required. Thanks.

  • All Xen Orchestra related questions/reports

    3k Topics
    29k Posts
    A
    @poddingue Thank you!!!

  • Our hyperconverged storage solution

    52 Topics
    811 Posts
    J
    Now for my question that I would love input on. This DRBD dashboard states that there are some things out of sync. [image: a1be50f7-d656-40db-a572-e2fb6d68a68a-image.jpeg] Which is fed from this metric [image: 37b05625-285e-496d-acb1-39184b0c3bd8-image.jpeg] However linstor says differently. jonathon@jonathon-framework:~$ linstor --controllers=10.2.0.10,10.2.0.11,10.2.0.12,10.2.0.13,10.2.0.14 r l | grep xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 │ xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 │ ovbh-pprod-xen01 │ DRBD,STORAGE │ Unused │ Ok │ UpToDate │ Yes │ │ xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 │ ovbh-pprod-xen02 │ DRBD,STORAGE │ InUse │ Ok │ UpToDate │ Yes │ │ xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 │ ovbh-pprod-xen05 │ DRBD,STORAGE │ Unused │ Ok │ UpToDate │ Yes │ jonathon@jonathon-framework:~$ linstor --controllers=10.2.0.10,10.2.0.11,10.2.0.12,10.2.0.13,10.2.0.14 v l | grep xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 │ xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 │ ovbh-pprod-xen01 │ xcp-sr-linstor_group_thin_device │ 0 │ 1013 │ /dev/drbd1013 │ 300.26 GiB │ Unused │ UpToDate │ Established(2) │ │ xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 │ ovbh-pprod-xen02 │ xcp-sr-linstor_group_thin_device │ 0 │ 1013 │ /dev/drbd1013 │ 300.26 GiB │ InUse │ UpToDate │ Established(2) │ │ xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 │ ovbh-pprod-xen05 │ xcp-sr-linstor_group_thin_device │ 0 │ 1013 │ /dev/drbd1013 │ 300.26 GiB │ Unused │ UpToDate │ Established(2) │ What is this pv? K8s worker vdi. Cool jonathon@jonathon-framework:~$ linstor --controllers=10.2.0.10,10.2.0.11,10.2.0.12,10.2.0.13,10.2.0.14 kv s xcp-sr-linstor_group_thin_device | grep d07a41d6-0aa2-49a5-a241-b755c6daa3d8 │ xcp/volume/d07a41d6-0aa2-49a5-a241-b755c6daa3d8/metadata │ {"name_label": "OVBH-VPROD-K8S01-WORKER02", "name_description": "", "is_a_snapshot": false, "snapshot_of": "", "snapshot_time": "", "type": "user", "vdi_type": "vhd", "read_only": false, "metadata_of_pool": ""} │ │ xcp/volume/d07a41d6-0aa2-49a5-a241-b755c6daa3d8/not-exists │ 0 │ │ xcp/volume/d07a41d6-0aa2-49a5-a241-b755c6daa3d8/volume-name │ xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 │ I notice it only states that some xcp-volumes-* are out of sync, and none of the pvs created by piraeus operator. Curious to know if anyone has any thoughts on this?

  • Non-English speakers

    37 Topics
    136 Posts
    J
    @AtaxyaNetwork Merci pour tes recherches ! Oui "cd_label" serait cool comme ajout au plugin ce qui permet sur les distro type Fedora/Redhat de ne pas avoir de boot_command à gérer