Re: [Xen-devel] Re: xl vs. xm, possible bug in xl

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

CC'ing IanJ to make sure he is going to read this

On Fri, 9 Sep 2011, Stefano Stabellini wrote:
> On Fri, 9 Sep 2011, Sven Köhler wrote:
> > Am 09.09.2011 13:27, schrieb Stefano Stabellini:
> > >> Any clue, that the second problem is about?
> > >>> # xl create /etc/xen/xen-sk1
> > >>> Parsing config file /etc/xen/xen-sk1
> > >>> libxl: error: libxl_device.c:476:libxl__wait_for_device_model Device 
> > >>> Model not ready
> > >>> xl: fatal error: libxl_create.c:535, rc=-1: 
> > >>> libxl__confirm_device_model_startup
> > > 
> > > That means that qemu failed to start. Could you please cat
> > > /var/log/xen/qemu-dm-domainname.log?
> > 
> > There is no such file (my domain config lacks a name="something" line).
> > However qemu-dm-test.log does exist and is of recent date, and it says
> > that qemu cannot be started. This is very plausible, since qemu is not
> > even installed. This machine is supposed to start paravirt guests only.
> > And xen has been compiled without support for hvm guests. (Not sure
> > right now, what the gentoo people do to disable support support for hvm
> > guests).
> > 
> > Does my config file for the domain (see one of my previous emails in
> > this thread) indicate, that the machine is a hvm domain? How can I tell
> > xl that this a paravirt domain, and qemu is not needed and should not be
> > used?
> 
> I think I have found the issue: if blktap2 is not enabled xl is going to
> start qemu (to provide a disk backend) even if it is not actually needed
> because the user wants to use blkback.
> 
> We have a patch upstream to fix this issue but it hasn't been backported
> to 4.1:
> 
> 
> 
> # HG changeset patch
> # User Ian Campbell <ian.campbell@xxxxxxxxxx>
> # Date 1300213187 0
> # Node ID d4ca456c0c25c3c3daedc216c657296f2895482a
> # Parent  3caed2112c65791855e8bf0fd34c15e3160bbc78
> libxl: do not start a xenpv qemu solely for tap devices if blktap is available
> 
> qemu is used as a fallback for DISK_BACKEND_TAP if no blktap is
> available but if blktap is available, or for DISK_BACKEND_PHY, we
> don't need a qemu process.
> 
> Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> Committed-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> 
> diff -r 3caed2112c65 -r d4ca456c0c25 tools/libxl/libxl_dm.c
> --- a/tools/libxl/libxl_dm.c  Tue Mar 15 10:14:27 2011 +0000
> +++ b/tools/libxl/libxl_dm.c  Tue Mar 15 18:19:47 2011 +0000
> @@ -828,8 +828,29 @@ int libxl__need_xenpv_qemu(libxl_ctx *ct
>          goto out;
>      }
>  
> -    if (nr_disks > 0 && !libxl__blktap_enabled(&gc))
> -        ret = 1;
> +    if (nr_disks > 0) {
> +        int blktap_enabled = -1;
> +        for (i = 0; i < nr_disks; i++) {
> +            switch (disks[i].backend) {
> +            case DISK_BACKEND_TAP:
> +                if (blktap_enabled == -1)
> +                    blktap_enabled = libxl__blktap_enabled(&gc);
> +                if (!blktap_enabled) {
> +                    ret = 1;
> +                    goto out;
> +                }
> +                break;
> +
> +            case DISK_BACKEND_QDISK:
> +                ret = 1;
> +                goto out;
> +
> +            case DISK_BACKEND_PHY:
> +            case DISK_BACKEND_UNKNOWN:
> +                break;
> +            }
> +        }
> +    }
>  
>  out:
>      LIbxl__free_all(&gc);

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel