Xen project Mailing List

Hi,

On Tue, Jan 20, 2015 at 2:29 PM, Raphael 'kena' Poss <r.poss@xxxxxx> wrote:

For information, if I manually edit the Mirage-generated "main.ml" to say:

let block1 () =
Â Block.connect "xvda1"

(instead of Block.connect "/path/to/disk.img")

Then it works fine! However this is not what I want, as main.ml should really work out of the box. :)

It seems to me that there is some naming glue between the code generator, Block.connect and Xen that I don't understand. Can anyone shed some light on this?

On Unix the natural way to name a file or disk image is through a filesystem path. In a minimal VM implementation there isn't a filesystem so paths don't work; instead disks are attached to virtual slot numbers (usually integers) on some virtual bus. On Xen, PV disks are attached to a single virtual bus. Xen was originally created to run PV Linux guests and it was convenient to base the slot numbers on the Linux device/major numbers, hence the convention became that the "first" commonly-used slot was numbered "51712" and corresponded to "/dev/xvda" in the guest. The goal was that the config file setting in dom0 would say "xvda" and the VM would agree and use "/dev/xvda". Clearly this is a bit old-fashioned now; we have more guest types than PV Linux and guest kernels can call their disk whatever they want anyway.

Your string "xvda1" is being interpreted by this code in mirage-block-xen:

https://github.com/mirage/mirage-block-xen/blob/f84f16dab55c42e91b70dc0c02e6953706a13063/lib/blkfront.ml#L427

the code will accept options including

- a virtual slot number (e.g. 51712) on the "Xen PV" bus

- a virtual slot number converted to a linux-style string (e.g. "xvda")

I agree this is very clunky.

I think we need a better way to identify our disks. The toolstacks (the things which start the VMs) don't provide a link between the filename on the host and the slot number. In fact many service providers would prefer not to leak filesystem paths into untrusted VMs at all. So I think we should avoid using paths to identify disks.

I believe Windows completely ignores the virtual slot number and relies on labels contained *within* the disks. Perhaps we should insist that all our disks have a trivial partition table with a unique "Disk identity"?[1] This implies we would need to extend the mirage tool to prepare the disk images and fill in the identify string?

Cheers,

Dave

[1]Âhttp://en.wikipedia.org/wiki/Master_boot_record#Disk_identity

Op 20 jan 2015, om 15:18 heeft Raphael 'kena' Poss het volgende geschreven:

> Hi all,
>
> I'm having trouble with all the "block" examples in mirage-skeleton, using Xen 4.4.
> It all boils down to Block.connect not finding the disk image I describe in the .xl description file.
>
> For example: in block/block_test.xl
> disk = [ 'format=raw,vdev=xvda,access=rw,target=/home/kena/src/mirage-skeleton/block/disk.img' ]
>
> Gives:
>
> Block.connect /home/kena/src/mirage-skeleton/block/disk.img: unable to match '/home/kena/src/mirage-skeleton/block/disk.img' to any available devices [ 51712 ]
> Block.connect /home/kena/src/mirage-skeleton/block/disk.img: could not find device
>
> This happened first with a fresh install of Mirage 2.0, then also with Mirage 2.1/2.2 from the opam dev repository.
> For what it's worth it seems my Mirage install works OK, as the 'console' and 'static_website' demo appear to work perfectly fine.
>
> Any hints as to where and how to investigate this?
>
> --
> Raphael 'kena' Poss Â r.poss@xxxxxx
> http://science.raphael.poss.name/
>
>
>

--
Raphael 'kena' Poss Â r.poss@xxxxxx
http://science.raphael.poss.name/

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel

Dave Scott

Re: [MirageOS-devel] Errors trying the "block" example with Mirage 2.0+ and Xen 4.4