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. 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. Is file system maintenance on the hypervisor volume storing the VM images redundant to the VM's own file system consistancy utilities. Regards, Jamie Ian Fargen
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
On Wed, Jul 03, 2013 at 12:24:24PM +0200, Nicolas Sebrecht wrote:> 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.Of course if you think that having 2 fscks is overkill, then you could also change the way you storage images on the host. eg, use an LVM volume for each guest disk, instead of storing them in /var/lib/libvirt/images. That way the guest OS is 100% responsible for its data integrity and you don't waste I/O bandwidth by having duplicate fscks in host & guest. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|