The 03/07/13, Jamie Fargen wrote: > Hey! > > I have some RHEL6 hypervisors and the VMs are in raw qemu image files in a > local raid array linux raid + lvm + ext3. When a kernel update is installed > a reboot is necessary, usually it has been more than 180 days since the > last reboot and the file system is fsck'd and this takes 2-3 hours. > > I am curious to know if there is any documentation that addresses the pro's > and con's of fsck'ing the volume containing /var/lib/libvirt/images. This is standard ext fsck to prevent errors after some time. In order to avoid long fsck times, we use ext4 almost everywhere (for both hypervisors and guests). I would suggest you to switch to a newer filesystem supporting fast fsck. > Could fsck make a change to the underlying file system that the guest > images are stored on, which the guest operating system may not be able to > handle when it runs its own file system maintenance, i.e. fsck or chkdsk. Talking about filesystems errors, you should assume that everything is possible. Though, the fsck on /var/lib/libvirt/images is limited to the filesystem used by the hypervisor and should not interfere with the filesystems of the guests. An exception I'm aware of is a reiserfs filesystem inside another reiserfs filesystem (/var/lib/libvirt/images is reiserfs and the guests are in reiserfs, too). > Is file system maintenance on the hypervisor volume storing the VM images > redundant to the VM's own file system consistancy utilities. As said above, it's not redondant. The fsck at hypervisor level keeps limited to the filesystem at hypervisor level.