[Fedora-xen] [f20] Problem with libvirt + Xen XL toolstack

Marco Guazzone marco.guazzone at gmail.com
Wed Nov 12 09:46:36 UTC 2014


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


More information about the xen mailing list