From marco.guazzone at gmail.com Sat Jun  6 11:10:07 2015
Content-Type: multipart/mixed; boundary="===============3019178197827370193=="
MIME-Version: 1.0
From: Marco Guazzone <marco.guazzone at gmail.com>
To: xen at lists.fedoraproject.org
Subject: [Fedora-xen] [f20] Problem with libvirt + Xen XL toolstack
Date: Tue, 11 Nov 2014 15:50:19 +0100
Message-ID: <CABbE_O442-dwMdRzT6FsYjr8rUViGAoQ9e+1_fWd90DPFnxU9w@mail.gmail.com>

--===============3019178197827370193==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

Hello,

Since when libvirt has introduced support for the Xen XL toolstack, I
was unable to make it work together.
With Fedora 20 x86_64, still I have problems and the only way to use
libvirt+Xen is to use the old xend toolstack.

Can anybody help me?

Here's below is my test. Sorry, the mail is very long...

1. Disable SElinux
  $ vi /etc/selinux/config
    SELINUXTYPE=3Ddisabled

2. Install Xen and libvirt
  $ yum install xen
  $ yum install libvirt-daemon-xen libvirt-client

3. Disable Network Manager
  $ systemctl disable NetworkManager
  $ systemctl stop NetworkManager

4- Create network bridge
  $ vi /etc/sysconfig/network-
scripts/ifcfg-br0
    DEVICE=3Dbr0
    TYPE=3DBridge
    BOOTPROTO=3Dnone
    ONBOOT=3Dyes
    IPADDR=3D10.10.15.2
    NETMASK=3D255.255.255.0
    STP=3Dyes
    DELAY=3D0
    DEFROUTE=3Dyes
    USERCTL=3Dno
    NM_CONTROLLED=3Dno

  $ vi /etc/sysconfig/network-scripts/ifcfg-em2
    NAME=3Dem2
    TYPE=3DEthernet
    BOOTPROTO=3Dnone
    ONBOOT=3Dyes
    BRIDGE=3Dbr0
    PEERDNS=3Dyes
    PEERROUTES=3Dyes
    DEFROUTE=3Dyes
    USERCTL=3Dno
    NM_CONTROLLED=3Dno

5. Enable classic networking
  $ systemctl enable network
  $ systemctl start network

6. Reboot with Xen

7. Check xend toolstack is disabled
  $ systemctl is-enabled xend
    disabled

8. Create a test VM
  $ qemu-img-xen create -f raw test.img 10G
  $ vi testvm.cfg
    name =3D "testvm"
    uuid =3D "93f08541-bfd5-4ac4-851d-c619a4516a13"
    builder =3D "hvm"
    maxmem =3D 3072
    memory =3D 2048
    vcpus =3D 1
    on_crash =3D "restart"
    disk =3D [ "file:/root/images/testvm.img,hda,w",
"file:/root/iso/CentOS-7.0-1406-    x86_64-Minimal.iso,hdc:cdrom,r" ]
    vif =3D [ "bridge=3Dbr0,script=3Dvif-bridge" ]
    boot =3D "cd"
    sdl =3D 0
    vnc =3D 1
    vncunused =3D 1
    xen_platform_pci =3D 1
 $ xl create testvm.cfg

9. Open vncviewer and perform installation

10. Shutdown just created VM

11. Create a libvirt XML file
  $ virsh -c xen:/// domxml-from-native xen-xm testvm.cfg > testvm.xml
    <domain type=3D'xen'>
     <name>testvm</name>
     <uuid>93f08541-bfd5-4ac4-851d-c619a4516a13</uuid>
     <memory unit=3D'KiB'>3145728</memory>
     <currentMemory unit=3D'KiB'>2097152</currentMemory>
     <vcpu placement=3D'static'>1</vcpu>
     <os>
       <type arch=3D'x86_64' machine=3D'xenfv'>hvm</type>
       <loader>/usr/lib/xen/boot/hvmloader</loader>
       <boot dev=3D'hd'/>
       <boot dev=3D'hd'/>
     </os>
     <clock offset=3D'variable' adjustment=3D'0' basis=3D'utc'/>
     <on_poweroff>destroy</on_poweroff>
     <on_reboot>restart</on_reboot>
     <on_crash>restart</on_crash>
     <devices>
       <disk type=3D'file' device=3D'disk'>
         <driver name=3D'file'/>
         <source file=3D'/root/images/testvm.img'/>
         <target dev=3D'hda' bus=3D'ide'/>
       </disk>
       <disk type=3D'file' device=3D'cdrom'>
         <driver name=3D'file'/>
          <source file=3D'/root/iso/CentOS-7.0-1406-x86_64-Minimal.iso'/>
        <target dev=3D'hdc' bus=3D'ide'/>
         <readonly/>
       </disk>
       <interface type=3D'bridge'>
         <mac address=3D'00:00:00:00:00:00'/>
         <source bridge=3D'br0'/>
         <script path=3D'vif-bridge'/>
       </interface>
       <input type=3D'mouse' bus=3D'ps2'/>
       <graphics type=3D'vnc' port=3D'-1' autoport=3D'yes'/>
     </devices>
    </domain>

12. Start the VM with libvirt
  $ virsh create testvm.xml

BOOOM:

error: Failed to create domain from testvm.xml
error: End of file while reading data: Input/output error
error: One or more references were leaked after disconnect from the hypervi=
sor
error: Failed to reconnect to the hypervisor



Thank you very much for your time.

Best,

-- Marco

--===============3019178197827370193==--

From konrad.wilk at oracle.com Sat Jun  6 11:10:07 2015
Content-Type: multipart/mixed; boundary="===============4559941213452543914=="
MIME-Version: 1.0
From: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
To: xen at lists.fedoraproject.org
Subject: Re: [Fedora-xen] [f20] Problem with libvirt + Xen XL toolstack
Date: Tue, 11 Nov 2014 10:53:18 -0500
Message-ID: <20141111155318.GA13402@laptop.dumpdata.com>
In-Reply-To: CABbE_O442-dwMdRzT6FsYjr8rUViGAoQ9e+1_fWd90DPFnxU9w@mail.gmail.com

--===============4559941213452543914==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 11, 2014 at 03:50:19PM +0100, Marco Guazzone wrote:
> Hello,
> =

> Since when libvirt has introduced support for the Xen XL toolstack, I
> was unable to make it work together.
> With Fedora 20 x86_64, still I have problems and the only way to use
> libvirt+Xen is to use the old xend toolstack.
> =

> Can anybody help me?
> =

> Here's below is my test. Sorry, the mail is very long...
> =

> 1. Disable SElinux
>   $ vi /etc/selinux/config
>     SELINUXTYPE=3Ddisabled

Uh, not sure why you need that?
> =

> 2. Install Xen and libvirt
>   $ yum install xen
>   $ yum install libvirt-daemon-xen libvirt-client
> =

> 3. Disable Network Manager
>   $ systemctl disable NetworkManager
>   $ systemctl stop NetworkManager

Network Manager can deal with the bridge as you have
NM_CONTROLLED=3Dno set in it.
> =

> 4- Create network bridge
>   $ vi /etc/sysconfig/network-
> scripts/ifcfg-br0
>     DEVICE=3Dbr0
>     TYPE=3DBridge
>     BOOTPROTO=3Dnone
>     ONBOOT=3Dyes
>     IPADDR=3D10.10.15.2
>     NETMASK=3D255.255.255.0
>     STP=3Dyes
>     DELAY=3D0
>     DEFROUTE=3Dyes
>     USERCTL=3Dno
>     NM_CONTROLLED=3Dno
> =

>   $ vi /etc/sysconfig/network-scripts/ifcfg-em2
>     NAME=3Dem2
>     TYPE=3DEthernet
>     BOOTPROTO=3Dnone
>     ONBOOT=3Dyes
>     BRIDGE=3Dbr0
>     PEERDNS=3Dyes
>     PEERROUTES=3Dyes
>     DEFROUTE=3Dyes
>     USERCTL=3Dno
>     NM_CONTROLLED=3Dno
> =

> 5. Enable classic networking
>   $ systemctl enable network
>   $ systemctl start network
> =

> 6. Reboot with Xen
> =

> 7. Check xend toolstack is disabled
>   $ systemctl is-enabled xend
>     disabled
> =

> 8. Create a test VM
>   $ qemu-img-xen create -f raw test.img 10G

I've never seen that tool!
>   $ vi testvm.cfg
>     name =3D "testvm"
>     uuid =3D "93f08541-bfd5-4ac4-851d-c619a4516a13"
>     builder =3D "hvm"
>     maxmem =3D 3072
>     memory =3D 2048
>     vcpus =3D 1
>     on_crash =3D "restart"
>     disk =3D [ "file:/root/images/testvm.img,hda,w",
> "file:/root/iso/CentOS-7.0-1406-    x86_64-Minimal.iso,hdc:cdrom,r" ]

You seem to have a space in there, but htat is probably due to paste.
>     vif =3D [ "bridge=3Dbr0,script=3Dvif-bridge" ]
>     boot =3D "cd"
>     sdl =3D 0
>     vnc =3D 1
>     vncunused =3D 1
>     xen_platform_pci =3D 1
>  $ xl create testvm.cfg
>

Why don't you just use 'virt-install' outright instead of doing
it via xl and such?

It also takes care of your images having the right SELinux permissions
(I believe so). =

> 9. Open vncviewer and perform installation
> =

> 10. Shutdown just created VM
> =

> 11. Create a libvirt XML file
>   $ virsh -c xen:/// domxml-from-native xen-xm testvm.cfg > testvm.xml
>     <domain type=3D'xen'>
>      <name>testvm</name>
>      <uuid>93f08541-bfd5-4ac4-851d-c619a4516a13</uuid>
>      <memory unit=3D'KiB'>3145728</memory>
>      <currentMemory unit=3D'KiB'>2097152</currentMemory>
>      <vcpu placement=3D'static'>1</vcpu>
>      <os>
>        <type arch=3D'x86_64' machine=3D'xenfv'>hvm</type>
>        <loader>/usr/lib/xen/boot/hvmloader</loader>
>        <boot dev=3D'hd'/>
>        <boot dev=3D'hd'/>
>      </os>
>      <clock offset=3D'variable' adjustment=3D'0' basis=3D'utc'/>
>      <on_poweroff>destroy</on_poweroff>
>      <on_reboot>restart</on_reboot>
>      <on_crash>restart</on_crash>
>      <devices>
>        <disk type=3D'file' device=3D'disk'>
>          <driver name=3D'file'/>
>          <source file=3D'/root/images/testvm.img'/>
>          <target dev=3D'hda' bus=3D'ide'/>
>        </disk>
>        <disk type=3D'file' device=3D'cdrom'>
>          <driver name=3D'file'/>
>           <source file=3D'/root/iso/CentOS-7.0-1406-x86_64-Minimal.iso'/>
>         <target dev=3D'hdc' bus=3D'ide'/>
>          <readonly/>
>        </disk>
>        <interface type=3D'bridge'>
>          <mac address=3D'00:00:00:00:00:00'/>

Uuiuuh. Is that right? Shouldn't it have some value?

>          <source bridge=3D'br0'/>
>          <script path=3D'vif-bridge'/>
>        </interface>
>        <input type=3D'mouse' bus=3D'ps2'/>
>        <graphics type=3D'vnc' port=3D'-1' autoport=3D'yes'/>
>      </devices>
>     </domain>
> =

> 12. Start the VM with libvirt
>   $ virsh create testvm.xml
> =

> BOOOM:
> =

> error: Failed to create domain from testvm.xml
> error: End of file while reading data: Input/output error
> error: One or more references were leaked after disconnect from the hyper=
visor
> error: Failed to reconnect to the hypervisor
> =


So earlier version of libvirt (Fedora 20) has issues if the bridge
was called anything but 'xenbr0' it would fail. Later (Fedora 21) is OK wit=
h it.

I think that is what you are hitting (I was hitting that in Fedora 20
when I was testing it out for Beta).

Try changing the bridge name to 'xenbr0'.

IF that does not help, edit the libvirt.cfg file to crank up the debugging
and use 'journalctl -x' to see what it complains about.

> =

> =

> Thank you very much for your time.
> =

> Best,
> =

> -- Marco
> --
> xen mailing list
> xen(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/xen

--===============4559941213452543914==--

From marco.guazzone at gmail.com Sat Jun  6 11:10:07 2015
Content-Type: multipart/mixed; boundary="===============2104534197557030083=="
MIME-Version: 1.0
From: Marco Guazzone <marco.guazzone at gmail.com>
To: xen at lists.fedoraproject.org
Subject: Re: [Fedora-xen] [f20] Problem with libvirt + Xen XL toolstack
Date: Tue, 11 Nov 2014 17:21:30 +0100
Message-ID: <CABbE_O7zPpS-Cfsyp45yumQfkeJng-bgtPt57vkvvrTGF_KPHA@mail.gmail.com>
In-Reply-To: 20141111155318.GA13402@laptop.dumpdata.com

--===============2104534197557030083==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 11, 2014 at 4:53 PM, Konrad Rzeszutek Wilk
<konrad.wilk(a)oracle.com> wrote:

Hi Konrad,

>> 1. Disable SElinux
>>   $ vi /etc/selinux/config
>>     SELINUXTYPE=3Ddisabled
>
> Uh, not sure why you need that?

Just to avoid any possible interference... And, because I've found it
at the Xen wiki

http://wiki.xen.org/wiki/Fedora_Host_Installation

>> 3. Disable Network Manager
>>   $ systemctl disable NetworkManager
>>   $ systemctl stop NetworkManager
>
> Network Manager can deal with the bridge as you have
> NM_CONTROLLED=3Dno set in it.

Similarly as above, I've disabled it to avoid any possible issue.
Also, found it at the Xen wiki:

http://wiki.xen.org/wiki/Fedora_Host_Installation



>
> Why don't you just use 'virt-install' outright instead of doing
> it via xl and such?
> It also takes care of your images having the right SELinux permissions
> (I believe so).


You are true. I've used to use virt-install until it stopped to
support the xl toolstack (since Fedora 16).
Maybe now is working again...
Anyway, I've used xl just to check that the VM is working with Xen's xl alo=
ne.


>>        <interface type=3D'bridge'>
>>          <mac address=3D'00:00:00:00:00:00'/>
>
> Uuiuuh. Is that right? Shouldn't it have some value?

This is just  what libvirt translates from the native config file

>>
>> BOOOM:
>>
>> error: Failed to create domain from testvm.xml
>> error: End of file while reading data: Input/output error
>> error: One or more references were leaked after disconnect from the hype=
rvisor
>> error: Failed to reconnect to the hypervisor
>>
>
> So earlier version of libvirt (Fedora 20) has issues if the bridge
> was called anything but 'xenbr0' it would fail. Later (Fedora 21) is OK w=
ith it.
>
> I think that is what you are hitting (I was hitting that in Fedora 20
> when I was testing it out for Beta).
>
> Try changing the bridge name to 'xenbr0'.
>

Renamed the bridge to 'xenbr0':

xenbr0: flags=3D4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.10.15.10  netmask 255.255.255.0  broadcast 10.10.15.255
        inet6 fe80::219:99ff:feef:62ab  prefixlen 64  scopeid 0x20<link>
        ether 00:19:99:ef:62:ab  txqueuelen 0  (Ethernet)
        RX packets 8  bytes 1144 (1.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 8  bytes 648 (648.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

rebooted the machine... But same error

error: Failed to create domain from testvm.xml
error: End of file while reading data: Input/output error
error: One or more references were leaked after disconnect from the hypervi=
sor
error: Failed to reconnect to the hypervisor

> IF that does not help, edit the libvirt.cfg file to crank up the debugging
> and use 'journalctl -x' to see what it complains about.
>


Could you be more specific. Sorry, I'm not a sysadmin.
I'm using Xen for research purpose

Thank you very much!

-- Marco

--===============2104534197557030083==--

From konrad.wilk at oracle.com Sat Jun  6 11:10:07 2015
Content-Type: multipart/mixed; boundary="===============5883275535752121170=="
MIME-Version: 1.0
From: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
To: xen at lists.fedoraproject.org
Subject: Re: [Fedora-xen] [f20] Problem with libvirt + Xen XL toolstack
Date: Tue, 11 Nov 2014 11:43:55 -0500
Message-ID: <20141111164355.GA15019@laptop.dumpdata.com>
In-Reply-To: CABbE_O7zPpS-Cfsyp45yumQfkeJng-bgtPt57vkvvrTGF_KPHA@mail.gmail.com

--===============5883275535752121170==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 11, 2014 at 05:21:30PM +0100, Marco Guazzone wrote:
> On Tue, Nov 11, 2014 at 4:53 PM, Konrad Rzeszutek Wilk
> <konrad.wilk(a)oracle.com> wrote:
> =

> Hi Konrad,
> =

> >> 1. Disable SElinux
> >>   $ vi /etc/selinux/config
> >>     SELINUXTYPE=3Ddisabled
> >
> > Uh, not sure why you need that?
> =

> Just to avoid any possible interference... And, because I've found it
> at the Xen wiki
> =

> http://wiki.xen.org/wiki/Fedora_Host_Installation
> =

> >> 3. Disable Network Manager
> >>   $ systemctl disable NetworkManager
> >>   $ systemctl stop NetworkManager
> >
> > Network Manager can deal with the bridge as you have
> > NM_CONTROLLED=3Dno set in it.
> =

> Similarly as above, I've disabled it to avoid any possible issue.
> Also, found it at the Xen wiki:
> =

> http://wiki.xen.org/wiki/Fedora_Host_Installation
> =


gosh, thank you for reporting that. I've updated the Wiki pages to reflect
the status on Fedora 21.
> =

> =

> >
> > Why don't you just use 'virt-install' outright instead of doing
> > it via xl and such?
> > It also takes care of your images having the right SELinux permissions
> > (I believe so).
> =

> =

> You are true. I've used to use virt-install until it stopped to
> support the xl toolstack (since Fedora 16).
> Maybe now is working again...
> Anyway, I've used xl just to check that the VM is working with Xen's xl a=
lone.
> =

> =

> >>        <interface type=3D'bridge'>
> >>          <mac address=3D'00:00:00:00:00:00'/>
> >
> > Uuiuuh. Is that right? Shouldn't it have some value?
> =

> This is just  what libvirt translates from the native config file
> =

> >>
> >> BOOOM:
> >>
> >> error: Failed to create domain from testvm.xml
> >> error: End of file while reading data: Input/output error
> >> error: One or more references were leaked after disconnect from the hy=
pervisor
> >> error: Failed to reconnect to the hypervisor
> >>
> >
> > So earlier version of libvirt (Fedora 20) has issues if the bridge
> > was called anything but 'xenbr0' it would fail. Later (Fedora 21) is OK=
 with it.
> >
> > I think that is what you are hitting (I was hitting that in Fedora 20
> > when I was testing it out for Beta).
> >
> > Try changing the bridge name to 'xenbr0'.
> >
> =

> Renamed the bridge to 'xenbr0':
> =

> xenbr0: flags=3D4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
>         inet 10.10.15.10  netmask 255.255.255.0  broadcast 10.10.15.255
>         inet6 fe80::219:99ff:feef:62ab  prefixlen 64  scopeid 0x20<link>
>         ether 00:19:99:ef:62:ab  txqueuelen 0  (Ethernet)
>         RX packets 8  bytes 1144 (1.1 KiB)
>         RX errors 0  dropped 0  overruns 0  frame 0
>         TX packets 8  bytes 648 (648.0 B)
>         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> =

> rebooted the machine... But same error

I presume you also changed the entry in the xml file?

> =

> error: Failed to create domain from testvm.xml
> error: End of file while reading data: Input/output error
> error: One or more references were leaked after disconnect from the hyper=
visor
> error: Failed to reconnect to the hypervisor
> =

> > IF that does not help, edit the libvirt.cfg file to crank up the debugg=
ing
> > and use 'journalctl -x' to see what it complains about.
> >
> =

> =

> Could you be more specific. Sorry, I'm not a sysadmin.
> I'm using Xen for research purpose

Edit /etc/libvirt/libvirtd.conf

and change 'log_level' to be 'log_level=3D4'

and make sure that 'log_output' has '"1:syslog:libvirtd"

> =

> Thank you very much!
> =

> -- Marco
> --
> xen mailing list
> xen(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/xen

--===============5883275535752121170==--

From marco.guazzone at gmail.com Sat Jun  6 11:10:07 2015
Content-Type: multipart/mixed; boundary="===============0398686580242554497=="
MIME-Version: 1.0
From: Marco Guazzone <marco.guazzone at gmail.com>
To: xen at lists.fedoraproject.org
Subject: Re: [Fedora-xen] [f20] Problem with libvirt + Xen XL toolstack
Date: Tue, 11 Nov 2014 22:01:09 +0100
Message-ID: <CABbE_O6e3mgOC4ufwogaMwn3=BymMY0bKFGNd7V7Fc5ZZoxfbQ@mail.gmail.com>
In-Reply-To: 20141111164355.GA15019@laptop.dumpdata.com

--===============0398686580242554497==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 11, 2014 at 5:43 PM, Konrad Rzeszutek Wilk
<konrad.wilk(a)oracle.com> wrote:
>>
>> Renamed the bridge to 'xenbr0':
>>
>> xenbr0: flags=3D4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
>>         inet 10.10.15.10  netmask 255.255.255.0  broadcast 10.10.15.255
>>         inet6 fe80::219:99ff:feef:62ab  prefixlen 64  scopeid 0x20<link>
>>         ether 00:19:99:ef:62:ab  txqueuelen 0  (Ethernet)
>>         RX packets 8  bytes 1144 (1.1 KiB)
>>         RX errors 0  dropped 0  overruns 0  frame 0
>>         TX packets 8  bytes 648 (648.0 B)
>>         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>>
>> rebooted the machine... But same error
>
> I presume you also changed the entry in the xml file?

Yep!

    <interface type=3D'bridge'>
      <mac address=3D'00:00:00:00:00:00'/>
      <source bridge=3D'xenbr0'/>
      <script path=3D'vif-bridge'/>
    </interface>


>>
>> Could you be more specific. Sorry, I'm not a sysadmin.
>> I'm using Xen for research purpose
>
> Edit /etc/libvirt/libvirtd.conf
>
> and change 'log_level' to be 'log_level=3D4'
>
> and make sure that 'log_output' has '"1:syslog:libvirtd"

OK. Changed /etc/libvirt/libvirtd.conf:

log_level =3D 4
log_outputs=3D"1:syslog:libvirtd"

Then rebooted and tried to create the VM with libvirt with virsh.

This is the output of /var/log/libvirt/libxl/testvm.log

libxl: verbose:
libxl_create.c:130:libxl__domain_build_info_setdefault: qemu-xen is
unavailable, use qemu-xen-traditional instead: No such file or
directory
libxl: debug: libxl_create.c:1243:do_domain_create: ao 0x7f713c002a80:
create: how=3D(nil) callback=3D(nil) poller=3D0x7f713c009ee0
libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
vdev=3Dhda spec.backend=3Dtap
libxl: debug: libxl_device.c:212:disk_try_backend: Disk vdev=3Dhda,
backend tap unsuitable because blktap not available
libxl: error: libxl_device.c:300:libxl__device_disk_set_backend: no
suitable backend for disk hda
libxl: error: libxl_dm.c:1305:libxl__destroy_device_model: could not
find device-model's pid for dom 3
libxl: error: libxl.c:1420:libxl__destroy_domid:
libxl__destroy_device_model failed for 3
libxl: debug: libxl_event.c:1569:libxl__ao_complete: ao
0x7f713c002a80: complete, rc=3D-3
libxl: debug: libxl_create.c:1256:do_domain_create: ao 0x7f713c002a80:
inprogress: poller=3D0x7f713c009ee0, flags=3Dic
libxl: debug: libxl_event.c:1541:libxl__ao__destroy: ao 0x7f713c002a80: des=
troy


Don't know if it is OK, but the first row claims about the missing
device model qemu-xen...
Then there are a couple of errors about the disk device back-end and
the device model, but honestly I have some trouble in finding a way to
fix them

In /var/log/libvirt/libxl-driver.log, there isn't nothing of interest (IMO):

xc: debug: hypercall buffer: total allocations:18 total releases:18
xc: debug: hypercall buffer: current allocations:0 maximum allocations:4
xc: debug: hypercall buffer: cache current size:4
xc: debug: hypercall buffer: cache hits:13 misses:4 toobig:1

Cheers,

-- Marco

--===============0398686580242554497==--

From konrad.wilk at oracle.com Sat Jun  6 11:10:07 2015
Content-Type: multipart/mixed; boundary="===============5389803206697167364=="
MIME-Version: 1.0
From: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
To: xen at lists.fedoraproject.org
Subject: Re: [Fedora-xen] [f20] Problem with libvirt + Xen XL toolstack
Date: Tue, 11 Nov 2014 17:11:13 -0500
Message-ID: <20141111221113.GB30289@laptop.dumpdata.com>
In-Reply-To: CABbE_O6e3mgOC4ufwogaMwn3=BymMY0bKFGNd7V7Fc5ZZoxfbQ@mail.gmail.com

--===============5389803206697167364==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 11, 2014 at 10:01:09PM +0100, Marco Guazzone wrote:
> On Tue, Nov 11, 2014 at 5:43 PM, Konrad Rzeszutek Wilk
> <konrad.wilk(a)oracle.com> wrote:
> >>
> >> Renamed the bridge to 'xenbr0':
> >>
> >> xenbr0: flags=3D4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
> >>         inet 10.10.15.10  netmask 255.255.255.0  broadcast 10.10.15.255
> >>         inet6 fe80::219:99ff:feef:62ab  prefixlen 64  scopeid 0x20<lin=
k>
> >>         ether 00:19:99:ef:62:ab  txqueuelen 0  (Ethernet)
> >>         RX packets 8  bytes 1144 (1.1 KiB)
> >>         RX errors 0  dropped 0  overruns 0  frame 0
> >>         TX packets 8  bytes 648 (648.0 B)
> >>         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> >>
> >> rebooted the machine... But same error
> >
> > I presume you also changed the entry in the xml file?
> =

> Yep!
> =

>     <interface type=3D'bridge'>
>       <mac address=3D'00:00:00:00:00:00'/>
>       <source bridge=3D'xenbr0'/>
>       <script path=3D'vif-bridge'/>
>     </interface>
> =

> =

> >>
> >> Could you be more specific. Sorry, I'm not a sysadmin.
> >> I'm using Xen for research purpose
> >
> > Edit /etc/libvirt/libvirtd.conf
> >
> > and change 'log_level' to be 'log_level=3D4'
> >
> > and make sure that 'log_output' has '"1:syslog:libvirtd"
> =

> OK. Changed /etc/libvirt/libvirtd.conf:
> =

> log_level =3D 4
> log_outputs=3D"1:syslog:libvirtd"
> =

> Then rebooted and tried to create the VM with libvirt with virsh.
> =

> This is the output of /var/log/libvirt/libxl/testvm.log
> =

> libxl: verbose:
> libxl_create.c:130:libxl__domain_build_info_setdefault: qemu-xen is
> unavailable, use qemu-xen-traditional instead: No such file or
> directory
> libxl: debug: libxl_create.c:1243:do_domain_create: ao 0x7f713c002a80:
> create: how=3D(nil) callback=3D(nil) poller=3D0x7f713c009ee0
> libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
> vdev=3Dhda spec.backend=3Dtap

Somehow it picked 'tap'.

> libxl: debug: libxl_device.c:212:disk_try_backend: Disk vdev=3Dhda,
> backend tap unsuitable because blktap not available

Which is not available under Xen 4.4.

I am not sure why it did that as you have:

   <disk type=3D'file' device=3D'disk'>
         <driver name=3D'file'/>
         <source file=3D'/root/images/testvm.img'/>
         <target dev=3D'hda' bus=3D'ide'/>


So there might be need to alter the guest config a bit more, but
I am not sure what needs to be done. I will see what my entry looks
like tomorrow.

Also CC-ing Jim as he might have better idea.
> libxl: error: libxl_device.c:300:libxl__device_disk_set_backend: no
> suitable backend for disk hda
> libxl: error: libxl_dm.c:1305:libxl__destroy_device_model: could not
> find device-model's pid for dom 3
> libxl: error: libxl.c:1420:libxl__destroy_domid:
> libxl__destroy_device_model failed for 3
> libxl: debug: libxl_event.c:1569:libxl__ao_complete: ao
> 0x7f713c002a80: complete, rc=3D-3
> libxl: debug: libxl_create.c:1256:do_domain_create: ao 0x7f713c002a80:
> inprogress: poller=3D0x7f713c009ee0, flags=3Dic
> libxl: debug: libxl_event.c:1541:libxl__ao__destroy: ao 0x7f713c002a80: d=
estroy
> =

> =

> Don't know if it is OK, but the first row claims about the missing
> device model qemu-xen...
> Then there are a couple of errors about the disk device back-end and
> the device model, but honestly I have some trouble in finding a way to
> fix them
> =

> In /var/log/libvirt/libxl-driver.log, there isn't nothing of interest (IM=
O):
> =

> xc: debug: hypercall buffer: total allocations:18 total releases:18
> xc: debug: hypercall buffer: current allocations:0 maximum allocations:4
> xc: debug: hypercall buffer: cache current size:4
> xc: debug: hypercall buffer: cache hits:13 misses:4 toobig:1
> =

> Cheers,
> =

> -- Marco
> --
> xen mailing list
> xen(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/xen

--===============5389803206697167364==--

From marco.guazzone at gmail.com Sat Jun  6 11:10:08 2015
Content-Type: multipart/mixed; boundary="===============8012595647087503811=="
MIME-Version: 1.0
From: Marco Guazzone <marco.guazzone at gmail.com>
To: xen at lists.fedoraproject.org
Subject: Re: [Fedora-xen] [f20] Problem with libvirt + Xen XL toolstack
Date: Wed, 12 Nov 2014 10:46:36 +0100
Message-ID: <CABbE_O6inuDP4J1mJsTOYi_xG7F_GDL+KBW_8GQwzGvwLa3VLw@mail.gmail.com>
In-Reply-To: 5462F6A5.1080607@suse.com

--===============8012595647087503811==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 12, 2014 at 6:56 AM, Jim Fehlig <jfehlig(a)suse.com> wrote:
> Konrad Rzeszutek Wilk wrote:
>> On Tue, Nov 11, 2014 at 10:01:09PM +0100, Marco Guazzone wrote:
>>
>>> On Tue, Nov 11, 2014 at 5:43 PM, Konrad Rzeszutek Wilk
>>> <konrad.wilk(a)oracle.com> wrote:
>>>
>>>>> Renamed the bridge to 'xenbr0':
>>>>>
>>>>> xenbr0: flags=3D4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
>>>>>         inet 10.10.15.10  netmask 255.255.255.0  broadcast 10.10.15.2=
55
>>>>>         inet6 fe80::219:99ff:feef:62ab  prefixlen 64  scopeid 0x20<li=
nk>
>>>>>         ether 00:19:99:ef:62:ab  txqueuelen 0  (Ethernet)
>>>>>         RX packets 8  bytes 1144 (1.1 KiB)
>>>>>         RX errors 0  dropped 0  overruns 0  frame 0
>>>>>         TX packets 8  bytes 648 (648.0 B)
>>>>>         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>>>>>
>>>>> rebooted the machine... But same error
>>>>>
>>>> I presume you also changed the entry in the xml file?
>>>>
>>> Yep!
>>>
>>>     <interface type=3D'bridge'>
>>>       <mac address=3D'00:00:00:00:00:00'/>
>>>       <source bridge=3D'xenbr0'/>
>>>       <script path=3D'vif-bridge'/>
>>>     </interface>
>>>
>>>
>>>
>>>>> Could you be more specific. Sorry, I'm not a sysadmin.
>>>>> I'm using Xen for research purpose
>>>>>
>>>> Edit /etc/libvirt/libvirtd.conf
>>>>
>>>> and change 'log_level' to be 'log_level=3D4'
>>>>
>>>> and make sure that 'log_output' has '"1:syslog:libvirtd"
>>>>
>>> OK. Changed /etc/libvirt/libvirtd.conf:
>>>
>>> log_level =3D 4
>>>
>
> FYI, log level 4 is the default, so this doesn't change anything.  You
> probably want debug log level (log_level =3D 1).
>

Hi all,

OK. I've changed to log_level to 1 (DEBUG)


>
> What version of libvirt?  You might need
>
> http://libvirt.org/git/?p=3Dlibvirt.git;a=3Dcommit;h=3D48d81cef3b2dff6fe0=
2bd7c8f0bf4f5aff917d8c
>
> which is in libvirt 1.2.6.
>

Ah, this also explains why if I turn to use the old xend toolstack in
place of XL, libvirt works correctly.
So, the problem is in the libxl driver of libvirt

I have version 1.1.3.6-1.fc20 (i.e., the one shipped with Fedora 20)

>>
>>> libxl: debug: libxl_device.c:212:disk_try_backend: Disk vdev=3Dhda,
>>> backend tap unsuitable because blktap not available
>>>
>>
>> Which is not available under Xen 4.4.
>>
>> I am not sure why it did that as you have:
>>
>>    <disk type=3D'file' device=3D'disk'>
>>          <driver name=3D'file'/>
>>
>
> If you don't have the above patch, use <driver name=3D'qemu'/> to
> explicitly request qdisk.


I've change the XML and replaced
  <driver name=3D'file'/>
with the above element for both the 'disk' and the 'cdrom' devices:
  <devices>
    <disk type=3D'file' device=3D'disk'>
<!--
      <driver name=3D'file'/>
-->
      <driver name=3D'qemu'/>
      <source file=3D'/root/images/testvm.img'/>
      <target dev=3D'hda' bus=3D'ide'/>
    </disk>
    <disk type=3D'file' device=3D'cdrom'>
<!--
      <driver name=3D'file'/>
-->
      <driver name=3D'qemu'/>
      <source file=3D'/root/iso/CentOS-7.0-1406-x86_64-Minimal.iso'/>
      <target dev=3D'hdc' bus=3D'ide'/>
      <readonly/>
    </disk>
    ...
  </devices>

Then rebooted and created the VM with virsh.

Still fail. Here's what I got.

$ virsh create testvm.xml
error: Failed to create domain from testvm.xml
error: internal error: libxenlight failed to create new domain 'testvm'

cat /var/log/libvirt/libxl/testvm.log:

libxl: verbose:
libxl_create.c:130:libxl__domain_build_info_setdefault: qemu-xen is
unavailable, use qemu-xen-traditional instead: No such file or
directory
libxl: debug: libxl_create.c:1243:do_domain_create: ao 0x7fb67c0027a0:
create: how=3D(nil) callback=3D(nil) poller=3D0x7fb67c002370
libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
vdev=3Dhda spec.backend=3Dqdisk
libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
vdev=3Dhdc spec.backend=3Dqdisk
libxl: debug: libxl_create.c:699:initiate_domain_create: running bootloader
libxl: debug: libxl_bootloader.c:321:libxl__bootloader_run: not a PV
domain, skipping bootloader
libxl: debug: libxl_event.c:608:libxl__ev_xswatch_deregister: watch
w=3D0x7fb67c002b28: deregister unregistered
libxl: debug: libxl_numa.c:478:libxl__get_numa_candidate: New best
NUMA placement candidate found: nr_nodes=3D1, nr_cpus=3D8, nr_vcpus=3D17,
free_memkb=3D2699
libxl: detail: libxl_dom.c:195:numa_place_domain: NUMA placement
candidate with 1 nodes, 8 cpus and 2699 KB free selected
xc: detail: elf_parse_binary: phdr: paddr=3D0x100000 memsz=3D0xa2304
xc: detail: elf_parse_binary: memory: 0x100000 -> 0x1a2304
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001a2304
  Modules:       0000000000000000->0000000000000000
  TOTAL:         0000000000000000->00000000bf800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000001
xc: detail: elf_load_binary: phdr 0 at 0x7fb6a7b13000 -> 0x7fb6a7bac18d
libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
vdev=3Dhda spec.backend=3Dqdisk
libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
vdev=3Dhdc spec.backend=3Dqdisk
libxl: debug: libxl_dm.c:1211:libxl__spawn_local_dm: Spawning
device-model /usr/lib/xen/bin/qemu-dm with arguments:
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   /usr/lib/xen/bin/qem=
u-dm
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   -d
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   2
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   -domain-name
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   testvm
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   -vnc
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   127.0.0.1:0
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   -videoram
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   8
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   -boot
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   cc
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   -vcpu_avail
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   0x01
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   -net
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   none
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   -M
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   xenfv
libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch
w=3D0x7fb67c002d60 wpath=3D/local/domain/0/device-model/2/state token=3D3/0:
register slotnum=3D3
libxl: debug: libxl_create.c:1256:do_domain_create: ao 0x7fb67c0027a0:
inprogress: poller=3D0x7fb67c002370, flags=3Di
libxl: debug: libxl_event.c:503:watchfd_callback: watch
w=3D0x7fb67c002d60 wpath=3D/local/domain/0/device-model/2/state token=3D3/0:
event epath=3D/local/domain/0/device-model/2/state
libxl: debug: libxl_event.c:596:libxl__ev_xswatch_deregister: watch
w=3D0x7fb67c002d60 wpath=3D/local/domain/0/device-model/2/state token=3D3/0:
deregister slotnum=3D3
libxl: error: libxl_dm.c:1280:device_model_spawn_outcome: domain 2
device model: spawn failed (rc=3D-3)
libxl: error: libxl_create.c:1088:domcreate_devmodel_started: device
model did not start: -3
libxl: error: libxl_dm.c:1311:libxl__destroy_device_model: Device
Model already exited
libxl: debug: libxl_event.c:1569:libxl__ao_complete: ao
0x7fb67c0027a0: complete, rc=3D-3
libxl: debug: libxl_event.c:1541:libxl__ao__destroy: ao 0x7fb67c0027a0: des=
troy


Cheers,

-- Marco

--===============8012595647087503811==--

From marco.guazzone at gmail.com Sat Jun  6 11:10:08 2015
Content-Type: multipart/mixed; boundary="===============7921078642170197478=="
MIME-Version: 1.0
From: Marco Guazzone <marco.guazzone at gmail.com>
To: xen at lists.fedoraproject.org
Subject: Re: [Fedora-xen] [f20] Problem with libvirt + Xen XL toolstack
Date: Wed, 12 Nov 2014 17:03:49 +0100
Message-ID: <CABbE_O6CqnKGKdLtfuwMy=2=OriNUmMfvAh6KrZSS7D-vV84VA@mail.gmail.com>
In-Reply-To: 54637CA8.6040800@suse.com

--===============7921078642170197478==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 12, 2014 at 4:28 PM, Jim Fehlig <jfehlig(a)suse.com> wrote:
>
> This says the device model (which appears to be qemu-dm in your case)
> failed to run.  /var/log/xen/qemu-dm-<vm_name>.log should have some info
> telling why qemu failed.
>

It says:

domid: 2
Boot device 'c' was given twice

Looking at the XML, I see there are two "boot" elements. So I've tried
to comment one of them:
  <os>
    <type arch=3D'x86_64' machine=3D'xenfv'>hvm</type>
    <loader>/usr/lib/xen/boot/hvmloader</loader>
    <boot dev=3D'hd'/>
<!--
    <boot dev=3D'hd'/>
-->
  </os>
Interestingly, these two elements were generated by libvirt with
"virsh -c xen:/// domxml-from-native xen-xm testvm.cfg"

Then, I've tried to start the VM with "virsh create", but still problems.
Appartently, it seemed to work since I see it as "running" with "virsh list=
".
However, (1) I'm unable to connect with vncviewer, and (2) after a
while the VM stops.

Here below is the content of the logs:

/var/log/libvirt/libxl/testvm.log:

libxl: verbose:
libxl_create.c:130:libxl__domain_build_info_setdefault: qemu-xen is
unavailable, use qemu-xen-traditional instead: No such file or
directory
libxl: debug: libxl_create.c:1243:do_domain_create: ao 0x7fb678002900:
create: how=3D(nil) callback=3D(nil) poller=3D0x7fb6780011b0
libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
vdev=3Dhda spec.backend=3Dqdisk
libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
vdev=3Dhdc spec.backend=3Dqdisk
libxl: debug: libxl_create.c:699:initiate_domain_create: running bootloader
libxl: debug: libxl_bootloader.c:321:libxl__bootloader_run: not a PV
domain, skipping bootloader
libxl: debug: libxl_event.c:608:libxl__ev_xswatch_deregister: watch
w=3D0x7fb678002c88: deregister unregistered
libxl: debug: libxl_numa.c:478:libxl__get_numa_candidate: New best
NUMA placement candidate found: nr_nodes=3D1, nr_cpus=3D8, nr_vcpus=3D17,
free_memkb=3D2698
libxl: detail: libxl_dom.c:195:numa_place_domain: NUMA placement
candidate with 1 nodes, 8 cpus and 2698 KB free selected
xc: detail: elf_parse_binary: phdr: paddr=3D0x100000 memsz=3D0xa2304
xc: detail: elf_parse_binary: memory: 0x100000 -> 0x1a2304
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001a2304
  Modules:       0000000000000000->0000000000000000
  TOTAL:         0000000000000000->00000000bf800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000001
xc: detail: elf_load_binary: phdr 0 at 0x7fb6a7af8000 -> 0x7fb6a7b9118d
libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
vdev=3Dhda spec.backend=3Dqdisk
libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
vdev=3Dhdc spec.backend=3Dqdisk
libxl: debug: libxl_dm.c:1211:libxl__spawn_local_dm: Spawning
device-model /usr/lib/xen/bin/qemu-dm with arguments:
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   /usr/lib/xen/bin/qem=
u-dm
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   -d
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   9
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   -domain-name
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   testvm
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   -vnc
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   127.0.0.1:1
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   -videoram
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   8
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   -boot
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   c
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   -vcpu_avail
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   0x01
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   -net
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   none
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   -M
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   xenfv
libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch
w=3D0x7fb678002ec0 wpath=3D/local/domain/0/device-model/9/state token=3D3/0:
register slotnum=3D3
libxl: debug: libxl_create.c:1256:do_domain_create: ao 0x7fb678002900:
inprogress: poller=3D0x7fb6780011b0, flags=3Di
libxl: debug: libxl_event.c:503:watchfd_callback: watch
w=3D0x7fb678002ec0 wpath=3D/local/domain/0/device-model/9/state token=3D3/0:
event epath=3D/local/domain/0/device-model/9/state
libxl: debug: libxl_event.c:503:watchfd_callback: watch
w=3D0x7fb678002ec0 wpath=3D/local/domain/0/device-model/9/state token=3D3/0:
event epath=3D/local/domain/0/device-model/9/state
libxl: debug: libxl_event.c:596:libxl__ev_xswatch_deregister: watch
w=3D0x7fb678002ec0 wpath=3D/local/domain/0/device-model/9/state token=3D3/0:
deregister slotnum=3D3
libxl: debug: libxl_event.c:608:libxl__ev_xswatch_deregister: watch
w=3D0x7fb678002ec0: deregister unregistered
libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch
w=3D0x7fb678006b18 wpath=3D/local/domain/0/backend/vif/9/0/state
token=3D3/1: register slotnum=3D3
libxl: debug: libxl_event.c:503:watchfd_callback: watch
w=3D0x7fb678006b18 wpath=3D/local/domain/0/backend/vif/9/0/state
token=3D3/1: event epath=3D/local/domain/0/backend/vif/9/0/state
libxl: debug: libxl_event.c:643:devstate_watch_callback: backend
/local/domain/0/backend/vif/9/0/state wanted state 2 ok
libxl: debug: libxl_event.c:596:libxl__ev_xswatch_deregister: watch
w=3D0x7fb678006b18 wpath=3D/local/domain/0/backend/vif/9/0/state
token=3D3/1: deregister slotnum=3D3
libxl: debug: libxl_event.c:608:libxl__ev_xswatch_deregister: watch
w=3D0x7fb678006b18: deregister unregistered
libxl: debug: libxl_device.c:959:device_hotplug: calling hotplug
script: /etc/xen/scripts/vif-bridge online
libxl: debug: libxl_event.c:1737:libxl__ao_progress_report: ao
0x7fb678002900: progress report: ignored
libxl: debug: libxl_event.c:1569:libxl__ao_complete: ao
0x7fb678002900: complete, rc=3D0
libxl: debug: libxl_event.c:1541:libxl__ao__destroy: ao 0x7fb678002900: des=
troy
libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch
w=3D0x7fb678001cf0 wpath=3D@releaseDomain token=3D3/2: register slotnum=3D3
libxl: debug: libxl_event.c:503:watchfd_callback: watch
w=3D0x7fb678001cf0 wpath=3D@releaseDomain token=3D3/2: event
epath=3D@releaseDomain
libxl: debug: libxl.c:1004:domain_death_xswatch_callback:
[evg=3D0x7fb678001810:9] from domid=3D9 nentries=3D1 rc=3D1
libxl: debug: libxl.c:1015:domain_death_xswatch_callback:
[evg=3D0x7fb678001810:9]   got=3Ddomaininfos[0] got->domain=3D9
libxl: debug: libxl.c:1042:domain_death_xswatch_callback:  exists
shutdown_reported=3D0 dominf.flags=3Dffff0022
libxl: debug: libxl.c:1008:domain_death_xswatch_callback: [evg=3D0] all rep=
orted
libxl: debug: libxl.c:1072:domain_death_xswatch_callback: domain death
search done
libxl: debug: libxl_event.c:503:watchfd_callback: watch
w=3D0x7fb678001cf0 wpath=3D@releaseDomain token=3D3/2: event
epath=3D@releaseDomain
libxl: debug: libxl.c:1004:domain_death_xswatch_callback:
[evg=3D0x7fb678001810:9] from domid=3D9 nentries=3D1 rc=3D1
libxl: debug: libxl.c:1015:domain_death_xswatch_callback:
[evg=3D0x7fb678001810:9]   got=3Ddomaininfos[0] got->domain=3D9
libxl: debug: libxl.c:1042:domain_death_xswatch_callback:  exists
shutdown_reported=3D0 dominf.flags=3D6
libxl: debug: libxl.c:1054:domain_death_xswatch_callback:  shutdown reporti=
ng
libxl: debug: libxl.c:1008:domain_death_xswatch_callback: [evg=3D0] all rep=
orted
libxl: debug: libxl.c:1072:domain_death_xswatch_callback: domain death
search done
libxl: debug: libxl_event.c:1154:egc_run_callbacks: event
0x7fb6a99f1ad0 callback type=3Ddomain_shutdown
libxl: debug: libxl.c:1256:libxl_domain_destroy: ao 0x7fb6a99f1b60:
create: how=3D(nil) callback=3D(nil) poller=3D0x7fb6780011b0
libxl: debug: libxl_dm.c:1314:libxl__destroy_device_model: Device Model sig=
naled
libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch
w=3D0x7fb6a99f08a8 wpath=3D/local/domain/0/backend/vif/9/0/state
token=3D2/3: register slotnum=3D2
libxl: debug: libxl.c:1265:libxl_domain_destroy: ao 0x7fb6a99f1b60:
inprogress: poller=3D0x7fb6780011b0, flags=3Di
libxl: debug: libxl_event.c:503:watchfd_callback: watch
w=3D0x7fb6a99f08a8 wpath=3D/local/domain/0/backend/vif/9/0/state
token=3D2/3: event epath=3D/local/domain/0/backend/vif/9/0/state
libxl: debug: libxl_event.c:643:devstate_watch_callback: backend
/local/domain/0/backend/vif/9/0/state wanted state 6 ok
libxl: debug: libxl_event.c:596:libxl__ev_xswatch_deregister: watch
w=3D0x7fb6a99f08a8 wpath=3D/local/domain/0/backend/vif/9/0/state
token=3D2/3: deregister slotnum=3D2
libxl: debug: libxl_event.c:608:libxl__ev_xswatch_deregister: watch
w=3D0x7fb6a99f08a8: deregister unregistered
libxl: debug: libxl_device.c:959:device_hotplug: calling hotplug
script: /etc/xen/scripts/vif-bridge offline
libxl: debug: libxl_event.c:472:watchfd_callback: watch
epath=3D/local/domain/0/backend/vif/9/0/state token=3D2/3: empty slot
libxl: debug: libxl_event.c:472:watchfd_callback: watch
epath=3D/local/domain/0/backend/vif/9/0/state token=3D2/3: empty slot
libxl: debug: libxl_event.c:1569:libxl__ao_complete: ao
0x7fb6a99f1b60: complete, rc=3D0
libxl: debug: libxl_event.c:1541:libxl__ao__destroy: ao 0x7fb6a99f1b60: des=
troy
libxl: debug: libxl_event.c:596:libxl__ev_xswatch_deregister: watch
w=3D0x7fb678001cf0 wpath=3D@releaseDomain token=3D3/2: deregister slotnum=
=3D3
libxl: debug: libxl_event.c:472:watchfd_callback: watch
epath=3D@releaseDomain token=3D3/2: empty slot


/var/log/xen/qemu-dm-testvm.log:

domid: 9
-videoram option does not work with cirrus vga device model. Videoram set t=
o 4M.
Strip off blktap sub-type prefix to /root/images/testvm.img (drv 'aio')
Using file /root/images/testvm.img in read-write mode
Strip off blktap sub-type prefix to
/root/iso/CentOS-7.0-1406-x86_64-Minimal.iso (drv 'aio')
Using file /root/iso/CentOS-7.0-1406-x86_64-Minimal.iso in read-only mode
Watching /local/domain/0/device-model/9/logdirty/cmd
Watching /local/domain/0/device-model/9/command
Watching /local/domain/9/cpu
qemu_map_cache_init nr_buckets =3D 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid =3D 93f08541-bfd5-4ac4-851d-c619a4516a13
populating video RAM at ff000000
mapping video RAM from ff000000
Register xen platform.
Done register platform.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw st=
ate.
xs_read(/local/domain/0/device-model/9/xen_extended_power_mgmt): read error
xs_read(): vncpasswd get error.
/vm/93f08541-bfd5-4ac4-851d-c619a4516a13/vncpasswd.
medium change watch on `hdc' (index: 1):
aio:/root/iso/CentOS-7.0-1406-x86_64-Minimal.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
vcpu-set: watch node error.
[xenstore_process_vcpu_set_event]: /local/domain/9/cpu has no CPU!
xs_read(/local/domain/9/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/9/log-throttling'
medium change watch on `/local/domain/9/log-throttling' - unknown
device, ignored
cirrus vga map change while on lfb mode
mapping vram to f0000000 - f0400000
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw st=
ate.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro st=
ate.


Just FYI, I've tried to start the VM directly with "xl" and it works:
the VM runs and vncviewer happily connects.
Here's the content of /var/log/xen/qemu-dm-testvm.log:

domid: 10
-videoram option does not work with cirrus vga device model. Videoram set t=
o 4M.
Strip off blktap sub-type prefix to /root/images/testvm.img (drv 'aio')
Using file /root/images/testvm.img in read-write mode
Strip off blktap sub-type prefix to
/root/iso/CentOS-7.0-1406-x86_64-Minimal.iso (drv 'aio')
Using file /root/iso/CentOS-7.0-1406-x86_64-Minimal.iso in read-only mode
Watching /local/domain/0/device-model/10/logdirty/cmd
Watching /local/domain/0/device-model/10/command
Watching /local/domain/10/cpu
qemu_map_cache_init nr_buckets =3D 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid =3D 93f08541-bfd5-4ac4-851d-c619a4516a13
populating video RAM at ff000000
mapping video RAM from ff000000
Register xen platform.
Done register platform.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw st=
ate.
xs_read(/local/domain/0/device-model/10/xen_extended_power_mgmt): read error
xs_read(): vncpasswd get error.
/vm/93f08541-bfd5-4ac4-851d-c619a4516a13/vncpasswd.
medium change watch on `hdc' (index: 1):
aio:/root/iso/CentOS-7.0-1406-x86_64-Minimal.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
vcpu-set: watch node error.
[xenstore_process_vcpu_set_event]: /local/domain/10/cpu has no CPU!
xs_read(/local/domain/10/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/10/log-throttling'
medium change watch on `/local/domain/10/log-throttling' - unknown
device, ignored
cirrus vga map change while on lfb mode
mapping vram to f0000000 - f0400000
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw st=
ate.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro st=
ate.
Unknown PV product 3 loaded in guest
PV driver build 1
region type 1 at [c100,c200).
region type 0 at [f3001000,f3001100).
squash iomem [f3001000, f3001100).
ACPI:debug: write addr=3D0xb044, val=3D0x0.
ACPI:debug: write addr=3D0xb045, val=3D0x89.
ACPI:debug: write addr=3D0xb044, val=3D0x1.
ACPI:debug: write addr=3D0xb045, val=3D0x89.
...
ACPI:debug: write addr=3D0xb044, val=3D0xff.
ACPI:debug: write addr=3D0xb045, val=3D0x89.


Cheers,

-- Marco

--===============7921078642170197478==--

From bill at bfccomputing.com Sat Jun  6 11:10:08 2015
Content-Type: multipart/mixed; boundary="===============2165587755094539353=="
MIME-Version: 1.0
From: Bill McGonigle <bill at bfccomputing.com>
To: xen at lists.fedoraproject.org
Subject: [Fedora-xen] Enable Xen in f20 qemu? [Was: Xen 4.4 RC2 [TestDay]]
Date: Wed, 12 Nov 2014 12:19:39 -0500
Message-ID: <546396AB.3010109@bfccomputing.com>
In-Reply-To: 1390292149.23576.49.camel@Solace

--===============2165587755094539353==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

On 01/21/14 03:15, Dario Faggioli wrote:
> While investigating, we also spotted this:
> http://pkgs.fedoraproject.org/cgit/qemu.git/tree/qemu.spec?h=3Df20
> =

> Which contains the following:
> =

> dobuild() {
>     ./configure \
>         --prefix=3D%{_prefix} \
>         --libdir=3D%{_libdir} \
>         --sysconfdir=3D%{_sysconfdir} \
>         --interp-prefix=3D%{_prefix}/qemu-%%M \
>         --audio-drv-list=3Dpa,sdl,alsa,oss \
>         --localstatedir=3D%{_localstatedir} \
>         --libexecdir=3D%{_libexecdir} \
>         --disable-strip \
>         --extra-ldflags=3D"$extraldflags -pie -Wl,-z,relro -Wl,-z,now" \
>         --extra-cflags=3D"%{optflags} -fPIE -DPIE" \
>         --enable-mixemu \
>         --enable-trace-backend=3Ddtrace \
>         --disable-werror \
>         --disable-xen \
>         --enable-kvm \
> ...
> =

> which seems to suggest that xen support is disabled in Fedora's qemu
> package. Should we ask why they do that, and investigate whether that
> can change (and, of course, whether that is enough for us) ?

This still seems to be true - I guess I've been building my own for a
long time or using virt-preview and just now had the opportunity to
notice that the stock f20 qemu still fails with virt-install.

# virt-install --name=3Dtestvm --ram=3D2048 --vcpus=3D2 --cpuset=3D2-11
--location=3Dhttp://librescu/cobbler/ks_mirror/centos6-x86_64
--os-type=3Dlinux --os-variant=3Drhel6 --disk
path=3D/dev/zvol/storage/testvm/boot --disk
path=3D/dev/zvol/storage/testvm/root --network
bridge=3Dbr0,mac=3D02:00:0a:0a:0a:19 --graphics=3Dvnc --paravirt --arch=3Dx=
86_64
--virt-type=3Dxen

yields:

# tail -100 /var/log/libvirt/libxl/testvm.log  | grep
libxl__spawn_local_dm | grep -v Spawning | cut -f 6 -d ' '| xargs echo
/usr/bin/qemu-system-i386 -xen-domid 13 -chardev
socket,id=3Dlibxl-cmd,path=3D/var/run/xen/qmp-libxl-13,server,nowait -mon
chardev=3Dlibxl-cmd,mode=3Dcontrol -nodefaults -xen-attach -name testvm -vnc
127.0.0.1:0 -k en-us -machine xenpv -m 2049

which gives:

  Option xen-domid not supported for this target

etc.  I see the f21 version (I built the matching version from
virt-preview on f20) works fine and I've been using the above pattern
for a couple years on f[1?-20].  Is it time to just enable xen for f20
since it works and f20 will be supported for a while yet?  It was a
little tricky (aka time-consuming) for me to track this down and I have
a slight clue how the parts work - failing for historical reasons seems
to be incorrect and will unnecessarily confuse a large part of the user
base.

-Bill

-- =

Bill McGonigle, Owner
BFC Computing, LLC
http://bfccomputing.com/
Telephone: +1.855.SW.LIBRE
Email, IM, VOIP: bill(a)bfccomputing.com
VCard: http://bfccomputing.com/vcard/bill.vcf
Social networks: bill_mcgonigle/bill.mcgonigle


--===============2165587755094539353==
Content-Type: application/pgp-signature
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="signature.asc"

LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEKCmlRSWNCQUVC
QWdBR0JRSlVZNWJBQUFvSkVJcUJqRGZwUHNLZ2xoWVAvQTVKMHB4SVM2M0crdWVCY1hZNlpQQ0gK
MGl4UVJtV1krRXdxb1VjTlBEZnlYNjdBRGxwSkFaelY0YnRPUDVwbnduKzQ5aHgvNzIyVVRRMjEv
VzdhZHlLVQpDMlhCSXBkbUVBVll4Qm1ldzFQM09tYjZtK0dqSG1DdDZSTmhnWml1bFRLL0crN2U4
UkYwMkZJeWQ0ZCsxTzFWCkpOVlFTZnowc2xQRlpPZW5PK1psV0hYNVBKL0I5M3VnQlNsdVdnZGx3
ajBFZSt0clB6SjJFdktPeWdXMGhTMnoKZXJFMnJEVnlKZlZSWkpQS3R5Snp4NGNLNkI4eUtkeW84
Z0gzYUFLblhqendtREcrbmhZMDExZjF5T2w4UGN2QQpkbWcyL2NQTnpqVzh6WldmWEtkeEltNTlp
TW9NdGkzandtWUU1ekNRckorNEtTZzBYSHZwVjF5ZUtMUEhLbUQ3CmJVYUlaZ0pCMFp0WHMzT0FJ
WFpLWjRnOTJweGkwaTVnbWRLdTV1d0FDVEJ0aGV1OXNPY1JNZkF0MFBYMXZqejIKMWRJc2E1VUNy
dGEyM1pkcUkwRVFyVytKank3blZjcUVDVm1JMDlTbjdOTDJhOHZHZWQrelNWa01uVk51Vko5eQor
QmRPeGpqS1JUbmxZT04yQzRKUXg1TUVzaU0vTndFSEptS2RkZW8wRjVBQXlzZlF4R3UrbU8vV2h5
UTBLNWY5ClBzQnBCTk42dnBWc2JxUTJYRWMzRExpWGd2VCs0bVg2ZW9nK0h0b01xTlgydEdPOVRs
ckFtODRGblRFZWJ0NEcKL2NvMjllMCs0aXRZWFMyNXdPNWJsSTE2RVYyTmRLa01YVmVyNmVja2dE
QUg3cklHVThIZDU5T2dwbXZPUmRYbgpTWndIZjMrTkhCVTNRdlBTd2ZoNAo9UlU3YwotLS0tLUVO
RCBQR1AgU0lHTkFUVVJFLS0tLS0K

--===============2165587755094539353==--

From marco.guazzone at gmail.com Sat Jun  6 11:10:08 2015
Content-Type: multipart/mixed; boundary="===============5230336136931822224=="
MIME-Version: 1.0
From: Marco Guazzone <marco.guazzone at gmail.com>
To: xen at lists.fedoraproject.org
Subject: Re: [Fedora-xen] [f20] Problem with libvirt + Xen XL toolstack
Date: Thu, 13 Nov 2014 09:49:19 +0100
Message-ID: <CABbE_O6eSs9mFh6X7-XfcWbV+WXhJsSO6gjtGL8pxSqjLyQkqg@mail.gmail.com>
In-Reply-To: 5463F696.9050600@suse.com

--===============5230336136931822224==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 13, 2014 at 1:08 AM, Jim Fehlig <jfehlig(a)suse.com> wrote:
>
> Can you provide
>

Sure!

> 1. the config you use with xl

name =3D "testvm"
uuid =3D "93f08541-bfd5-4ac4-851d-c619a4516a13"
kernel =3D "/usr/lib/xen/boot/hvmloader"
builder =3D "hvm"
maxmem =3D 3072
memory =3D 2048
vcpus =3D 1
on_crash =3D "restart"
disk =3D [ "file:/root/images/test.img,hda,w",
"file:/root/iso/CentOS-7.0-1406-x86_64-Minimal.iso,hdc:cdrom,r" ]
vif =3D [ "bridge=3Dxenbr0,script=3Dvif-bridge" ]
boot =3D "cd"
sdl =3D 0
vnc =3D 1
vncunused =3D 1
xen_platform_pci =3D 1


> 2. the XML config you use with libvirt

<domain type=3D'xen'>
  <name>testvm</name>
  <uuid>93f08541-bfd5-4ac4-851d-c619a4516a13</uuid>
  <memory unit=3D'KiB'>3145728</memory>
  <currentMemory unit=3D'KiB'>2097152</currentMemory>
  <vcpu placement=3D'static'>1</vcpu>
  <os>
    <type arch=3D'x86_64' machine=3D'xenfv'>hvm</type>
    <loader>/usr/lib/xen/boot/hvmloader</loader>
    <boot dev=3D'hd'/>
<!--
    <boot dev=3D'hd'/>
-->
  </os>
  <clock offset=3D'variable' adjustment=3D'0' basis=3D'utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <disk type=3D'file' device=3D'disk'>
<!--
      <driver name=3D'file'/>
-->
      <driver name=3D'qemu'/>
      <source file=3D'/root/images/test.img'/>
      <target dev=3D'hda' bus=3D'ide'/>
    </disk>
    <disk type=3D'file' device=3D'cdrom'>
<!--
      <driver name=3D'file'/>
-->
      <driver name=3D'qemu'/>
      <source file=3D'/root/iso/CentOS-7.0-1406-x86_64-Minimal.iso'/>
      <target dev=3D'hdc' bus=3D'ide'/>
      <readonly/>
    </disk>
    <interface type=3D'bridge'>
      <mac address=3D'00:00:00:00:00:00'/>
      <source bridge=3D'xenbr0'/>
      <script path=3D'vif-bridge'/>
    </interface>
    <input type=3D'mouse' bus=3D'ps2'/>
    <graphics type=3D'vnc' port=3D'-1' autoport=3D'yes'/>
  </devices>
</domain>


> 3. the qemu command line libxl generated for each case?

QEMU command for "xl create testvm.cfg":

 /usr/lib/xen/bin/qemu-dm -d 11 -domain-name testvm -vnc 127.0.0.1:0
-vncunused -videoram 8 -boot cd -acpi -vcpu_avail 0x01 -net
nic,vlan=3D0,macaddr=3D00:16:3e:5c:c2:5a,model=3Drtl8139 -net
tap,vlan=3D0,ifname=3Dvif11.0-emu,bridge=3Dxenbr0,script=3Dno,downscript=3D=
no -M
xenfv

QEMU command for "virsh create testvm.xml":

/usr/lib/xen/bin/qemu-dm -d 12 -domain-name testvm -vnc 127.0.0.1:1
-videoram 8 -boot c -vcpu_avail 0x01 -net none -M xenfv


Thanks so much.

Best,

-- Marco

--===============5230336136931822224==--

From crobinso at redhat.com Sat Jun  6 11:10:08 2015
Content-Type: multipart/mixed; boundary="===============5131469003190249109=="
MIME-Version: 1.0
From: Cole Robinson <crobinso at redhat.com>
To: xen at lists.fedoraproject.org
Subject: Re: [Fedora-xen] Enable Xen in f20 qemu? [Was: Xen 4.4 RC2 [TestDay]]
Date: Sun, 16 Nov 2014 11:52:49 -0500
Message-ID: <5468D661.2060705@redhat.com>
In-Reply-To: 546396AB.3010109@bfccomputing.com

--===============5131469003190249109==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

On 11/12/2014 12:19 PM, Bill McGonigle wrote:
> On 01/21/14 03:15, Dario Faggioli wrote:
>> While investigating, we also spotted this:
>> http://pkgs.fedoraproject.org/cgit/qemu.git/tree/qemu.spec?h=3Df20
>>
>> Which contains the following:
>>
>> dobuild() {
>>      ./configure \
>>          --prefix=3D%{_prefix} \
>>          --libdir=3D%{_libdir} \
>>          --sysconfdir=3D%{_sysconfdir} \
>>          --interp-prefix=3D%{_prefix}/qemu-%%M \
>>          --audio-drv-list=3Dpa,sdl,alsa,oss \
>>          --localstatedir=3D%{_localstatedir} \
>>          --libexecdir=3D%{_libexecdir} \
>>          --disable-strip \
>>          --extra-ldflags=3D"$extraldflags -pie -Wl,-z,relro -Wl,-z,now" \
>>          --extra-cflags=3D"%{optflags} -fPIE -DPIE" \
>>          --enable-mixemu \
>>          --enable-trace-backend=3Ddtrace \
>>          --disable-werror \
>>          --disable-xen \
>>          --enable-kvm \
>> ...
>>
>> which seems to suggest that xen support is disabled in Fedora's qemu
>> package. Should we ask why they do that, and investigate whether that
>> can change (and, of course, whether that is enough for us) ?
>
> This still seems to be true - I guess I've been building my own for a
> long time or using virt-preview and just now had the opportunity to
> notice that the stock f20 qemu still fails with virt-install.
>
> # virt-install --name=3Dtestvm --ram=3D2048 --vcpus=3D2 --cpuset=3D2-11
> --location=3Dhttp://librescu/cobbler/ks_mirror/centos6-x86_64
> --os-type=3Dlinux --os-variant=3Drhel6 --disk
> path=3D/dev/zvol/storage/testvm/boot --disk
> path=3D/dev/zvol/storage/testvm/root --network
> bridge=3Dbr0,mac=3D02:00:0a:0a:0a:19 --graphics=3Dvnc --paravirt --arch=
=3Dx86_64
> --virt-type=3Dxen
>
> yields:
>
> # tail -100 /var/log/libvirt/libxl/testvm.log  | grep
> libxl__spawn_local_dm | grep -v Spawning | cut -f 6 -d ' '| xargs echo
> /usr/bin/qemu-system-i386 -xen-domid 13 -chardev
> socket,id=3Dlibxl-cmd,path=3D/var/run/xen/qmp-libxl-13,server,nowait -mon
> chardev=3Dlibxl-cmd,mode=3Dcontrol -nodefaults -xen-attach -name testvm -=
vnc
> 127.0.0.1:0 -k en-us -machine xenpv -m 2049
>
> which gives:
>
>    Option xen-domid not supported for this target
>
> etc.  I see the f21 version (I built the matching version from
> virt-preview on f20) works fine and I've been using the above pattern
> for a couple years on f[1?-20].  Is it time to just enable xen for f20
> since it works and f20 will be supported for a while yet?  It was a
> little tricky (aka time-consuming) for me to track this down and I have
> a slight clue how the parts work - failing for historical reasons seems
> to be incorrect and will unnecessarily confuse a large part of the user
> base.
>

Should be fine, please file an f20 bug against qemu and I'll turn on xen in =

the next build

- Cole


--===============5131469003190249109==--

From marco.guazzone at gmail.com Sat Jun  6 11:10:08 2015
Content-Type: multipart/mixed; boundary="===============8361786253768447827=="
MIME-Version: 1.0
From: Marco Guazzone <marco.guazzone at gmail.com>
To: xen at lists.fedoraproject.org
Subject: Re: [Fedora-xen] [f20] Problem with libvirt + Xen XL toolstack
Date: Mon, 17 Nov 2014 10:20:30 +0100
Message-ID: <CABbE_O7noozMkM92ctRyZ8O6rfWS2qNscdUn_jx6oNjaHvy-Mg@mail.gmail.com>
In-Reply-To: CABbE_O6eSs9mFh6X7-XfcWbV+WXhJsSO6gjtGL8pxSqjLyQkqg@mail.gmail.com

--===============8361786253768447827==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 13, 2014 at 9:49 AM, Marco Guazzone
<marco.guazzone(a)gmail.com> wrote:
> On Thu, Nov 13, 2014 at 1:08 AM, Jim Fehlig <jfehlig(a)suse.com> wrote:
>>
>> Can you provide
>>
>
> Sure!
>
>> 1. the config you use with xl
>
> name =3D "testvm"
> uuid =3D "93f08541-bfd5-4ac4-851d-c619a4516a13"
> kernel =3D "/usr/lib/xen/boot/hvmloader"
> builder =3D "hvm"
> maxmem =3D 3072
> memory =3D 2048
> vcpus =3D 1
> on_crash =3D "restart"
> disk =3D [ "file:/root/images/test.img,hda,w",
> "file:/root/iso/CentOS-7.0-1406-x86_64-Minimal.iso,hdc:cdrom,r" ]
> vif =3D [ "bridge=3Dxenbr0,script=3Dvif-bridge" ]
> boot =3D "cd"
> sdl =3D 0
> vnc =3D 1
> vncunused =3D 1
> xen_platform_pci =3D 1
>
>
>> 2. the XML config you use with libvirt
>
> <domain type=3D'xen'>
>   <name>testvm</name>
>   <uuid>93f08541-bfd5-4ac4-851d-c619a4516a13</uuid>
>   <memory unit=3D'KiB'>3145728</memory>
>   <currentMemory unit=3D'KiB'>2097152</currentMemory>
>   <vcpu placement=3D'static'>1</vcpu>
>   <os>
>     <type arch=3D'x86_64' machine=3D'xenfv'>hvm</type>
>     <loader>/usr/lib/xen/boot/hvmloader</loader>
>     <boot dev=3D'hd'/>
> <!--
>     <boot dev=3D'hd'/>
> -->
>   </os>
>   <clock offset=3D'variable' adjustment=3D'0' basis=3D'utc'/>
>   <on_poweroff>destroy</on_poweroff>
>   <on_reboot>restart</on_reboot>
>   <on_crash>restart</on_crash>
>   <devices>
>     <disk type=3D'file' device=3D'disk'>
> <!--
>       <driver name=3D'file'/>
> -->
>       <driver name=3D'qemu'/>
>       <source file=3D'/root/images/test.img'/>
>       <target dev=3D'hda' bus=3D'ide'/>
>     </disk>
>     <disk type=3D'file' device=3D'cdrom'>
> <!--
>       <driver name=3D'file'/>
> -->
>       <driver name=3D'qemu'/>
>       <source file=3D'/root/iso/CentOS-7.0-1406-x86_64-Minimal.iso'/>
>       <target dev=3D'hdc' bus=3D'ide'/>
>       <readonly/>
>     </disk>
>     <interface type=3D'bridge'>
>       <mac address=3D'00:00:00:00:00:00'/>
>       <source bridge=3D'xenbr0'/>
>       <script path=3D'vif-bridge'/>
>     </interface>
>     <input type=3D'mouse' bus=3D'ps2'/>
>     <graphics type=3D'vnc' port=3D'-1' autoport=3D'yes'/>
>   </devices>
> </domain>
>
>
>> 3. the qemu command line libxl generated for each case?
>
> QEMU command for "xl create testvm.cfg":
>
>  /usr/lib/xen/bin/qemu-dm -d 11 -domain-name testvm -vnc 127.0.0.1:0
> -vncunused -videoram 8 -boot cd -acpi -vcpu_avail 0x01 -net
> nic,vlan=3D0,macaddr=3D00:16:3e:5c:c2:5a,model=3Drtl8139 -net
> tap,vlan=3D0,ifname=3Dvif11.0-emu,bridge=3Dxenbr0,script=3Dno,downscript=
=3Dno -M
> xenfv
>
> QEMU command for "virsh create testvm.xml":
>
> /usr/lib/xen/bin/qemu-dm -d 12 -domain-name testvm -vnc 127.0.0.1:1
> -videoram 8 -boot c -vcpu_avail 0x01 -net none -M xenfv
>
>
> Thanks so much.
>
> Best,
>

Hi,

Any news?

In the meanwhile, from the qemu command above, I've noted that it
tries to boot from HD.
In fact, the conversion from Xen config file to XML missed to add a
<boot> element for cdrom (instead, it wrongly added a duplicate
element for HD).
So, I've tried to add this <boot> element, thus resulting in:

  <os>
    <type arch=3D'x86_64' machine=3D'xenfv'>hvm</type>
    <loader>/usr/lib/xen/boot/hvmloader</loader>
    <boot dev=3D'hd'/>
<!--
    <boot dev=3D'hd'/>
-->
    <boot dev=3D'cdrom'/>
 </os>

Now, the QEMU command spawn by virsh is

/usr/lib/xen/bin/qemu-dm -d 3 -domain-name testvm -vnc 127.0.0.1:0
-videoram 8 -boot cd -vcpu_avail 0x01 -net none -M xenfv

Now, vncviewer is able to connect, I can see the CentOS initial menu,
but when I choose to start the installation the vnc window becomes
black and I can do nothing.
I've tried to start the installation in several ways, including the
basic graphics mode (VESA) or by adding the "text" parameter to the
kernel boot options.
But the result is the same.

This is the logs content

/var/log/xen/qemu-dm-testvm.log

domid: 3
-videoram option does not work with cirrus vga device model. Videoram set t=
o 4M.
Strip off blktap sub-type prefix to /root/images/test.img (drv 'aio')
Using file /root/images/test.img in read-write mode
Strip off blktap sub-type prefix to
/root/iso/CentOS-7.0-1406-x86_64-Minimal.iso (drv 'aio')
Using file /root/iso/CentOS-7.0-1406-x86_64-Minimal.iso in read-only mode
Watching /local/domain/0/device-model/3/logdirty/cmd
Watching /local/domain/0/device-model/3/command
Watching /local/domain/3/cpu
qemu_map_cache_init nr_buckets =3D 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid =3D 93f08541-bfd5-4ac4-851d-c619a4516a13
populating video RAM at ff000000
mapping video RAM from ff000000
Register xen platform.
Done register platform.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw st=
ate.
xs_read(/local/domain/0/device-model/3/xen_extended_power_mgmt): read error
xs_read(): vncpasswd get error.
/vm/93f08541-bfd5-4ac4-851d-c619a4516a13/vncpasswd.
medium change watch on `hdc' (index: 1):
aio:/root/iso/CentOS-7.0-1406-x86_64-Minimal.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
vcpu-set: watch node error.
[xenstore_process_vcpu_set_event]: /local/domain/3/cpu has no CPU!
xs_read(/local/domain/3/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/3/log-throttling'
medium change watch on `/local/domain/3/log-throttling' - unknown
device, ignored
cirrus vga map change while on lfb mode
mapping vram to f0000000 - f0400000
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw st=
ate.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro st=
ate.


/var/log/libvirt/libxl/testvm.log:

libxl: verbose:
libxl_create.c:130:libxl__domain_build_info_setdefault: qemu-xen is
unavailable, use qemu-xen-traditional instead: No such file or
directory
libxl: debug: libxl_create.c:1243:do_domain_create: ao 0x7f6504176c40:
create: how=3D(nil) callback=3D(nil) poller=3D0x7f65041796f0
libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
vdev=3Dhda spec.backend=3Dqdisk
libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
vdev=3Dhdc spec.backend=3Dqdisk
libxl: debug: libxl_create.c:699:initiate_domain_create: running bootloader
libxl: debug: libxl_bootloader.c:321:libxl__bootloader_run: not a PV
domain, skipping bootloader
libxl: debug: libxl_event.c:608:libxl__ev_xswatch_deregister: watch
w=3D0x7f6504184728: deregister unregistered
libxl: debug: libxl_numa.c:478:libxl__get_numa_candidate: New best
NUMA placement candidate found: nr_nodes=3D2, nr_cpus=3D16, nr_vcpus=3D34,
free_memkb=3D3461
libxl: detail: libxl_dom.c:195:numa_place_domain: NUMA placement
candidate with 2 nodes, 16 cpus and 3461 KB free selected
xc: detail: elf_parse_binary: phdr: paddr=3D0x100000 memsz=3D0xa2304
xc: detail: elf_parse_binary: memory: 0x100000 -> 0x1a2304
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001a2304
  Modules:       0000000000000000->0000000000000000
  TOTAL:         0000000000000000->00000000bf800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000001
xc: detail: elf_load_binary: phdr 0 at 0x7f6526334000 -> 0x7f65263cd18d
libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
vdev=3Dhda spec.backend=3Dqdisk
libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
vdev=3Dhdc spec.backend=3Dqdisk
libxl: debug: libxl_dm.c:1211:libxl__spawn_local_dm: Spawning
device-model /usr/lib/xen/bin/qemu-dm with arguments:
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   /usr/lib/xen/bin/qem=
u-dm
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   -d
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   3
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   -domain-name
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   testvm
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   -vnc
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   127.0.0.1:0
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   -videoram
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   8
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   -boot
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   cd
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   -vcpu_avail
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   0x01
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   -net
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   none
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   -M
libxl: debug: libxl_dm.c:1213:libxl__spawn_local_dm:   xenfv
libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch
w=3D0x7f6504184960 wpath=3D/local/domain/0/device-model/3/state token=3D3/0:
register slotnum=3D3
libxl: debug: libxl_create.c:1256:do_domain_create: ao 0x7f6504176c40:
inprogress: poller=3D0x7f65041796f0, flags=3Di
libxl: debug: libxl_event.c:503:watchfd_callback: watch
w=3D0x7f6504184960 wpath=3D/local/domain/0/device-model/3/state token=3D3/0:
event epath=3D/local/domain/0/device-model/3/state
libxl: debug: libxl_event.c:503:watchfd_callback: watch
w=3D0x7f6504184960 wpath=3D/local/domain/0/device-model/3/state token=3D3/0:
event epath=3D/local/domain/0/device-model/3/state
libxl: debug: libxl_event.c:596:libxl__ev_xswatch_deregister: watch
w=3D0x7f6504184960 wpath=3D/local/domain/0/device-model/3/state token=3D3/0:
deregister slotnum=3D3
libxl: debug: libxl_event.c:608:libxl__ev_xswatch_deregister: watch
w=3D0x7f6504184960: deregister unregistered
libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch
w=3D0x7f650417e9e8 wpath=3D/local/domain/0/backend/vif/3/0/state
token=3D3/1: register slotnum=3D3
libxl: debug: libxl_event.c:503:watchfd_callback: watch
w=3D0x7f650417e9e8 wpath=3D/local/domain/0/backend/vif/3/0/state
token=3D3/1: event epath=3D/local/domain/0/backend/vif/3/0/state
libxl: debug: libxl_event.c:647:devstate_watch_callback: backend
/local/domain/0/backend/vif/3/0/state wanted state 2 still waiting
state 1
libxl: debug: libxl_event.c:503:watchfd_callback: watch
w=3D0x7f650417e9e8 wpath=3D/local/domain/0/backend/vif/3/0/state
token=3D3/1: event epath=3D/local/domain/0/backend/vif/3/0/state
libxl: debug: libxl_event.c:643:devstate_watch_callback: backend
/local/domain/0/backend/vif/3/0/state wanted state 2 ok
libxl: debug: libxl_event.c:596:libxl__ev_xswatch_deregister: watch
w=3D0x7f650417e9e8 wpath=3D/local/domain/0/backend/vif/3/0/state
token=3D3/1: deregister slotnum=3D3
libxl: debug: libxl_event.c:608:libxl__ev_xswatch_deregister: watch
w=3D0x7f650417e9e8: deregister unregistered
libxl: debug: libxl_device.c:959:device_hotplug: calling hotplug
script: /etc/xen/scripts/vif-bridge online
libxl: debug: libxl_event.c:1737:libxl__ao_progress_report: ao
0x7f6504176c40: progress report: ignored
libxl: debug: libxl_event.c:1569:libxl__ao_complete: ao
0x7f6504176c40: complete, rc=3D0
libxl: debug: libxl_event.c:1541:libxl__ao__destroy: ao 0x7f6504176c40: des=
troy
libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch
w=3D0x7f65040cdb90 wpath=3D@releaseDomain token=3D3/2: register slotnum=3D3
libxl: debug: libxl_event.c:503:watchfd_callback: watch
w=3D0x7f65040cdb90 wpath=3D@releaseDomain token=3D3/2: event
epath=3D@releaseDomain
libxl: debug: libxl.c:1004:domain_death_xswatch_callback:
[evg=3D0x7f6504000f50:3] from domid=3D3 nentries=3D1 rc=3D1
libxl: debug: libxl.c:1015:domain_death_xswatch_callback:
[evg=3D0x7f6504000f50:3]   got=3Ddomaininfos[0] got->domain=3D3
libxl: debug: libxl.c:1042:domain_death_xswatch_callback:  exists
shutdown_reported=3D0 dominf.flags=3Dffff0002
libxl: debug: libxl.c:1008:domain_death_xswatch_callback: [evg=3D0] all rep=
orted
libxl: debug: libxl.c:1072:domain_death_xswatch_callback: domain death
search done


Cheers,

-- Marco

--===============8361786253768447827==--

From marco.guazzone at gmail.com Sat Jun  6 11:10:08 2015
Content-Type: multipart/mixed; boundary="===============5746648364047799075=="
MIME-Version: 1.0
From: Marco Guazzone <marco.guazzone at gmail.com>
To: xen at lists.fedoraproject.org
Subject: Re: [Fedora-xen] [f20] Problem with libvirt + Xen XL toolstack
Date: Tue, 18 Nov 2014 17:13:09 +0100
Message-ID: <CABbE_O5wrDfM9BcrNi9eYuszXASwD7AVh=k+qB11qG477m2dJg@mail.gmail.com>
In-Reply-To: CABbE_O7noozMkM92ctRyZ8O6rfWS2qNscdUn_jx6oNjaHvy-Mg@mail.gmail.com

--===============5746648364047799075==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

On Mon, Nov 17, 2014 at 10:20 AM, Marco Guazzone
<marco.guazzone(a)gmail.com> wrote:
>

[big cut]

> Hi,
>
> Any news?
>
> In the meanwhile, from the qemu command above, I've noted that it
> tries to boot from HD.
> In fact, the conversion from Xen config file to XML missed to add a
> <boot> element for cdrom (instead, it wrongly added a duplicate
> element for HD).
> So, I've tried to add this <boot> element, thus resulting in:
>
>   <os>
>     <type arch=3D'x86_64' machine=3D'xenfv'>hvm</type>
>     <loader>/usr/lib/xen/boot/hvmloader</loader>
>     <boot dev=3D'hd'/>
> <!--
>     <boot dev=3D'hd'/>
> -->
>     <boot dev=3D'cdrom'/>
>  </os>
>
> Now, the QEMU command spawn by virsh is
>
> /usr/lib/xen/bin/qemu-dm -d 3 -domain-name testvm -vnc 127.0.0.1:0
> -videoram 8 -boot cd -vcpu_avail 0x01 -net none -M xenfv
>
> Now, vncviewer is able to connect, I can see the CentOS initial menu,
> but when I choose to start the installation the vnc window becomes
> black and I can do nothing.
> I've tried to start the installation in several ways, including the
> basic graphics mode (VESA) or by adding the "text" parameter to the
> kernel boot options.
> But the result is the same.
>

[big cut]

>

Hi,

Maybe, I've found a workaround. I had to change again the XML file in
order to add some 'features' element.
  <features>
    <acpi/>
    <apic/>
    <pae/>
    <hap/>
  </features>

This time, the installation of the guest system seems to work.
I still have some annoying problem with the CentOS graphical
installation since the installation GUI immediately disappears with
the following message:
  ** (anaconda:1049): WARNING **: keybinder_init: Unable to open display
  (anaconda:1049): Gdk-WARNING **: anaconda: Fatal IO Error 0
(Success) on X server :1.
  Pane is dead
and the installation program remains stuck.
I've also tried to start the installation in the basic graphics mode.
But the problem remains.

Again, I can solve this with a workaround: I start the installation in
text mode by adding "text" to the kernel boot options of the CentOS
installation.

Now the VM is up & running.

Best,

-- Marco

--===============5746648364047799075==--

From marco.guazzone at gmail.com Sat Jun  6 11:10:08 2015
Content-Type: multipart/mixed; boundary="===============5722315576492499161=="
MIME-Version: 1.0
From: Marco Guazzone <marco.guazzone at gmail.com>
To: xen at lists.fedoraproject.org
Subject: Re: [Fedora-xen] [f20] Problem with libvirt + Xen XL toolstack
Date: Tue, 25 Nov 2014 10:53:31 +0100
Message-ID: <CABbE_O60CJ=8g59G19bYFfayO6UTDM16iNbo+K3LGF4MsKyatw@mail.gmail.com>
In-Reply-To: 54736660.4040705@suse.com

--===============5722315576492499161==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

Hi Jim,

On Mon, Nov 24, 2014 at 6:09 PM, Jim Fehlig <jfehlig(a)suse.com> wrote:
> Hi Marco,
>
> Sorry for the delay.  I'm not ignoring your mails, just too busy with
> travel, recuperating from sickness, etc. to investigate and respond...
>

No problem. I'm always in hurry as well.
Thank you for the time you spend in this list


>
>
> The duplicate <boot> entries are the result of a bug in the
> DomainXMLFromNative function.  I just verified the bug still exists in
> libvirt git master.

ok

>
> Sigh.  More bugs in DomainXMLFromNative.  Can you verify if <hap/> is
> explicitly needed?  IIRC, Xen will automatically use hap if supported by =
the
> hardware.
>

You're right. As stated here:
   http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html
hap is True if supported.
Also, apic is True by default
So, I've commented the "hap" and "apic" elements. No problem encountered.

>> This time, the installation of the guest system seems to work.
>> I still have some annoying problem with the CentOS graphical
>> installation since the installation GUI immediately disappears with
>> the following message:
>>    ** (anaconda:1049): WARNING **: keybinder_init: Unable to open display
>>    (anaconda:1049): Gdk-WARNING **: anaconda: Fatal IO Error 0
>> (Success) on X server :1.
>>    Pane is dead
>> and the installation program remains stuck.
>> I've also tried to start the installation in the basic graphics mode.
>> But the problem remains.
>
>
> Do you also see this problem when starting the domain directly with xl?
>

Yes. The installation GUI appears, then I move the mouse and the GUI
disappears and I remains with the above error message.


> FYI, it may be some time before I have a chance to track down and fix the=
se
> bugs.  Are you able to help contribute in this area?
>

Not so much, sorry! I'm overloaded of work and I have some deadlines
for my research.
Anyway, I can perform some test if you need in the next few days, at
least until I start my experiments.
In fact, from that moment, I can use the experimental testbed only for
stuff related to research experiments.

Cheers,

-- Marco

--===============5722315576492499161==--