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

[Thomas Leonard <talex5@xxxxxxxxx>]

On 25 January 2015 at 14:06, David Scott <scott.dj@xxxxxxxxx> wrote:
>
>
> On Thu, Jan 22, 2015 at 4:45 PM, Thomas Leonard <talex5@xxxxxxxxx> wrote:
>>
>> 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).
>
>
> Yeah, switching to variants sounds good.
>
>>
>>
>> > 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.
>
>
> Sounds good.
>
> Looking into it a bit more, the convention I see on my Linux boxes is to
> name disk (partitions) using UUIDs, via "GUID partition tables"[1]. My
> /etc/fstab looks a bit like:
>
> # /boot was on /dev/sda1 during installation
> UUID=3d493119-f738-4852-89ee-25b98931c5ca /boot           ext2    defaults
> 0       2
>
> So I think we could extend ocaml-mbr to include gpt (or make ocaml-gpt with
> a build depend on ocaml-mbr). We could extend the mirage tool's library with
> something like "partition_of_file" (in addition to "block_of_file") which
> would create a fresh file containing a trivial gpt with a single
> partition/uuid plus a copy of the original data.

If it makes a copy, doesn't that mean that running mirage will
overwrite any data written by the unikernel? (or, fail to update to
changes in the original file).

> The generated
> "Block.connect" could then use "`Uuid <uuid we made>". Maybe we could
> generate better runes in the .xl file too.
>
> So in the default case it would work without manual switch/case (at the cost
> of a disk copy), but you could drop back to "block_of_file" if you knew what
> you were doing.
>
> Cheers,
> Dave
>
> [1] https://wiki.archlinux.org/index.php/GUID_Partition_Table



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