Jump to content
Welcome to our new Citrix community!
  • 0

Error exporting Windows VMs snapshots


Gelber de Arruda Junior

Question

Hi buddies,

 

I have a PowerEdge r530 running XenServer 7.1 build 137272c with Raid 5 (with 3 disks of 1tb SAS, total 2tb of usable space) in production for 4 years. It is running 2
Windows Servers 2012, 1 Freebsd and 2 Ubuntu VMs. Every month a made a snapshot of every relevant VMs and export it to a file in my local machine deleting the old ones
snapshots and files. Since last month I am able to export the snapshots of unix like machines only. When I try to export a snapshot of a Windows Server a get the following
error message:

"export failed due to a block checksum mismatch, please retry later"

Exporting the unix like system works well. I have some experience with Linux but only know the basic of XenServer(I used the command line only to make VMs start
automaticaly, googling about the error I also needed to search what is SR).

I discovered the following command to check the disk:

 

 vhd-util check --debug -n /dev/XSLocalEXT-c6e4dc71-e5c5-9fd5-a1ec-af539c13c4a2/c6e4dc71-e5c5-9fd5-a1ec-af539c13c4a2

 

And this is the output...

 

primary footer invalid: invalid cookie
/dev/XSLocalEXT-c6e4dc71-e5c5-9fd5-a1ec-af539c13c4a2/c6e4dc71-e5c5-9fd5-a1ec-af539c13c4a2 appears invalid; dumping metadata
Failed to open /dev/XSLocalEXT-c6e4dc71-e5c5-9fd5-a1ec-af539c13c4a2/c6e4dc71-e5c5-9fd5-a1ec-af539c13c4a2: -22

/dev/XSLocalEXT-c6e4dc71-e5c5-9fd5-a1ec-af539c13c4a2/c6e4dc71-e5c5-9fd5-a1ec-af539c13c4a2 appears invalid; dumping headers

VHD Footer Summary:
-------------------
Cookie              :
Features            : (0x00000000)
File format version : Major: 0, Minor: 0
Data offset         : 0
Timestamp           : Fri Dec 31 22:00:00 1999
Creator Application : ''
Creator version     : Major: 0, Minor: 0
Creator OS          : Unknown!
Original disk size  : 0 MB (0 Bytes)
Current disk size   : 0 MB (0 Bytes)
Geometry            : Cyl: 0, Hds: 0, Sctrs: 0
                    : = 0 MB (0 Bytes)
Disk type           : None
Checksum            : 0x0|0xffffffff (Bad!)
UUID                : 00000000-0000-0000-0000-000000000000
Saved state         : No
Hidden              : 0

VHD Header Summary:
-------------------
Cookie              :
Data offset (unusd) : 0
Table offset        : 0
Header version      : 0x00000000
Max BAT size        : 0
Block size          : 0 (0 MB)
Parent name         :
Parent UUID         : 00000000-0000-0000-0000-000000000000
Parent timestamp    : Fri Dec 31 22:00:00 1999
Checksum            : 0x0|0xffffffff (Bad!)

I had no idea what I had to do from here, so I tryed:

 

vhd-util repair --debug -n /dev/XSLocalEXT-c6e4dc71-e5c5-9fd5-a1ec-af539c13c4a2/c6e4dc71-e5c5-9fd5-a1ec-af539c13c4a2

 

And that is the output:

 

error opening /dev/XSLocalEXT-c6e4dc71-e5c5-9fd5-a1ec-af539c13c4a2/c6e4dc71-e5c5-9fd5-a1ec-af539c13c4a2: -22

 

I need some help to solve this problem.

Link to comment

4 answers to this question

Recommended Posts

  • 0

Sounds like it's time to do some checking with LVM. Perhaps your LVM metadata got corrupted... do you have any backups or archives under the associated subdirectories under /etc/lvm/ ? Id start with lvdisplay, pvdisplay, vgdisplay, etc. to see how your LVM  setup currently appears. Trying to copy the storage to another SR would also be a good experiment to see if it can be completed successfully or not.

 

-=Tobias

  • Like 1
Link to comment
  • 0

Yea, looks like something is going on. I would shut it down and try to do a full copy of the VM and see if you

could work around the error that way. The downside is it may not come back up again or may not copy. But

that is why we do backups, right ? Not being able to do a snapshot is a bad thing.

 

--Alan--

 

Link to comment
  • 0
On 1/10/2020 at 9:00 PM, Tobias Kreidl said:

Sounds like it's time to do some checking with LVM. Perhaps your LVM metadata got corrupted... do you have any backups or archives under the associated subdirectories under /etc/lvm/ ? Id start with lvdisplay, pvdisplay, vgdisplay, etc. to see how your LVM  setup currently appears. Trying to copy the storage to another SR would also be a good experiment to see if it can be completed successfully or not.

 

-=Tobias

 

Thank you for your reply!

I forgot mentioning that all VMs are working perfectly.

 

Here is my /etc/lvm:

[root@xenserver- lvm]# ls -ltras
total 216
 4 -rw-r--r--  1 root root  2244 Feb 16  2017 lvmlocal.conf
 4 drwx------  2 root root  4096 Feb 16  2017 archive
 4 drwxr-xr-x  2 root root  4096 May 16  2017 profile
88 -rw-r--r--  1 root root 82209 May 16  2017 lvm.conf.orig
 4 drwxr-xr-x  2 root root  4096 May 16  2017 master
88 -rw-r--r--  1 root root 82209 May 16  2017 lvm.conf
 4 drwxr-xr-x  7 root root  4096 May 16  2017 .
 4 drwx------  2 root root  4096 May 16  2017 cache
 4 drwx------  2 root root  4096 May 16  2017 backup
12 drwxr-xr-x 96 root root 12288 Jan 10 00:03 ..

 

 

lvdisplay

  --- Logical volume ---
  LV Path                /dev/XSLocalEXT-c6e4dc71-e5c5-9fd5-a1ec-af539c13c4a2/c6e4dc71-e5c5-9fd5-a1ec-af539c13c4a2
  LV Name                c6e4dc71-e5c5-9fd5-a1ec-af539c13c4a2
  VG Name                XSLocalEXT-c6e4dc71-e5c5-9fd5-a1ec-af539c13c4a2
  LV UUID                QpB6iE-kNj7-lT37-U9Yc-T3dv-voOM-NyPriW
  LV Write Access        read/write
  LV Creation host, time xenserver-togafujm, 2017-05-16 14:16:02 -0300
  LV Status              available
  # open                 1
  LV Size                1.78 TiB
  Current LE             466044
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:0


 pvdisplay

  --- Physical volume ---
  PV Name               /dev/sda3
  VG Name               XSLocalEXT-c6e4dc71-e5c5-9fd5-a1ec-af539c13c4a2
  PV Size               1.78 TiB / not usable 14.98 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              466044
  Free PE               0
  Allocated PE          466044
  PV UUID               WkL3T9-rSrD-l8fD-ZNdC-KtFr-qBE1-3z49qo

vgdisplay

  --- Volume group ---
  VG Name               XSLocalEXT-c6e4dc71-e5c5-9fd5-a1ec-af539c13c4a2
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  2
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               1
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               1.78 TiB
  PE Size               4.00 MiB
  Total PE              466044
  Alloc PE / Size       466044 / 1.78 TiB
  Free  PE / Size       0 / 0
  VG UUID               PNcne0-YLPL-doMr-gFnZ-2ncN-lArE-XcxcVC

This is the onlly SR in my network. I'm going to setup a new one today.

 

On 1/10/2020 at 5:43 PM, Alan Lantz said:

Yea, looks like something is going on. I would shut it down and try to do a full copy of the VM and see if you

could work around the error that way. The downside is it may not come back up again or may not copy. But

that is why we do backups, right ? Not being able to do a snapshot is a bad thing.

 

--Alan--

 

 

Thank you for your reply! I'm not bold enough to do a full shut down but I rebooted without changes. I'll do some backups today to make other attempts.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...