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

[Thomas Leonard <talex5@xxxxxxxxx>]

On 22 January 2015 at 09:48, David Scott <scott.dj@xxxxxxxxx> wrote:
> 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. :)

In my config.ml, I use:

let storage =
  match get_mode () with
  | `Xen -> block_of_file "xvda"
  | `Unix -> block_of_file "disk.img"

That works, but the "block_of_file" name is misleading.

Also, it all goes very strange if you also have a file named "xvda" in
the same directory - then mirage replaces the Xen block name with an
absolute Unix file path!

>> 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.

It would be nice to use a variant here (e.g. `Slot 0xCA00).

> 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?

I like being able to refer to raw disks if needed. But we could have a
(`Label "my-disk") variant too.

>
> 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
>
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
>



-- 
Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

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