Uploaded image for project: 'XenServer Org'
  1. XenServer Org
  2. XSO-842

Corrupted VHDs on file based SR

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: To Do (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 7.3
    • Fix Version/s: None
    • Component/s: VM Lifecycle
    • Labels:
      None

      Description

      Making a VM.snaphost sometimes trigger "bad" VHDs. But I'm not able to figure out what's happening exactly. Everything in the VHD footer/header seems OK, but vhd-util displays an issue with an invalid cookie.

      Here is the output:

      # vhd-util check --debug -n /var/run/sr-mount/efc3406f-88a0-75a7-3b50-9b25469e8b5f/66b3e64d-8ad9-4f3d-840e-e9ae82f06a15.vhd
      primary footer invalid: invalid cookie
      /var/run/sr-mount/efc3406f-88a0-75a7-3b50-9b25469e8b5f/66b3e64d-8ad9-4f3d-840e-e9ae82f06a15.vhd appears invalid; dumping metadata
      VHD Footer Summary:
      -------------------
      Cookie              : conectix
      Features            : (0x00000002) <RESV>
      File format version : Major: 1, Minor: 0
      Data offset         : 512
      Timestamp           : Sun Jan 28 19:00:00 2018
      Creator Application : 'tap'
      Creator version     : Major: 1, Minor: 3
      Creator OS          : Unknown!
      Original disk size  : 122880 MB (128849018880 Bytes)
      Current disk size   : 122880 MB (128849018880 Bytes)
      Geometry            : Cyl: 61680, Hds: 16, Sctrs: 255
                          : = 122878 MB (128847052800 Bytes)
      Disk type           : Differencing hard disk
      Checksum            : 0xffffee32|0xffffee32 (Good!)
      UUID                : c673f661-e68f-409b-9352-2197808afa64
      Saved state         : No
      Hidden              : 0
      
      VHD Header Summary:
      -------------------
      Cookie              : cxsparse
      Data offset (unusd) : 18446744073709
      Table offset        : 1536
      Header version      : 0x00010000
      Max BAT size        : 61440
      Block size          : 2097152 (2 MB)
      Parent name         : efce6cac-2c1d-4f99-aee6-56720a1f385d.vhd
      Parent UUID         : 6c325d43-0217-4afa-a9be-d10ca96318ad
      Parent timestamp    : Sun Jan 28 18:59:21 2018
      Checksum            : 0xffffd764|0xffffd764 (Good!)
      
      VHD Parent Locators:
      --------------------
      locator:            : 0
             code         : PLAT_CODE_MACX
             data_space   : 512
             data_length  : 49
             data_offset  : 255488
             decoded name : ./efce6cac-2c1d-4f99-aee6-56720a1f385d.vhd
      
      locator:            : 1
             code         : PLAT_CODE_W2KU
             data_space   : 512
             data_length  : 84
             data_offset  : 256000
             decoded name : ./efce6cac-2c1d-4f99-aee6-56720a1f385d.vhd
      
      locator:            : 2
             code         : PLAT_CODE_W2RU
             data_space   : 512
             data_length  : 84
             data_offset  : 256512
             decoded name : ./efce6cac-2c1d-4f99-aee6-56720a1f385d.vhd
      
      VHD Batmap Summary:
      -------------------
      Batmap offset       : 247808
      Batmap size (secs)  : 15
      Batmap version      : 0x00010002
      Checksum            : 0xffffffff|0xffffffff (Good!)
      
      

      I'm problably missing something big.

      FYI: a vhd-util repair works perfectly, but I'm not sure to understand what's happening in the first place, and what repair actually repair.

        Attachments

          Activity

            People

            Assignee:
            chandrikas Chandrika Srinivasan
            Reporter:
            olivierlambert Olivier Lambert
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Dates

              Created:
              Updated: