From marco.guazzone at gmail.com  Tue Nov 11 14:50:19 2014
From: marco.guazzone at gmail.com (Marco Guazzone)
Date: Tue, 11 Nov 2014 15:50:19 +0100
Subject: [Fedora-xen] [f20] Problem with libvirt + Xen XL toolstack
Message-ID: <CABbE_O442-dwMdRzT6FsYjr8rUViGAoQ9e+1_fWd90DPFnxU9w@mail.gmail.com>

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=disabled

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=br0
    TYPE=Bridge
    BOOTPROTO=none
    ONBOOT=yes
    IPADDR=10.10.15.2
    NETMASK=255.255.255.0
    STP=yes
    DELAY=0
    DEFROUTE=yes
    USERCTL=no
    NM_CONTROLLED=no

  $ vi /etc/sysconfig/network-scripts/ifcfg-em2
    NAME=em2
    TYPE=Ethernet
    BOOTPROTO=none
    ONBOOT=yes
    BRIDGE=br0
    PEERDNS=yes
    PEERROUTES=yes
    DEFROUTE=yes
    USERCTL=no
    NM_CONTROLLED=no

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 = "testvm"
    uuid = "93f08541-bfd5-4ac4-851d-c619a4516a13"
    builder = "hvm"
    maxmem = 3072
    memory = 2048
    vcpus = 1
    on_crash = "restart"
    disk = [ "file:/root/images/testvm.img,hda,w",
"file:/root/iso/CentOS-7.0-1406-    x86_64-Minimal.iso,hdc:cdrom,r" ]
    vif = [ "bridge=br0,script=vif-bridge" ]
    boot = "cd"
    sdl = 0
    vnc = 1
    vncunused = 1
    xen_platform_pci = 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='xen'>
     <name>testvm</name>
     <uuid>93f08541-bfd5-4ac4-851d-c619a4516a13</uuid>
     <memory unit='KiB'>3145728</memory>
     <currentMemory unit='KiB'>2097152</currentMemory>
     <vcpu placement='static'>1</vcpu>
     <os>
       <type arch='x86_64' machine='xenfv'>hvm</type>
       <loader>/usr/lib/xen/boot/hvmloader</loader>
       <boot dev='hd'/>
       <boot dev='hd'/>
     </os>
     <clock offset='variable' adjustment='0' basis='utc'/>
     <on_poweroff>destroy</on_poweroff>
     <on_reboot>restart</on_reboot>
     <on_crash>restart</on_crash>
     <devices>
       <disk type='file' device='disk'>
         <driver name='file'/>
         <source file='/root/images/testvm.img'/>
         <target dev='hda' bus='ide'/>
       </disk>
       <disk type='file' device='cdrom'>
         <driver name='file'/>
          <source file='/root/iso/CentOS-7.0-1406-x86_64-Minimal.iso'/>
        <target dev='hdc' bus='ide'/>
         <readonly/>
       </disk>
       <interface type='bridge'>
         <mac address='00:00:00:00:00:00'/>
         <source bridge='br0'/>
         <script path='vif-bridge'/>
       </interface>
       <input type='mouse' bus='ps2'/>
       <graphics type='vnc' port='-1' autoport='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 hypervisor
error: Failed to reconnect to the hypervisor



Thank you very much for your time.

Best,

-- Marco

From konrad.wilk at oracle.com  Tue Nov 11 15:53:18 2014
From: konrad.wilk at oracle.com (Konrad Rzeszutek Wilk)
Date: Tue, 11 Nov 2014 10:53:18 -0500
Subject: [Fedora-xen] [f20] Problem with libvirt + Xen XL toolstack
In-Reply-To: <CABbE_O442-dwMdRzT6FsYjr8rUViGAoQ9e+1_fWd90DPFnxU9w@mail.gmail.com>
References: <CABbE_O442-dwMdRzT6FsYjr8rUViGAoQ9e+1_fWd90DPFnxU9w@mail.gmail.com>
Message-ID: <20141111155318.GA13402@laptop.dumpdata.com>

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=disabled

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=no set in it.
> 
> 4- Create network bridge
>   $ vi /etc/sysconfig/network-
> scripts/ifcfg-br0
>     DEVICE=br0
>     TYPE=Bridge
>     BOOTPROTO=none
>     ONBOOT=yes
>     IPADDR=10.10.15.2
>     NETMASK=255.255.255.0
>     STP=yes
>     DELAY=0
>     DEFROUTE=yes
>     USERCTL=no
>     NM_CONTROLLED=no
> 
>   $ vi /etc/sysconfig/network-scripts/ifcfg-em2
>     NAME=em2
>     TYPE=Ethernet
>     BOOTPROTO=none
>     ONBOOT=yes
>     BRIDGE=br0
>     PEERDNS=yes
>     PEERROUTES=yes
>     DEFROUTE=yes
>     USERCTL=no
>     NM_CONTROLLED=no
> 
> 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 = "testvm"
>     uuid = "93f08541-bfd5-4ac4-851d-c619a4516a13"
>     builder = "hvm"
>     maxmem = 3072
>     memory = 2048
>     vcpus = 1
>     on_crash = "restart"
>     disk = [ "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 = [ "bridge=br0,script=vif-bridge" ]
>     boot = "cd"
>     sdl = 0
>     vnc = 1
>     vncunused = 1
>     xen_platform_pci = 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='xen'>
>      <name>testvm</name>
>      <uuid>93f08541-bfd5-4ac4-851d-c619a4516a13</uuid>
>      <memory unit='KiB'>3145728</memory>
>      <currentMemory unit='KiB'>2097152</currentMemory>
>      <vcpu placement='static'>1</vcpu>
>      <os>
>        <type arch='x86_64' machine='xenfv'>hvm</type>
>        <loader>/usr/lib/xen/boot/hvmloader</loader>
>        <boot dev='hd'/>
>        <boot dev='hd'/>
>      </os>
>      <clock offset='variable' adjustment='0' basis='utc'/>
>      <on_poweroff>destroy</on_poweroff>
>      <on_reboot>restart</on_reboot>
>      <on_crash>restart</on_crash>
>      <devices>
>        <disk type='file' device='disk'>
>          <driver name='file'/>
>          <source file='/root/images/testvm.img'/>
>          <target dev='hda' bus='ide'/>
>        </disk>
>        <disk type='file' device='cdrom'>
>          <driver name='file'/>
>           <source file='/root/iso/CentOS-7.0-1406-x86_64-Minimal.iso'/>
>         <target dev='hdc' bus='ide'/>
>          <readonly/>
>        </disk>
>        <interface type='bridge'>
>          <mac address='00:00:00:00:00:00'/>

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

>          <source bridge='br0'/>
>          <script path='vif-bridge'/>
>        </interface>
>        <input type='mouse' bus='ps2'/>
>        <graphics type='vnc' port='-1' autoport='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 hypervisor
> 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'.

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 at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/xen

From marco.guazzone at gmail.com  Tue Nov 11 16:21:30 2014
From: marco.guazzone at gmail.com (Marco Guazzone)
Date: Tue, 11 Nov 2014 17:21:30 +0100
Subject: [Fedora-xen] [f20] Problem with libvirt + Xen XL toolstack
In-Reply-To: <20141111155318.GA13402@laptop.dumpdata.com>
References: <CABbE_O442-dwMdRzT6FsYjr8rUViGAoQ9e+1_fWd90DPFnxU9w@mail.gmail.com>
	<20141111155318.GA13402@laptop.dumpdata.com>
Message-ID: <CABbE_O7zPpS-Cfsyp45yumQfkeJng-bgtPt57vkvvrTGF_KPHA@mail.gmail.com>

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

Hi Konrad,

>> 1. Disable SElinux
>>   $ vi /etc/selinux/config
>>     SELINUXTYPE=disabled
>
> 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=no 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 alone.


>>        <interface type='bridge'>
>>          <mac address='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 hypervisor
>> 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=4163<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 hypervisor
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

From konrad.wilk at oracle.com  Tue Nov 11 16:43:55 2014
From: konrad.wilk at oracle.com (Konrad Rzeszutek Wilk)
Date: Tue, 11 Nov 2014 11:43:55 -0500
Subject: [Fedora-xen] [f20] Problem with libvirt + Xen XL toolstack
In-Reply-To: <CABbE_O7zPpS-Cfsyp45yumQfkeJng-bgtPt57vkvvrTGF_KPHA@mail.gmail.com>
References: <CABbE_O442-dwMdRzT6FsYjr8rUViGAoQ9e+1_fWd90DPFnxU9w@mail.gmail.com>
	<20141111155318.GA13402@laptop.dumpdata.com>
	<CABbE_O7zPpS-Cfsyp45yumQfkeJng-bgtPt57vkvvrTGF_KPHA@mail.gmail.com>
Message-ID: <20141111164355.GA15019@laptop.dumpdata.com>

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 at oracle.com> wrote:
> 
> Hi Konrad,
> 
> >> 1. Disable SElinux
> >>   $ vi /etc/selinux/config
> >>     SELINUXTYPE=disabled
> >
> > 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=no 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 alone.
> 
> 
> >>        <interface type='bridge'>
> >>          <mac address='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 hypervisor
> >> 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=4163<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 hypervisor
> 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

Edit /etc/libvirt/libvirtd.conf

and change 'log_level' to be 'log_level=4'

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

> 
> Thank you very much!
> 
> -- Marco
> --
> xen mailing list
> xen at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/xen

From marco.guazzone at gmail.com  Tue Nov 11 21:01:09 2014
From: marco.guazzone at gmail.com (Marco Guazzone)
Date: Tue, 11 Nov 2014 22:01:09 +0100
Subject: [Fedora-xen] [f20] Problem with libvirt + Xen XL toolstack
In-Reply-To: <20141111164355.GA15019@laptop.dumpdata.com>
References: <CABbE_O442-dwMdRzT6FsYjr8rUViGAoQ9e+1_fWd90DPFnxU9w@mail.gmail.com>
	<20141111155318.GA13402@laptop.dumpdata.com>
	<CABbE_O7zPpS-Cfsyp45yumQfkeJng-bgtPt57vkvvrTGF_KPHA@mail.gmail.com>
	<20141111164355.GA15019@laptop.dumpdata.com>
Message-ID: <CABbE_O6e3mgOC4ufwogaMwn3=BymMY0bKFGNd7V7Fc5ZZoxfbQ@mail.gmail.com>

On Tue, Nov 11, 2014 at 5:43 PM, Konrad Rzeszutek Wilk
<konrad.wilk at oracle.com> wrote:
>>
>> Renamed the bridge to 'xenbr0':
>>
>> xenbr0: flags=4163<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='bridge'>
      <mac address='00:00:00:00:00:00'/>
      <source bridge='xenbr0'/>
      <script path='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=4'
>
> and make sure that 'log_output' has '"1:syslog:libvirtd"

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

log_level = 4
log_outputs="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=(nil) callback=(nil) poller=0x7f713c009ee0
libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
vdev=hda spec.backend=tap
libxl: debug: libxl_device.c:212:disk_try_backend: Disk vdev=hda,
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=-3
libxl: debug: libxl_create.c:1256:do_domain_create: ao 0x7f713c002a80:
inprogress: poller=0x7f713c009ee0, flags=ic
libxl: debug: libxl_event.c:1541:libxl__ao__destroy: ao 0x7f713c002a80: destroy


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

From konrad.wilk at oracle.com  Tue Nov 11 22:11:13 2014
From: konrad.wilk at oracle.com (Konrad Rzeszutek Wilk)
Date: Tue, 11 Nov 2014 17:11:13 -0500
Subject: [Fedora-xen] [f20] Problem with libvirt + Xen XL toolstack
In-Reply-To: <CABbE_O6e3mgOC4ufwogaMwn3=BymMY0bKFGNd7V7Fc5ZZoxfbQ@mail.gmail.com>
References: <CABbE_O442-dwMdRzT6FsYjr8rUViGAoQ9e+1_fWd90DPFnxU9w@mail.gmail.com>
	<20141111155318.GA13402@laptop.dumpdata.com>
	<CABbE_O7zPpS-Cfsyp45yumQfkeJng-bgtPt57vkvvrTGF_KPHA@mail.gmail.com>
	<20141111164355.GA15019@laptop.dumpdata.com>
	<CABbE_O6e3mgOC4ufwogaMwn3=BymMY0bKFGNd7V7Fc5ZZoxfbQ@mail.gmail.com>
Message-ID: <20141111221113.GB30289@laptop.dumpdata.com>

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 at oracle.com> wrote:
> >>
> >> Renamed the bridge to 'xenbr0':
> >>
> >> xenbr0: flags=4163<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='bridge'>
>       <mac address='00:00:00:00:00:00'/>
>       <source bridge='xenbr0'/>
>       <script path='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=4'
> >
> > and make sure that 'log_output' has '"1:syslog:libvirtd"
> 
> OK. Changed /etc/libvirt/libvirtd.conf:
> 
> log_level = 4
> log_outputs="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=(nil) callback=(nil) poller=0x7f713c009ee0
> libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
> vdev=hda spec.backend=tap

Somehow it picked 'tap'.

> libxl: debug: libxl_device.c:212:disk_try_backend: Disk vdev=hda,
> 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='file' device='disk'>
         <driver name='file'/>
         <source file='/root/images/testvm.img'/>
         <target dev='hda' bus='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=-3
> libxl: debug: libxl_create.c:1256:do_domain_create: ao 0x7f713c002a80:
> inprogress: poller=0x7f713c009ee0, flags=ic
> libxl: debug: libxl_event.c:1541:libxl__ao__destroy: ao 0x7f713c002a80: destroy
> 
> 
> 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
> --
> xen mailing list
> xen at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/xen

From marco.guazzone at gmail.com  Wed Nov 12 09:46:36 2014
From: marco.guazzone at gmail.com (Marco Guazzone)
Date: Wed, 12 Nov 2014 10:46:36 +0100
Subject: [Fedora-xen] [f20] Problem with libvirt + Xen XL toolstack
In-Reply-To: <5462F6A5.1080607@suse.com>
References: <CABbE_O442-dwMdRzT6FsYjr8rUViGAoQ9e+1_fWd90DPFnxU9w@mail.gmail.com>
	<20141111155318.GA13402@laptop.dumpdata.com>
	<CABbE_O7zPpS-Cfsyp45yumQfkeJng-bgtPt57vkvvrTGF_KPHA@mail.gmail.com>
	<20141111164355.GA15019@laptop.dumpdata.com>
	<CABbE_O6e3mgOC4ufwogaMwn3=BymMY0bKFGNd7V7Fc5ZZoxfbQ@mail.gmail.com>
	<20141111221113.GB30289@laptop.dumpdata.com>
	<5462F6A5.1080607@suse.com>
Message-ID: <CABbE_O6inuDP4J1mJsTOYi_xG7F_GDL+KBW_8GQwzGvwLa3VLw@mail.gmail.com>

On Wed, Nov 12, 2014 at 6:56 AM, Jim Fehlig <jfehlig at 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 at oracle.com> wrote:
>>>
>>>>> Renamed the bridge to 'xenbr0':
>>>>>
>>>>> xenbr0: flags=4163<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='bridge'>
>>>       <mac address='00:00:00:00:00:00'/>
>>>       <source bridge='xenbr0'/>
>>>       <script path='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=4'
>>>>
>>>> and make sure that 'log_output' has '"1:syslog:libvirtd"
>>>>
>>> OK. Changed /etc/libvirt/libvirtd.conf:
>>>
>>> log_level = 4
>>>
>
> FYI, log level 4 is the default, so this doesn't change anything.  You
> probably want debug log level (log_level = 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=libvirt.git;a=commit;h=48d81cef3b2dff6fe02bd7c8f0bf4f5aff917d8c
>
> 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=hda,
>>> 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='file' device='disk'>
>>          <driver name='file'/>
>>
>
> If you don't have the above patch, use <driver name='qemu'/> to
> explicitly request qdisk.


I've change the XML and replaced
  <driver name='file'/>
with the above element for both the 'disk' and the 'cdrom' devices:
  <devices>
    <disk type='file' device='disk'>
<!--
      <driver name='file'/>
-->
      <driver name='qemu'/>
      <source file='/root/images/testvm.img'/>
      <target dev='hda' bus='ide'/>
    </disk>
    <disk type='file' device='cdrom'>
<!--
      <driver name='file'/>
-->
      <driver name='qemu'/>
      <source file='/root/iso/CentOS-7.0-1406-x86_64-Minimal.iso'/>
      <target dev='hdc' bus='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=(nil) callback=(nil) poller=0x7fb67c002370
libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
vdev=hda spec.backend=qdisk
libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
vdev=hdc spec.backend=qdisk
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=0x7fb67c002b28: deregister unregistered
libxl: debug: libxl_numa.c:478:libxl__get_numa_candidate: New best
NUMA placement candidate found: nr_nodes=1, nr_cpus=8, nr_vcpus=17,
free_memkb=2699
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=0x100000 memsz=0xa2304
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=hda spec.backend=qdisk
libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
vdev=hdc spec.backend=qdisk
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/qemu-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=0x7fb67c002d60 wpath=/local/domain/0/device-model/2/state token=3/0:
register slotnum=3
libxl: debug: libxl_create.c:1256:do_domain_create: ao 0x7fb67c0027a0:
inprogress: poller=0x7fb67c002370, flags=i
libxl: debug: libxl_event.c:503:watchfd_callback: watch
w=0x7fb67c002d60 wpath=/local/domain/0/device-model/2/state token=3/0:
event epath=/local/domain/0/device-model/2/state
libxl: debug: libxl_event.c:596:libxl__ev_xswatch_deregister: watch
w=0x7fb67c002d60 wpath=/local/domain/0/device-model/2/state token=3/0:
deregister slotnum=3
libxl: error: libxl_dm.c:1280:device_model_spawn_outcome: domain 2
device model: spawn failed (rc=-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=-3
libxl: debug: libxl_event.c:1541:libxl__ao__destroy: ao 0x7fb67c0027a0: destroy


Cheers,

-- Marco

From marco.guazzone at gmail.com  Wed Nov 12 16:03:49 2014
From: marco.guazzone at gmail.com (Marco Guazzone)
Date: Wed, 12 Nov 2014 17:03:49 +0100
Subject: [Fedora-xen] [f20] Problem with libvirt + Xen XL toolstack
In-Reply-To: <54637CA8.6040800@suse.com>
References: <CABbE_O442-dwMdRzT6FsYjr8rUViGAoQ9e+1_fWd90DPFnxU9w@mail.gmail.com>
	<20141111155318.GA13402@laptop.dumpdata.com>
	<CABbE_O7zPpS-Cfsyp45yumQfkeJng-bgtPt57vkvvrTGF_KPHA@mail.gmail.com>
	<20141111164355.GA15019@laptop.dumpdata.com>
	<CABbE_O6e3mgOC4ufwogaMwn3=BymMY0bKFGNd7V7Fc5ZZoxfbQ@mail.gmail.com>
	<20141111221113.GB30289@laptop.dumpdata.com>
	<5462F6A5.1080607@suse.com>
	<CABbE_O6inuDP4J1mJsTOYi_xG7F_GDL+KBW_8GQwzGvwLa3VLw@mail.gmail.com>
	<54637CA8.6040800@suse.com>
Message-ID: <CABbE_O6CqnKGKdLtfuwMy=2=OriNUmMfvAh6KrZSS7D-vV84VA@mail.gmail.com>

On Wed, Nov 12, 2014 at 4:28 PM, Jim Fehlig <jfehlig at 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='x86_64' machine='xenfv'>hvm</type>
    <loader>/usr/lib/xen/boot/hvmloader</loader>
    <boot dev='hd'/>
<!--
    <boot dev='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=(nil) callback=(nil) poller=0x7fb6780011b0
libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
vdev=hda spec.backend=qdisk
libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
vdev=hdc spec.backend=qdisk
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=0x7fb678002c88: deregister unregistered
libxl: debug: libxl_numa.c:478:libxl__get_numa_candidate: New best
NUMA placement candidate found: nr_nodes=1, nr_cpus=8, nr_vcpus=17,
free_memkb=2698
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=0x100000 memsz=0xa2304
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=hda spec.backend=qdisk
libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
vdev=hdc spec.backend=qdisk
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/qemu-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=0x7fb678002ec0 wpath=/local/domain/0/device-model/9/state token=3/0:
register slotnum=3
libxl: debug: libxl_create.c:1256:do_domain_create: ao 0x7fb678002900:
inprogress: poller=0x7fb6780011b0, flags=i
libxl: debug: libxl_event.c:503:watchfd_callback: watch
w=0x7fb678002ec0 wpath=/local/domain/0/device-model/9/state token=3/0:
event epath=/local/domain/0/device-model/9/state
libxl: debug: libxl_event.c:503:watchfd_callback: watch
w=0x7fb678002ec0 wpath=/local/domain/0/device-model/9/state token=3/0:
event epath=/local/domain/0/device-model/9/state
libxl: debug: libxl_event.c:596:libxl__ev_xswatch_deregister: watch
w=0x7fb678002ec0 wpath=/local/domain/0/device-model/9/state token=3/0:
deregister slotnum=3
libxl: debug: libxl_event.c:608:libxl__ev_xswatch_deregister: watch
w=0x7fb678002ec0: deregister unregistered
libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch
w=0x7fb678006b18 wpath=/local/domain/0/backend/vif/9/0/state
token=3/1: register slotnum=3
libxl: debug: libxl_event.c:503:watchfd_callback: watch
w=0x7fb678006b18 wpath=/local/domain/0/backend/vif/9/0/state
token=3/1: event epath=/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=0x7fb678006b18 wpath=/local/domain/0/backend/vif/9/0/state
token=3/1: deregister slotnum=3
libxl: debug: libxl_event.c:608:libxl__ev_xswatch_deregister: watch
w=0x7fb678006b18: 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=0
libxl: debug: libxl_event.c:1541:libxl__ao__destroy: ao 0x7fb678002900: destroy
libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch
w=0x7fb678001cf0 wpath=@releaseDomain token=3/2: register slotnum=3
libxl: debug: libxl_event.c:503:watchfd_callback: watch
w=0x7fb678001cf0 wpath=@releaseDomain token=3/2: event
epath=@releaseDomain
libxl: debug: libxl.c:1004:domain_death_xswatch_callback:
[evg=0x7fb678001810:9] from domid=9 nentries=1 rc=1
libxl: debug: libxl.c:1015:domain_death_xswatch_callback:
[evg=0x7fb678001810:9]   got=domaininfos[0] got->domain=9
libxl: debug: libxl.c:1042:domain_death_xswatch_callback:  exists
shutdown_reported=0 dominf.flags=ffff0022
libxl: debug: libxl.c:1008:domain_death_xswatch_callback: [evg=0] all reported
libxl: debug: libxl.c:1072:domain_death_xswatch_callback: domain death
search done
libxl: debug: libxl_event.c:503:watchfd_callback: watch
w=0x7fb678001cf0 wpath=@releaseDomain token=3/2: event
epath=@releaseDomain
libxl: debug: libxl.c:1004:domain_death_xswatch_callback:
[evg=0x7fb678001810:9] from domid=9 nentries=1 rc=1
libxl: debug: libxl.c:1015:domain_death_xswatch_callback:
[evg=0x7fb678001810:9]   got=domaininfos[0] got->domain=9
libxl: debug: libxl.c:1042:domain_death_xswatch_callback:  exists
shutdown_reported=0 dominf.flags=6
libxl: debug: libxl.c:1054:domain_death_xswatch_callback:  shutdown reporting
libxl: debug: libxl.c:1008:domain_death_xswatch_callback: [evg=0] all reported
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=domain_shutdown
libxl: debug: libxl.c:1256:libxl_domain_destroy: ao 0x7fb6a99f1b60:
create: how=(nil) callback=(nil) poller=0x7fb6780011b0
libxl: debug: libxl_dm.c:1314:libxl__destroy_device_model: Device Model signaled
libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch
w=0x7fb6a99f08a8 wpath=/local/domain/0/backend/vif/9/0/state
token=2/3: register slotnum=2
libxl: debug: libxl.c:1265:libxl_domain_destroy: ao 0x7fb6a99f1b60:
inprogress: poller=0x7fb6780011b0, flags=i
libxl: debug: libxl_event.c:503:watchfd_callback: watch
w=0x7fb6a99f08a8 wpath=/local/domain/0/backend/vif/9/0/state
token=2/3: event epath=/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=0x7fb6a99f08a8 wpath=/local/domain/0/backend/vif/9/0/state
token=2/3: deregister slotnum=2
libxl: debug: libxl_event.c:608:libxl__ev_xswatch_deregister: watch
w=0x7fb6a99f08a8: 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=/local/domain/0/backend/vif/9/0/state token=2/3: empty slot
libxl: debug: libxl_event.c:472:watchfd_callback: watch
epath=/local/domain/0/backend/vif/9/0/state token=2/3: empty slot
libxl: debug: libxl_event.c:1569:libxl__ao_complete: ao
0x7fb6a99f1b60: complete, rc=0
libxl: debug: libxl_event.c:1541:libxl__ao__destroy: ao 0x7fb6a99f1b60: destroy
libxl: debug: libxl_event.c:596:libxl__ev_xswatch_deregister: watch
w=0x7fb678001cf0 wpath=@releaseDomain token=3/2: deregister slotnum=3
libxl: debug: libxl_event.c:472:watchfd_callback: watch
epath=@releaseDomain token=3/2: empty slot


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

domid: 9
-videoram option does not work with cirrus vga device model. Videoram set to 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 = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 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 state.
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 state.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro state.


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 to 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 = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 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 state.
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 state.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro state.
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=0xb044, val=0x0.
ACPI:debug: write addr=0xb045, val=0x89.
ACPI:debug: write addr=0xb044, val=0x1.
ACPI:debug: write addr=0xb045, val=0x89.
...
ACPI:debug: write addr=0xb044, val=0xff.
ACPI:debug: write addr=0xb045, val=0x89.


Cheers,

-- Marco

From bill at bfccomputing.com  Wed Nov 12 17:19:39 2014
From: bill at bfccomputing.com (Bill McGonigle)
Date: Wed, 12 Nov 2014 12:19:39 -0500
Subject: [Fedora-xen] Enable Xen in f20 qemu? [Was: Xen 4.4 RC2 [TestDay]]
In-Reply-To: <1390292149.23576.49.camel@Solace>
References: <1390243371.4725.35.camel@astar.houby.net>	<alpine.DEB.2.00.1401202300430.3814@procyon.dur.ac.uk>
	<1390292149.23576.49.camel@Solace>
Message-ID: <546396AB.3010109@bfccomputing.com>

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=f20
> 
> Which contains the following:
> 
> dobuild() {
>     ./configure \
>         --prefix=%{_prefix} \
>         --libdir=%{_libdir} \
>         --sysconfdir=%{_sysconfdir} \
>         --interp-prefix=%{_prefix}/qemu-%%M \
>         --audio-drv-list=pa,sdl,alsa,oss \
>         --localstatedir=%{_localstatedir} \
>         --libexecdir=%{_libexecdir} \
>         --disable-strip \
>         --extra-ldflags="$extraldflags -pie -Wl,-z,relro -Wl,-z,now" \
>         --extra-cflags="%{optflags} -fPIE -DPIE" \
>         --enable-mixemu \
>         --enable-trace-backend=dtrace \
>         --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=testvm --ram=2048 --vcpus=2 --cpuset=2-11
--location=http://librescu/cobbler/ks_mirror/centos6-x86_64
--os-type=linux --os-variant=rhel6 --disk
path=/dev/zvol/storage/testvm/boot --disk
path=/dev/zvol/storage/testvm/root --network
bridge=br0,mac=02:00:0a:0a:0a:19 --graphics=vnc --paravirt --arch=x86_64
--virt-type=xen

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=libxl-cmd,path=/var/run/xen/qmp-libxl-13,server,nowait -mon
chardev=libxl-cmd,mode=control -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 at bfccomputing.com
VCard: http://bfccomputing.com/vcard/bill.vcf
Social networks: bill_mcgonigle/bill.mcgonigle

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/xen/attachments/20141112/f8343737/attachment.sig>

From marco.guazzone at gmail.com  Thu Nov 13 08:49:19 2014
From: marco.guazzone at gmail.com (Marco Guazzone)
Date: Thu, 13 Nov 2014 09:49:19 +0100
Subject: [Fedora-xen] [f20] Problem with libvirt + Xen XL toolstack
In-Reply-To: <5463F696.9050600@suse.com>
References: <CABbE_O442-dwMdRzT6FsYjr8rUViGAoQ9e+1_fWd90DPFnxU9w@mail.gmail.com>
	<20141111155318.GA13402@laptop.dumpdata.com>
	<CABbE_O7zPpS-Cfsyp45yumQfkeJng-bgtPt57vkvvrTGF_KPHA@mail.gmail.com>
	<20141111164355.GA15019@laptop.dumpdata.com>
	<CABbE_O6e3mgOC4ufwogaMwn3=BymMY0bKFGNd7V7Fc5ZZoxfbQ@mail.gmail.com>
	<20141111221113.GB30289@laptop.dumpdata.com>
	<5462F6A5.1080607@suse.com>
	<CABbE_O6inuDP4J1mJsTOYi_xG7F_GDL+KBW_8GQwzGvwLa3VLw@mail.gmail.com>
	<54637CA8.6040800@suse.com>
	<CABbE_O6CqnKGKdLtfuwMy=2=OriNUmMfvAh6KrZSS7D-vV84VA@mail.gmail.com>
	<5463F696.9050600@suse.com>
Message-ID: <CABbE_O6eSs9mFh6X7-XfcWbV+WXhJsSO6gjtGL8pxSqjLyQkqg@mail.gmail.com>

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

Sure!

> 1. the config you use with xl

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


> 2. the XML config you use with libvirt

<domain type='xen'>
  <name>testvm</name>
  <uuid>93f08541-bfd5-4ac4-851d-c619a4516a13</uuid>
  <memory unit='KiB'>3145728</memory>
  <currentMemory unit='KiB'>2097152</currentMemory>
  <vcpu placement='static'>1</vcpu>
  <os>
    <type arch='x86_64' machine='xenfv'>hvm</type>
    <loader>/usr/lib/xen/boot/hvmloader</loader>
    <boot dev='hd'/>
<!--
    <boot dev='hd'/>
-->
  </os>
  <clock offset='variable' adjustment='0' basis='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <disk type='file' device='disk'>
<!--
      <driver name='file'/>
-->
      <driver name='qemu'/>
      <source file='/root/images/test.img'/>
      <target dev='hda' bus='ide'/>
    </disk>
    <disk type='file' device='cdrom'>
<!--
      <driver name='file'/>
-->
      <driver name='qemu'/>
      <source file='/root/iso/CentOS-7.0-1406-x86_64-Minimal.iso'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
    </disk>
    <interface type='bridge'>
      <mac address='00:00:00:00:00:00'/>
      <source bridge='xenbr0'/>
      <script path='vif-bridge'/>
    </interface>
    <input type='mouse' bus='ps2'/>
    <graphics type='vnc' port='-1' autoport='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=0,macaddr=00:16:3e:5c:c2:5a,model=rtl8139 -net
tap,vlan=0,ifname=vif11.0-emu,bridge=xenbr0,script=no,downscript=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

From crobinso at redhat.com  Sun Nov 16 16:52:49 2014
From: crobinso at redhat.com (Cole Robinson)
Date: Sun, 16 Nov 2014 11:52:49 -0500
Subject: [Fedora-xen] Enable Xen in f20 qemu? [Was: Xen 4.4 RC2
	[TestDay]]
In-Reply-To: <546396AB.3010109@bfccomputing.com>
References: <1390243371.4725.35.camel@astar.houby.net>	<alpine.DEB.2.00.1401202300430.3814@procyon.dur.ac.uk>	<1390292149.23576.49.camel@Solace>
	<546396AB.3010109@bfccomputing.com>
Message-ID: <5468D661.2060705@redhat.com>

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=f20
>>
>> Which contains the following:
>>
>> dobuild() {
>>      ./configure \
>>          --prefix=%{_prefix} \
>>          --libdir=%{_libdir} \
>>          --sysconfdir=%{_sysconfdir} \
>>          --interp-prefix=%{_prefix}/qemu-%%M \
>>          --audio-drv-list=pa,sdl,alsa,oss \
>>          --localstatedir=%{_localstatedir} \
>>          --libexecdir=%{_libexecdir} \
>>          --disable-strip \
>>          --extra-ldflags="$extraldflags -pie -Wl,-z,relro -Wl,-z,now" \
>>          --extra-cflags="%{optflags} -fPIE -DPIE" \
>>          --enable-mixemu \
>>          --enable-trace-backend=dtrace \
>>          --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=testvm --ram=2048 --vcpus=2 --cpuset=2-11
> --location=http://librescu/cobbler/ks_mirror/centos6-x86_64
> --os-type=linux --os-variant=rhel6 --disk
> path=/dev/zvol/storage/testvm/boot --disk
> path=/dev/zvol/storage/testvm/root --network
> bridge=br0,mac=02:00:0a:0a:0a:19 --graphics=vnc --paravirt --arch=x86_64
> --virt-type=xen
>
> 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=libxl-cmd,path=/var/run/xen/qmp-libxl-13,server,nowait -mon
> chardev=libxl-cmd,mode=control -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


From marco.guazzone at gmail.com  Mon Nov 17 09:20:30 2014
From: marco.guazzone at gmail.com (Marco Guazzone)
Date: Mon, 17 Nov 2014 10:20:30 +0100
Subject: [Fedora-xen] [f20] Problem with libvirt + Xen XL toolstack
In-Reply-To: <CABbE_O6eSs9mFh6X7-XfcWbV+WXhJsSO6gjtGL8pxSqjLyQkqg@mail.gmail.com>
References: <CABbE_O442-dwMdRzT6FsYjr8rUViGAoQ9e+1_fWd90DPFnxU9w@mail.gmail.com>
	<20141111155318.GA13402@laptop.dumpdata.com>
	<CABbE_O7zPpS-Cfsyp45yumQfkeJng-bgtPt57vkvvrTGF_KPHA@mail.gmail.com>
	<20141111164355.GA15019@laptop.dumpdata.com>
	<CABbE_O6e3mgOC4ufwogaMwn3=BymMY0bKFGNd7V7Fc5ZZoxfbQ@mail.gmail.com>
	<20141111221113.GB30289@laptop.dumpdata.com>
	<5462F6A5.1080607@suse.com>
	<CABbE_O6inuDP4J1mJsTOYi_xG7F_GDL+KBW_8GQwzGvwLa3VLw@mail.gmail.com>
	<54637CA8.6040800@suse.com>
	<CABbE_O6CqnKGKdLtfuwMy=2=OriNUmMfvAh6KrZSS7D-vV84VA@mail.gmail.com>
	<5463F696.9050600@suse.com>
	<CABbE_O6eSs9mFh6X7-XfcWbV+WXhJsSO6gjtGL8pxSqjLyQkqg@mail.gmail.com>
Message-ID: <CABbE_O7noozMkM92ctRyZ8O6rfWS2qNscdUn_jx6oNjaHvy-Mg@mail.gmail.com>

On Thu, Nov 13, 2014 at 9:49 AM, Marco Guazzone
<marco.guazzone at gmail.com> wrote:
> On Thu, Nov 13, 2014 at 1:08 AM, Jim Fehlig <jfehlig at suse.com> wrote:
>>
>> Can you provide
>>
>
> Sure!
>
>> 1. the config you use with xl
>
> name = "testvm"
> uuid = "93f08541-bfd5-4ac4-851d-c619a4516a13"
> kernel = "/usr/lib/xen/boot/hvmloader"
> builder = "hvm"
> maxmem = 3072
> memory = 2048
> vcpus = 1
> on_crash = "restart"
> disk = [ "file:/root/images/test.img,hda,w",
> "file:/root/iso/CentOS-7.0-1406-x86_64-Minimal.iso,hdc:cdrom,r" ]
> vif = [ "bridge=xenbr0,script=vif-bridge" ]
> boot = "cd"
> sdl = 0
> vnc = 1
> vncunused = 1
> xen_platform_pci = 1
>
>
>> 2. the XML config you use with libvirt
>
> <domain type='xen'>
>   <name>testvm</name>
>   <uuid>93f08541-bfd5-4ac4-851d-c619a4516a13</uuid>
>   <memory unit='KiB'>3145728</memory>
>   <currentMemory unit='KiB'>2097152</currentMemory>
>   <vcpu placement='static'>1</vcpu>
>   <os>
>     <type arch='x86_64' machine='xenfv'>hvm</type>
>     <loader>/usr/lib/xen/boot/hvmloader</loader>
>     <boot dev='hd'/>
> <!--
>     <boot dev='hd'/>
> -->
>   </os>
>   <clock offset='variable' adjustment='0' basis='utc'/>
>   <on_poweroff>destroy</on_poweroff>
>   <on_reboot>restart</on_reboot>
>   <on_crash>restart</on_crash>
>   <devices>
>     <disk type='file' device='disk'>
> <!--
>       <driver name='file'/>
> -->
>       <driver name='qemu'/>
>       <source file='/root/images/test.img'/>
>       <target dev='hda' bus='ide'/>
>     </disk>
>     <disk type='file' device='cdrom'>
> <!--
>       <driver name='file'/>
> -->
>       <driver name='qemu'/>
>       <source file='/root/iso/CentOS-7.0-1406-x86_64-Minimal.iso'/>
>       <target dev='hdc' bus='ide'/>
>       <readonly/>
>     </disk>
>     <interface type='bridge'>
>       <mac address='00:00:00:00:00:00'/>
>       <source bridge='xenbr0'/>
>       <script path='vif-bridge'/>
>     </interface>
>     <input type='mouse' bus='ps2'/>
>     <graphics type='vnc' port='-1' autoport='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=0,macaddr=00:16:3e:5c:c2:5a,model=rtl8139 -net
> tap,vlan=0,ifname=vif11.0-emu,bridge=xenbr0,script=no,downscript=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,
>

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='x86_64' machine='xenfv'>hvm</type>
    <loader>/usr/lib/xen/boot/hvmloader</loader>
    <boot dev='hd'/>
<!--
    <boot dev='hd'/>
-->
    <boot dev='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 to 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 = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 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 state.
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 state.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro state.


/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=(nil) callback=(nil) poller=0x7f65041796f0
libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
vdev=hda spec.backend=qdisk
libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
vdev=hdc spec.backend=qdisk
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=0x7f6504184728: deregister unregistered
libxl: debug: libxl_numa.c:478:libxl__get_numa_candidate: New best
NUMA placement candidate found: nr_nodes=2, nr_cpus=16, nr_vcpus=34,
free_memkb=3461
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=0x100000 memsz=0xa2304
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=hda spec.backend=qdisk
libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
vdev=hdc spec.backend=qdisk
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/qemu-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=0x7f6504184960 wpath=/local/domain/0/device-model/3/state token=3/0:
register slotnum=3
libxl: debug: libxl_create.c:1256:do_domain_create: ao 0x7f6504176c40:
inprogress: poller=0x7f65041796f0, flags=i
libxl: debug: libxl_event.c:503:watchfd_callback: watch
w=0x7f6504184960 wpath=/local/domain/0/device-model/3/state token=3/0:
event epath=/local/domain/0/device-model/3/state
libxl: debug: libxl_event.c:503:watchfd_callback: watch
w=0x7f6504184960 wpath=/local/domain/0/device-model/3/state token=3/0:
event epath=/local/domain/0/device-model/3/state
libxl: debug: libxl_event.c:596:libxl__ev_xswatch_deregister: watch
w=0x7f6504184960 wpath=/local/domain/0/device-model/3/state token=3/0:
deregister slotnum=3
libxl: debug: libxl_event.c:608:libxl__ev_xswatch_deregister: watch
w=0x7f6504184960: deregister unregistered
libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch
w=0x7f650417e9e8 wpath=/local/domain/0/backend/vif/3/0/state
token=3/1: register slotnum=3
libxl: debug: libxl_event.c:503:watchfd_callback: watch
w=0x7f650417e9e8 wpath=/local/domain/0/backend/vif/3/0/state
token=3/1: event epath=/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=0x7f650417e9e8 wpath=/local/domain/0/backend/vif/3/0/state
token=3/1: event epath=/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=0x7f650417e9e8 wpath=/local/domain/0/backend/vif/3/0/state
token=3/1: deregister slotnum=3
libxl: debug: libxl_event.c:608:libxl__ev_xswatch_deregister: watch
w=0x7f650417e9e8: 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=0
libxl: debug: libxl_event.c:1541:libxl__ao__destroy: ao 0x7f6504176c40: destroy
libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch
w=0x7f65040cdb90 wpath=@releaseDomain token=3/2: register slotnum=3
libxl: debug: libxl_event.c:503:watchfd_callback: watch
w=0x7f65040cdb90 wpath=@releaseDomain token=3/2: event
epath=@releaseDomain
libxl: debug: libxl.c:1004:domain_death_xswatch_callback:
[evg=0x7f6504000f50:3] from domid=3 nentries=1 rc=1
libxl: debug: libxl.c:1015:domain_death_xswatch_callback:
[evg=0x7f6504000f50:3]   got=domaininfos[0] got->domain=3
libxl: debug: libxl.c:1042:domain_death_xswatch_callback:  exists
shutdown_reported=0 dominf.flags=ffff0002
libxl: debug: libxl.c:1008:domain_death_xswatch_callback: [evg=0] all reported
libxl: debug: libxl.c:1072:domain_death_xswatch_callback: domain death
search done


Cheers,

-- Marco

From marco.guazzone at gmail.com  Tue Nov 18 16:13:09 2014
From: marco.guazzone at gmail.com (Marco Guazzone)
Date: Tue, 18 Nov 2014 17:13:09 +0100
Subject: [Fedora-xen] [f20] Problem with libvirt + Xen XL toolstack
In-Reply-To: <CABbE_O7noozMkM92ctRyZ8O6rfWS2qNscdUn_jx6oNjaHvy-Mg@mail.gmail.com>
References: <CABbE_O442-dwMdRzT6FsYjr8rUViGAoQ9e+1_fWd90DPFnxU9w@mail.gmail.com>
	<20141111155318.GA13402@laptop.dumpdata.com>
	<CABbE_O7zPpS-Cfsyp45yumQfkeJng-bgtPt57vkvvrTGF_KPHA@mail.gmail.com>
	<20141111164355.GA15019@laptop.dumpdata.com>
	<CABbE_O6e3mgOC4ufwogaMwn3=BymMY0bKFGNd7V7Fc5ZZoxfbQ@mail.gmail.com>
	<20141111221113.GB30289@laptop.dumpdata.com>
	<5462F6A5.1080607@suse.com>
	<CABbE_O6inuDP4J1mJsTOYi_xG7F_GDL+KBW_8GQwzGvwLa3VLw@mail.gmail.com>
	<54637CA8.6040800@suse.com>
	<CABbE_O6CqnKGKdLtfuwMy=2=OriNUmMfvAh6KrZSS7D-vV84VA@mail.gmail.com>
	<5463F696.9050600@suse.com>
	<CABbE_O6eSs9mFh6X7-XfcWbV+WXhJsSO6gjtGL8pxSqjLyQkqg@mail.gmail.com>
	<CABbE_O7noozMkM92ctRyZ8O6rfWS2qNscdUn_jx6oNjaHvy-Mg@mail.gmail.com>
Message-ID: <CABbE_O5wrDfM9BcrNi9eYuszXASwD7AVh=k+qB11qG477m2dJg@mail.gmail.com>

On Mon, Nov 17, 2014 at 10:20 AM, Marco Guazzone
<marco.guazzone at 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='x86_64' machine='xenfv'>hvm</type>
>     <loader>/usr/lib/xen/boot/hvmloader</loader>
>     <boot dev='hd'/>
> <!--
>     <boot dev='hd'/>
> -->
>     <boot dev='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

From marco.guazzone at gmail.com  Tue Nov 25 09:53:31 2014
From: marco.guazzone at gmail.com (Marco Guazzone)
Date: Tue, 25 Nov 2014 10:53:31 +0100
Subject: [Fedora-xen] [f20] Problem with libvirt + Xen XL toolstack
In-Reply-To: <54736660.4040705@suse.com>
References: <CABbE_O442-dwMdRzT6FsYjr8rUViGAoQ9e+1_fWd90DPFnxU9w@mail.gmail.com>
	<20141111155318.GA13402@laptop.dumpdata.com>
	<CABbE_O7zPpS-Cfsyp45yumQfkeJng-bgtPt57vkvvrTGF_KPHA@mail.gmail.com>
	<20141111164355.GA15019@laptop.dumpdata.com>
	<CABbE_O6e3mgOC4ufwogaMwn3=BymMY0bKFGNd7V7Fc5ZZoxfbQ@mail.gmail.com>
	<20141111221113.GB30289@laptop.dumpdata.com>
	<5462F6A5.1080607@suse.com>
	<CABbE_O6inuDP4J1mJsTOYi_xG7F_GDL+KBW_8GQwzGvwLa3VLw@mail.gmail.com>
	<54637CA8.6040800@suse.com>
	<CABbE_O6CqnKGKdLtfuwMy=2=OriNUmMfvAh6KrZSS7D-vV84VA@mail.gmail.com>
	<5463F696.9050600@suse.com>
	<CABbE_O6eSs9mFh6X7-XfcWbV+WXhJsSO6gjtGL8pxSqjLyQkqg@mail.gmail.com>
	<CABbE_O7noozMkM92ctRyZ8O6rfWS2qNscdUn_jx6oNjaHvy-Mg@mail.gmail.com>
	<CABbE_O5wrDfM9BcrNi9eYuszXASwD7AVh=k+qB11qG477m2dJg@mail.gmail.com>
	<54736660.4040705@suse.com>
Message-ID: <CABbE_O60CJ=8g59G19bYFfayO6UTDM16iNbo+K3LGF4MsKyatw@mail.gmail.com>

Hi Jim,

On Mon, Nov 24, 2014 at 6:09 PM, Jim Fehlig <jfehlig at 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 these
> 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