[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... -GeorgeThat 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 ? I'll see if I can find some time to do some poking around here as well. -George Thank you, Philippe-A. Lemelin _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxx http://lists.xen.org/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |