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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Mon, Jan 5, 2015 at 6:41 PM, Philippe-A. Lemelin
<philippe.lemelin@xxxxxxxxxxxx> wrote:
>
>
> 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...
>>>>
>>>>    -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?
>>
>
> 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
>>> 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?
>
>
> Exactly.
>
>>
>>> 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 0.10.2.8. 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 ?

Aha -- OK, I think I've got this nailed.

Can you check to see what version of python-virtinst you're running?

I'm willing to bet it's 0.600.0-24.

Can you then see if you can downgrade to this package and install it
manually (i.e., downgrade to 0.600.0-19)?

http://mirror.centos.org/centos/6/xen4/x86_64/Packages/python-virtinst-0.600.0-19.el6.centos.alt.noarch.rpm

Apparently it's neither xend, nor Xen, nor libvirt that are defaulting
to tap; but virt-install itself.  The original x4c packages added a
patch to make virt-install default to tap2 instead of tap; but they
never upstreamed the change.  Recently, the core CentOS repo updated
python-virtinst to -24, which would naturally cause yum to "upgrade"
to the newer package in the core repo, but that didn't have the
change.

I'll get Johnny to build a new python-virtinst for x4c with the patch
installed; that should fix things for people.

 -George

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