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