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. Regards, -- Nicolas Sebrecht