[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |