[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MirageOS-devel] multiple block devices under xen



thanks dave!  a couple of questions inline as i start to try this out...

On 18 Feb 2014, at 12:05, David Scott <scott.dj@xxxxxxxxx> wrote:

> Background
> ----------
> 
> When a disk is added to a VM (under Xen, KVM, any hypervisor) it's like 
> plugging in a PCI device into a physical box -- a disk will appear in some 
> kind of numbered "slot" on a "bus". In xen the "slot" number is the name of 
> the directory in xenstore (/local/domain/<domid>/device/vbd/<slot>) 

just because i'm still a bit fuzzy on this -- what about when i'm not running 
xenstore?  (or am i always running xenstore, i just haven't realised yet?)

> From the Linux perspective, the *convention* is that the "slot" number is the 
> device node (major-number << 8 || minor-number):

...and from below (and a bit of googling), /dev/xvdN has major number 202 and 
minor number (N-'a')*16, right?  is that (the major/minor numbering of xvd 
devices) also convention or standard?

> Xen disk support
> ----------------
> 
> ...and then create a loop device like so:
> 
> sudo losetup /dev/loop0 disk.raw
> 
> (where /dev/loop0 is any free loop device. Note the total number of loop 
> devices is determined at module load time, it's not dynamic unfortunately 
> (last time I checked anyway))

is there an easy way to find out what this is?  (whether from CLI or 
programmatically.)

> Whatever you do, don't mix I/O to the /dev/loop device with I/O to the file 
> -- it won't be coherent. 

presumably this is unlikely to happen by accident in a mirage vm?

[snip details]

ok, so in summary the current recommendation is to:

+ create a FAT file image (done by mirage) and mount it as a loopback device 
        $ sudo losetup /dev/loopN fat.img

+ write a Xen config file that hotplugs loopback devices as physical block 
devices
        disk = [ '/dev/loop0,,xvda', ... ]

+ write a mirage config file that uses the block device node number as a name
        let block = { Block.name = "51712"; filename = "fat.img"; read_only = 
false; }

...and then hopefully everything will line up, with the Block.filename value 
used when running the mirage unikernel as a UNIX process, and the Block.name 
value being interpreted as the appropriate device node when running as a Xen VM 
(assuming the Xen config file has indicated to plug the loopback device as the 
xvdN device correctly)?

> This is obviously not ideal. Perhaps in future we can:
> * make "mirage" generate an .xl config file which references the file (rather 
> than a block device) and rely on the hotplug scripts to manage the loop 
> device. This should work, but since there are more moving parts, may be flaky 
> on your particular distro.
> * make "Block.connect" take some kind of volume label rather than a device 
> id, so mirage-block-{unix,xen} can cope with disks being presented in any 
> order on the bus

both would be nice i think -- but hopefully the info above (assuming i have it 
straight now) will be enough to get going! :)


-- 
Cheers,

R.




This message and any attachment are intended solely for the addressee and may 
contain confidential information. If you have received this message in error, 
please send it back to me, and immediately delete it.   Please do not use, copy 
or disclose the information contained in this message or in any attachment.  
Any views or opinions expressed by the author of this email do not necessarily 
reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment
may still contain software viruses which could damage your computer system, you 
are advised to perform your own checks. Email communications with the 
University of Nottingham may be monitored as permitted by UK legislation.





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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.