On Thu, Jan 22, 2015 at 4:45 PM, Thomas Leonard <[email protected]> wrote:
> On 22 January 2015 at 09:48, David Scott <[email protected]> wrote: > > Hi, > > > > On Tue, Jan 20, 2015 at 2:29 PM, Raphael 'kena' Poss <[email protected]> > 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. 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 > > > > > 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 · [email protected] > >> > http://science.raphael.poss.name/ > >> > > >> > > >> > > >> > >> -- > >> Raphael 'kena' Poss · [email protected] > >> http://science.raphael.poss.name/ > >> > >> > >> > >> > >> _______________________________________________ > >> MirageOS-devel mailing list > >> [email protected] > >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > > > > > > > > > > -- > > Dave Scott > > > > _______________________________________________ > > MirageOS-devel mailing list > > [email protected] > > 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 > -- Dave Scott
_______________________________________________ MirageOS-devel mailing list [email protected] http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
