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

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

[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...
>>
>>   -George
>>
> 
> 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?

> 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
> packages.

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.

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

 -George

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