[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] XENBUS timeout connecting to device (Hard disks not detected)



George, is blktap expected to work with the xen4centos (6) packages?

(not trimming quotes for George's benefit)

I wonder if tap vs. tap2 is a xend vs xl thing.

On Mon, 2015-01-05 at 09:57 -0500, Philippe-A. Lemelin wrote:
> 
> On 15-01-05 08:09 AM, Ian Campbell wrote:
> > On Tue, 2014-12-30 at 08:58 -0500, Philippe-A. Lemelin wrote:
> >> Good Morning List,
> >>
> >> I'm currently trying to install a CentOS DomU
> >
> > What is your dom0? Also CentOS? If so which Xen and libvirt are you
> > using (built yourself, from packages on the net, etc)?
> >
> 
> Yes, my dom0 is a fully updated CentOS 6. The xen version is 4.2.5-37 
> and the libvirt version is 0.10.2.8-8. All installed from the xen4 rpm 
> repository of CentOS. We also reinstalled the machine so it's a fresh 
> install with the default configurations.
> 
> Strangely, I have more than one server now running those versions of 
> packages and my domU are not showing any issues at the moment. I will 
> try to launch an installation on those and see if it can detect the disks.
> 
> >>   and I am facing an issue I
> >> never experienced before. None of my hard disks are detected. I've now
> >> tried with a single HDD or with many as I usually do and each time, I'm
> >> faced with the same result. I tried with a CenOS 5 and 6 DomU with the
> >> same end result, the installer is not seeing any valid devices on which
> >> to install.
> >>
> >> Here is the command i'm using when launching the installation:
> >>
> >> virt-install --vnc --bridge=xenbr0 -p --name=test --ram=2000 --vcpus=2
> >> --disk /images/disk1.img,format=raw --disk /images/disk2.img,format=raw
> >> --disk /images/disk3.img,format=raw --disk /images/disk4.img,format=raw
> >> --disk /images/disk5.img,format=raw
> >> --location=http://mirror.centos.org/centos/5/os/x86_64
> >>
> >> When looking at the installer log I see the following ( I confirmed that
> >> the 5 devices that timeout are indeed the xvda, xvdb... disks):
> >>
> >> <6>XENBUS: Device with no driver: device/vbd/51712
> >> <6>XENBUS: Device with no driver: device/vbd/51728
> >> <6>XENBUS: Device with no driver: device/vbd/51744
> >> <6>XENBUS: Device with no driver: device/vbd/51760
> >> <6>XENBUS: Device with no driver: device/vbd/51776
> >> <6>XENBUS: Device with no driver: device/vif/0
> >> <6>XENBUS: Device with no driver: device/console/0
> >> ...
> >> <4>XENBUS: Waiting for devices to initialise: 295s...290s... ...
> >> ...
> >> <4>XENBUS: Timeout connecting to device: device/vbd/51712 (local state
> >> 3, remote state 1)
> >> <4>XENBUS: Timeout connecting to device: device/vbd/51728 (local state
> >> 3, remote state 1)
> >> <4>XENBUS: Timeout connecting to device: device/vbd/51744 (local state
> >> 3, remote state 1)
> >> <4>XENBUS: Timeout connecting to device: device/vbd/51760 (local state
> >> 3, remote state 1)
> >> <4>XENBUS: Timeout connecting to device: device/vbd/51776 (local state
> >> 3, remote state 1)
> >>
> >> Once the installation fails, If I connect with Virt-Manager, I can see
> >> that my machines has 5 disks attached. I do not understand why it is
> >> timing out like that.
> >>
> >> I'm looking for any debugging tips or pointers on helping me to resolve
> >> this rather strange issue.
> >
> > Wild stab in the dark: Is the backend driver present in dom0? Either the
> > kernel module loaded or the appropriate backend provider (qemu perhaps)
> > installed and getting launched?
> >
> > The output of "xenstore-ls -fp" while the guest is running would contain
> > some clues as to which backend is expected, which might suggest a next
> > step.
> 
> I've run this command on my working installation and I can see it is 
> using tap2 :
> 
> /vm/6acf630f-912b-7159-8188-b7a7afd4d3f2/device/tap2 = ""   (n0)
> /vm/6acf630f-912b-7159-8188-b7a7afd4d3f2/device/tap2/51712 = ""   (n0)
> /vm/6acf630f-912b-7159-8188-b7a7afd4d3f2/device/tap2/51712/frontend = 
> "/local/domain/12/device/vbd/51712"   (n0)
> /vm/6acf630f-912b-7159-8188-b7a7afd4d3f2/device/tap2/51712/frontend-id = 
> "12"   (n0)
> /vm/6acf630f-912b-7159-8188-b7a7afd4d3f2/device/tap2/51712/backend-id = 
> "0"   (n0)
> /vm/6acf630f-912b-7159-8188-b7a7afd4d3f2/device/tap2/51712/backend = 
> "/local/domain/0/backend/vbd/12/51712"   (n0)
> 
> On the installation that is causing me issue, it would seem it is using 
> tap :
> 
> /vm/81ac93e8-8e79-a3ea-7039-7eabc0ed8b86/device/tap = ""   (n0)
> /vm/81ac93e8-8e79-a3ea-7039-7eabc0ed8b86/device/tap/51712 = ""   (n0)
> /vm/81ac93e8-8e79-a3ea-7039-7eabc0ed8b86/device/tap/51712/frontend = 
> "/local/domain/5/device/vbd/51712"   (n0)
> /vm/81ac93e8-8e79-a3ea-7039-7eabc0ed8b86/device/tap/51712/frontend-id = 
> "5"   (n0)
> /vm/81ac93e8-8e79-a3ea-7039-7eabc0ed8b86/device/tap/51712/backend-id = 
> "0"   (n0)
> /vm/81ac93e8-8e79-a3ea-7039-7eabc0ed8b86/device/tap/51712/backend = 
> "/local/domain/0/backend/tap/5/51712"   (n0)
> 
> I will try to force the driver to tap2 during the installation with 
> driver_name=tap2,driver_type=aio.
> 
> >
> > There are also various logs under /var/log/xen and presumably some
> > libvirt logs somewhere which would be worth having a look at.
> >
> 
> I went through all the logs under /var/log/xen (tail -f /var/log/xen/*) 
> during the installation of my machine and could not see errors.
> 
> I will go through the libvirt logs and see if more information is available.
> 
> > Do you know which toolstack libvirt is talking to, either xend or libxl.
> 
> Where can I find this information ?

Do you have a xend process running?

I seem to have temporarily b0rked my libvirt test box, but perhaps
"virsh" has an option to say which backend it would use, or maybe it
appears in tne output of "virsh capabilities"?

Ian.


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.