1. 12
  1.  

  2. 2

    Back when Boot Camp was relatively new on Macs, Parallels desktop had a similar feature where, while running in macOs, it could boot your windows partition in a VM. I think VMware Fusion could do it as well.

    1. 1

      I think this feature is still available in Parallels - I used it back when I still had an Intel MacBook

    2. 1

      I wonder if a similar setup is possible with QEMU?

      1. 2

        It’s definitely possible to run qemu/kvm VMs with storage on raw block devices, so I’d certainly expect so.

        1. 2

          I’ve used this trick in the past testing lilo tweaks to make sure I’d still have a bootable machine.

      2. 1

        Heh, this is a neat hack.

        I would expect booting the same filesystem twice would lead to massive filesystem corruption or kernel panics as two kernels write to the same block device at once, arguing over metadata updates.

        In most cases this is true, though ext4 has (opt-in) multiple-mount protection available that can safeguard against this.

        1. 1

          This might work to protect the filesystem against complete corruption but things at the VFS layer and above (including userspace code) will make assumptions about exclusive access. For example, if you lock a file in exclusive mode, then you expect that nothing else will modify the blocks while you’re doing so. The MMP mode in ext4 won’t protect against this because the locks are purely a kernel construct, they aren’t reflected in the FS.

          Some filesystems are designed explicitly to support a SAN model, where multiple machines have an iSCSI (or similar) block device and share the same machinery. Often, this involves some other out-of-band communication for things like locking to avoid needing a round-trip through persistent storage (think: NFS log manager, but at a lower level, so you lock a set of blocks rather than a range in a file).

          1. 1

            This might work to protect the filesystem against complete corruption but things at the VFS layer and above (including userspace code) will make assumptions about exclusive access. For example, if you lock a file in exclusive mode, then you expect that nothing else will modify the blocks while you’re doing so. The MMP mode in ext4 won’t protect against this because the locks are purely a kernel construct, they aren’t reflected in the FS.

            That sounds like a fairly different mechanism (locks and such) than how I’m pretty sure ext4 MMP works – if you try to mount a filesystem that’s already mounted elsewhere it just fails the second mount. I suppose in the event of wildly screwy clocks that could let something slip through, though after looking into the code I see there’s also periodic runtime checking while mounted (with the usual panic/continue/remount-ro handling options) as an additional safeguard.