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

Corrupted VHDs on file based SR

    XMLWordPrintable

Details

    • Bug
    • Resolution: Unresolved
    • Major
    • None
    • 7.3
    • VM Lifecycle
    • 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

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

            Dates

              Created:
              Updated: