Re: [libvirt] [PATCH] Xen Events Updated

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

 



On Fri, Nov 21, 2008 at 01:06:08PM -0500, Ben Guthro wrote:
> I tested these changes, and seem to be having some issues opening the xen driver in a post 3.0.3 codepath:
> 
> DEBUG: xen_unified.c: xenUnifiedOpen (Trying hypervisor sub-driver)
> DEBUG: xen_unified.c: xenUnifiedOpen (Activated hypervisor sub-driver)
> libvir: Xen Daemon error : internal error failed to create a socket   
> libvir: Xen error : out of memory                                     
> DEBUG: xen_unified.c: xenUnifiedOpen (Failed to make capabilities)    
> DEBUG: xen_unified.c: xenUnifiedOpen (Failed to activate a mandatory sub-driver)
> DEBUG: libvirt.c: do_open (driver 1 Xen returned ERROR)
> 
> 
> I haven't chased this down fully yet, but something is interfering...

Wierd, I'm rather puzzelled as to why you'd get the 'Activated hypervisor
sub-driver' message, but not immediately see a 'Trying XenD sub-driver'
message, since there's only one line of code in between them which is a
simple assignment...

        DEBUG0("Trying hypervisor sub-driver");
        if (drivers[XEN_UNIFIED_HYPERVISOR_OFFSET]->open(conn, auth, flags) ==
            VIR_DRV_OPEN_SUCCESS) {
            DEBUG0("Activated hypervisor sub-driver");
            priv->opened[XEN_UNIFIED_HYPERVISOR_OFFSET] = 1;
        }
    }

    /* XenD is required to suceed if root.
     * If it fails as non-root, then the proxy driver may take over
     */
    DEBUG0("Trying XenD sub-driver");
    if (drivers[XEN_UNIFIED_XEND_OFFSET]->open(conn, auth, flags) ==
        VIR_DRV_OPEN_SUCCESS) {
        DEBUG0("Activated XenD sub-driver");
        priv->opened[XEN_UNIFIED_XEND_OFFSET] = 1;


DEBUG: xen_unified.c: xenUnifiedOpen (Trying hypervisor sub-driver)
DEBUG: xen_unified.c: xenUnifiedOpen (Activated hypervisor sub-driver)
DEBUG: xen_unified.c: xenUnifiedOpen (Trying XenD sub-driver)
DEBUG: xen_unified.c: xenUnifiedOpen (Activated XenD sub-driver)
...snip...

One other problem I've noticed is a race condition on the @introduceDomain
watch. The watch fires as soon as the domain ID is added to xenstore.
We then query the name & uuid, but occassionally we query before XenD has
had a chance to fill them in.

I think that upon failure, we'll have to add a timer callback to retry
the lookup after 500ms, to take account of possible race. I'm going to
give this a try...

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]