On Thu, Mar 26, 2009 at 01:27:06PM +0000, Jody Belka wrote:
> On Thu, Mar 26, 2009 at 10:21:01AM +0000, Stefano Stabellini wrote:
> > Jody Belka wrote:
> >
> > > Now, the stub domain isn't actually working for me anyway, even on
> > > non-pvops0, but it is able to talk to the fs-backend at least. To show
> > > what that looks like, I've attached a couple of emails I sent off-list.
> >
> >
> >
> > There are some known issues that affect stubdoms at the moment, since
> > they involve some changes made on qemu upstream I am trying to find a
> > solution there.
>
> Ok, by changing from a pvfb vnc inside the stubdom config, to vnc in the
> master config, I now get output into my qemu-dm log file, and so can see
> the debug printf's I added in. It also means a msg from qemu is appearing:
>
> Could not initialize device 'tap'
>
> Which is coming from within vl.c:
>
> for(i = 0;i < nb_net_clients; i++) {
> if (net_client_parse(net_clients[i]) < 0)
> exit(1);
> }
>
>
> The qemu cmdline parameters are being reported as follows:
>
> "main" "-d" "23" "-domain-name" "wintest-sd" "-videoram" "4" "-vnc"
> "192.168.254.135:0" "-vncunused" "-vcpus" "1" "-boot" "c" "-acpi" "-net"
> "nic,vlan=1,macaddr=aa:00:00:12:23:34,model=e1000"
> "-net" "tap,vlan=1,ifname=tap23.0,bridge=eth0"
>
>
> Any debugging I could add that could track down the cause of the above
> error, or is this something you recognize?
Ok, turns out that there's a bit of code in there that deliberately causes
-net tap to error out for a stubdom, which then causes the entire stubdom
to die.
Changing that to just ignore the tap lets the domain come up. Lots of error
messages end up appearing in the log, and windows is currently crashing during
boot, but it's a long long long way along to really working :)
J
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home