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

XenServer 7.6 | Windows Server disk consistency check taking ages


Hi all,


I have an issue (?) on my XenServer 7.6 (Build date 2018-08-24, DBV 2018.0829) with a Windows VM.


Every time I need to reboot that VM a disk consistency check is forced. When running this consistency check, it takes ages. When viewing this from the console within XenCenter it takes around 1 second for 1 inode to be checked. With a total of 384256 inodes it will take around 106 hours to have this thing completed.

Is there a way to get this speeded up? I haven't seen that before. Of course, this disk consistency can be skipped, but every time that Windows VM reboots, it will come up again and again.

I guess that consistency check has its needs so I unlikely do want to disable that in the windows registry etc., so what I am looking for is an explanation why it is that slow during this check and what I can do to speed that up.



Link to comment

9 answers to this question

Recommended Posts

  • 0

It should not keep running each time unless it's failing to complete the disk check successfully. You should investigate to see if there are some serious errors on that device - perhaps there is some corruption that cannot be totally fixed, hence it's trying to do a repair each time. Check in particular /var/log/SMlog for clues about storage I/O errors.



Link to comment
  • 0

Hmmm, there is no reason I can think of then why it should be so slow. Dom0 resources are OK, I gather (memory and VCPUs)? That's about the only other main thing I can think of that would impact storage I/O.


You could try moving just the storage (VDI) to a different SR if you have one available and see if the behavior continues once moved to a totally different SR.



Link to comment
  • 0

Hi Tobias, thanks for your thoughts!


Like I said earlier: I already used two different storage repositories (iSCSI and local storage) and saw the same behaviour on both... :-(


Regarding: memory and vCPU:


I just did a "ps aux" on the dom0 and found:


[root@xen04 ~]# ps aux | grep 65588
65588     5528 84.2  0.4 194792 17580 ?        RLl  Jul12 3329:48 qemu-dm-53 -machine pc-0.10,accel=xen,max-ram-below-4g=4026531840,allow-unassigned=true,trad_compat=true -vnc unix:/var/run/xen/vnc-53,lock-key-sync=off -monitor null -xen-domid 53 -m size=32768 -boot order=dc -usb -device usb-tablet,port=2 -smp 16,maxcpus=16 -serial pty -display none -nodefaults -trace enable=xen_platform_log -sandbox on,obsolete=deny,elevateprivileges=allow,spawn=deny,resourcecontrol=deny -S -global PIIX4_PM.revision_id=0x1 -global ide-hd.ver=0.10.2 -global piix3-ide-xen.subvendor_id=0x5853 -global piix3-ide-xen.subsystem_id=0x0001 -global piix3-usb-uhci.subvendor_id=0x5853 -global piix3-usb-uhci.subsystem_id=0x0001 -global rtl8139.subvendor_id=0x5853 -global rtl8139.subsystem_id=0x0001 -parallel null -qmp unix:/var/run/xen/qmp-libxl-53,server,nowait -qmp unix:/var/run/xen/qmp-event-53,server,nowait -device xen-platform,addr=3,device-id=0x0002,revision=0x2,class-id=0x0100,subvendor_id=0x5853,subsystem_id=0x0002 -drive file=/dev/sm/backend/55af0fda-5844-0b28-e7f6-d33e64a32dee/ce1007a4-555c-4f6b-9359-530c00a37f31,if=ide,index=0,media=disk,force-lba=on,format=raw -drive file=,if=ide,index=3,media=cdrom,force-lba=off -device rtl8139,netdev=tapnet1,mac=3a:64:c0:52:09:43,addr=5 -netdev tap,id=tapnet1,fd=7 -device cirrus-vga,vgamem_mb=4,rombar=1,romfile=,subvendor_id=0x5853,subsystem_id=0x0001,addr=2 -vnc-clipboard-socket-fd 4 -xen-domid-restrict -chroot /var/xen/qemu/root-53 -runas 65588.1046
root     24386  0.0  0.0 112676  2284 pts/20   S+   16:43   0:00 grep --color=auto 65588
[root@xen04 ~]# 

This process is the affected VM whilst running the chkdsk procedure and was using around 85% CPU. I let the VM run the last days and ist just finished 3%...of the disk checking procedure ...  :/


I now tried the following: Booting the VM from a Windows setup iso file and ran a console there from the repair option menu. I then did the "chkdsk d: /f /r" command there and guess what: It started to run with the known good speed. So, as it is working from there fine I cannot say it is the storage repository which is causing the problem, is it? If so, it would have been that slow in the rescue mode as well, wouldn't it?


Very strange...


Anything else that could cause this behaviour?



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...