I have a partition on a raid 1 volume (call it md2) that I access via a visualization using kvm/qemu. I installed a full bootable system of Fedora (webserver).

Went to repair/check the filesystem:
I shutdown the virtualization and ran fsck on /dev/md2 and it yelled at me... bad superblock. Thinking about it that actually made sense... as the filesystem was created inside of the virtualization installed on /dev/md2... a file system within a host file system?

My question is this:
Is it possible to fix the virtual file system from the host system or will I have to boot the virtual server to a rescue dvd-rom disk to repair?

If the problem is that the file system exists on a partition within md2, you could set up a loop device for the partition in question.

For instance, losetup --offset 32256 /dev/loop0 /dev/md2 will create a loop device starting at byte offset 32256 (sector 63). You may also want to restrict the size of the loop device with the --sizelimit parameter if md2 contains more than one partition.

md2 has 2 partitions to make one LVM volume.. i think:


So I would run:
losetup --offset 404 /dev/loop0 /dev/md2

Then run:
fsck -f /dev/loop0

oops... I would have to mount the loop0 first before running fsck?
mount /dev/loop0 /mnt/systemtocheck

The --offset parameter is given in bytes. According to the screen dump, your first partition starts at sector 1. Since the first sector is 0 and each sector is 512 bytes, --offset 512 would be the correct parameter for the first partition, while --offset 208384 (407 * 512) would create a loop device starting at the second partition.

Since the 2nd partition is a PV for LVM, you'll also have to activate the volume group (vgscan/vgmknodes) and possibly also the logical volume for the LVM device to appear under /dev/<volume group>.

No, you should never run fsck on a mounted filesystem.