Re: Next step.... more guidance requested
- From: Antti Kantee <pooka@xxxxxx>
- To: rumpkernel-users@xxxxxxxxxxxxx
- Date: Mon, 15 Jun 2015 10:38:40 +0000
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.
Other related posts:
