Re: guests not starting properly on 7/amd64 dom0 freshly with xen45

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Dec 30,  1:12am, Jean-Yves Migeon wrote:
} Le 29/12/2015 20:53, S.P.Zeidler a écrit :
} > I get in /var/log/messages:
} > Dec 29 18:39:10 pkgbuild-DOM0 /netbsd: xvif1i0: Ethernet address
} > 00:16:3e:31:30:61
} > Dec 29 18:39:11 pkgbuild-DOM0 /netbsd: xbd backend domain 1 handle 0xca00
} > (51712) using event channel 19, protocol x86_64-abi
} > 
} > with the config being:
} > kernel = "/home/sets/amd64-nb7/netbsd-XEN3_DOMU.gz"
} > memory = 8192
} > name = "amd64-nb7"
} > vcpus = 3
} > cpus = [ "13", "14", "15" ]
} > vif = [ 'mac=00:16:3e:30:30:61, bridge=bridge0' ]
} > disk = [ '/dev/sd0k,raw,xvda,rw' ]
} > 
} > May I consider the log messages as indication that both xennet0 and xbd0
} > in fact do get configured?
} 
} At least for network, yes, xennet(4) will not log the transfer mode (in
} your case, "RX copy") if it could not initialize properly.
} 
} The surest way for this is to have a look in xenstore, and check the
} "state" for each devices used. Taking DOMID as "1", within dom0:
} 
} # xenstore-ls /local/domain/1/device
} ...
} 
} and look for the "state" entry, where it should be "4".
} 
} FWIW, the other possibles values are:
} 
} [snip]
} 
} Ideally you have to check that their backend counterpart is also in
} state "4" too (have a look at the "backend" entry for each domU device
} to know their path).
} 
} > Interfaces:
} > bridge0: flags=41<UP,RUNNING> mtu 1500
} > xvif1i0: flags=8822<BROADCAST,NOTRAILERS,SIMPLEX,MULTICAST> mtu 1500
} >         capabilities=2800<TCP4CSUM_Tx,UDP4CSUM_Tx>
} > 		enabled=0
} > 		address: 00:16:3e:31:30:61
} 
} This looks normal.
} 
} > disk:
} >  k: 188743680 1262524928     4.2BSD      0     0     0  # (Cyl.  43837*-50391*)
} > 
} > (and no, it is not mounted by anything else)
} 
} Does it have a vnd(4) attached to it in dom0?

     Since it is a device, there will be no vnd(4) involved.  Those
only come into play when the backend storage is a file.

} > and booting xen-debug has not increased verbosity.
} 
} I doubt that the hypervisor is at fault here, like John suggested I am
} also expecting some backend/frontend (miss-)connection.

     Yes, I agree, it is most likely a misconfiguration.

} Various possibilities:
} - vnd(4) not being able to mount the block device within dom0;

     not applicable

} - failed connecting the event-channel between xbdbdack(4) and xbd(4)
} (xenstore daemon failure, can happen when mixing xentools of different
} revisions);

     problem is likely here

} - invalid label (start and size out of bounds).

     possible, but not that likely

} Easiest way to debug this is to insert a couple of echoes in
} /usr/pkg/etc/xen/scripts/block and see which operation is failing.
} 
}-- End of excerpt from Jean-Yves Migeon