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

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

On 15-01-05 01:09 PM, George Dunlap wrote:
[cc'ing centos-virt, as this seems to do specifically with the x4c packages]

On 01/05/2015 05:01 PM, Philippe-A. Lemelin wrote:
On 15-01-05 11:34 AM, George Dunlap wrote:
On 01/05/2015 04:15 PM, Philippe-A. Lemelin wrote:

On 15-01-05 10:33 AM, Ian Campbell wrote:
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.

This is not the first installation of Xen we did but it is the first
time we have seen this behavior (see lower in this email, forcing tap2
solved the installation issue). We currently have 4 Dom0 running the
same hardware/OS but installed at different time in the last 6 months.
The installation is a manual process but respects the same written
procedure each time so there must have been a change in CentOS packages
somewhere at the end of November or the beginning of December. We are
still trying to figure what the difference is.

Well the x4c packages have been getting minor updates fairly regularly.
   What versions are installed on the working hosts?

It's possible that one of the fixes backported to 4.2.5 actually broke
something in xend and nobody noticed...


That was my main issue, every hosts are running the same versions but
the ones that have been shipped had not seen any installations of new
guests since.

I requested access to one of the production host and tested installing a
new guest and it could not detect the hard disks in the installer (all
the other guest have their disks device set to tap2 and the new test
installation has it set to tap). Uptime on this host is 54 days and it
was last updated on Dec 15 (yum upgrade).

Ah, interesting.  So let me see if I've got this right:
* So far, in your tests, all guests which use tap2 work correctly, and
all guests which use tap1 don't.
* Guests created with {libvirt,xen}-past defaulted to tap2.  (At least,
they're using tap2 now.)
* Guests created with {libvirt,xen}-current default to tap.
* If you specify tap2, then guests created with {libvirt,xen}-current
install successfully.

Is that right?

All of the above is right.

I simply use virt-manager this time and did the simplest installation,
selecting all the default values and using the Centos 6 mirrors for the

By "this time", you mean the test on the production host (which resulted
in a VM with its devices set to 'tap'), is that right?


At first I thought we had made some errors in the host installation but
seeing that my production hosts are showing the same behavior, I guess
something is indeed broken.

Would this be an issue with libvirt or xen ?

At this point it's hard to say.  If the tap2 disk choice persists across
Xen / libvirt upgrades, then obviously something is choosing libvirt to
specify tap1 now instead of tap2.  But that something could be as a
result of a change either in libvirt, or in xend, or even in the kernel.
  And that

I'm not sure how inter-dependent the packages are; but if you could find
a {libvirt, xen, kernel} trio from earlier last year that worked (i.e.,
defaulted to tap2), and then updated each one individually until it
defaulted to tap1, that would help give a clearer picture where the
problem might be coming from.

One of our guys is installing a server with the centos 6.6 mirror and we will NOT do a yum upgrade once completed. This should leave us with libvirt 0.10.2 instead of The packages at that point date back to October and we are sure everything was fine then.

Is the order of the update important ?

libvirt first, xen second, kernel last ?

I'll see if I can find some time to do some poking around here as well.


Thank you,

Philippe-A. Lemelin

Xen-users mailing list



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