On Mon, Jun 15, 2015 at 10:38:40AM +0000, Antti Kantee wrote:
> On 15/06/15 08:16, Andrew Stuart wrote:
> >This is my hardcoded_jsoncfg.
> >
> >static char hardcoded_jsoncfg[] = "{\"net\": {\"cloner\": \"true\",
> >\"method\": \"dhcp\", \"type\": \"inet\", \"if\": \"xenif0\"}, \"cmdline\":
> >\"nginx_baked.xen -c /etc/conf/nginx.conf\", \"blk\": {\"fstype\": \"ufs\",
> >\"source\": \"etfs\", \"path\": \"blk0\", \"mountpoint\": \"/etc\"}}”;
>
> Good, now it's easy to reason about what is happening.
>
> So when you specify "path": "blk0", it gets mapped to some Xen identifier.
> When I wrote the rump kernel hypercalls for Xen, I did the mapping from
> "blk<n>" to the Xen vbd this way:
>
> int devnum = 768 + (num<<6);
> https://github.com/rumpkernel/rumprun/blob/master/platform/xen/rumphyper_bio.c#L66
>
> ... because, while slightly odd, it seemed to work, and the main interest
> was getting the entire stack to run. Then I forgot to come back and make it
> work properly.
>
> Now, if we look at your log from a few mails ago:
>
> >vbd 2049 is hd0
> ...
> >vbd 2128 is hd1
> ...
> >vbd 2144 is hd2
>
> Since none of those are "768", using "blk0" doesn't work and you get your
> error:
>
> >Failed to read device/vbd/832/backend-id.
> ...
> >rumprun: etfs register for "blk1" failed: 5
>
> Though, I assume that log is from when you were using path=blk1 instead of
> blk0...
>
> So, in other words, the observation that made during original porting to Xen
> where vbd=768+(n<<6) does not hold on EC2. We/I need to fix the mapping
> between block device 0, 1, ... and Xen vbd. And that requires the person
> fixing the thing to know wtf vbd actually consists of ;)
>
> Until it gets fixed properly, assuming EC2 gives you the same vbd id every
> time (2049), you can just hardcode the num->devnum calculation in the code
> location I linked above and see if that gets you further.
The device number is generated following certain rules. In upstream Xen,
for example, different types of virtual disk identifiers are mapped to
different "number space". The spec can be found at:
http://xenbits.xen.org/docs/unstable/misc/vbd-interface.txt
AWS probably follows the same spec as well because they need to support
customers running their own Linux kernel.
Hope this helps.
Wei.
