Re: [Xen-users] Re: XEN 3.1: critical bug: vif init failure after creating 15-17 VMs (XENBUS: Timeout connecting to device: device/vif)

[Keir Fraser <keir@xxxxxxxxxxxxx>]

>> This problem is entirely different. The problem is visible earlier in your
>> console output: the Xen block-device driver is unable to acquire the
>> device-number space for SCSI devices (sda, sdb, etc). Hence it is failing to
>> initialise the vbd connections to the backend and is ending up in state 6
>> (which is XenbusStateClosed).
> 
> I don't understand. Which Xen block-device driver is unable to? The
> frontend or the backend? This never happened on Xen 2, al least I never
> encountered it.

The driver in domU. If you never saw this problem with Xen2, then that's
because the domU kernels you used at that time did not have the normal SCSI
subsystem compiled into them.

>> The solutions you have are:
>>  1. Do not build the generic SCSI subsystem into your dom0 kernels. It is
>> this subsystem which (quite reasonably) is allocating the sd* number space
>> to the exclusion of the Xen block-device driver.
> 
> This is not possible, as the physical machine has SCSI-disks and a SATA
> disk (which also uses the SCSI subsystem).

Sorry, that was a typo. I meant you should not build it into your *domU*
kernels. It is of course fine to have ordinary SCSI compiled into dom0.

>>  2. Call your devices hd* instead of sd* (i.e., hijack the IDE device
>> numbers instead of the SCSI ones), or even use the xvd* number space, which
>> is exclusively reserved for Xen VBDs.
> 
> I tried hd*, which works. I'm used to making sd* devices as there used
> to be some Xen version (forgot which one) that was more stable when
> using sd* devices in domUs.

Sounds unlikely to me. sd* and hd* are just names.

Anyhow, if you stop compiling SCSI into your domU kernel then you can
continue to use sd* names for your VBDs.

 -- Keir


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users