Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

Alexander Nusov
Hello,
Sorry for cross-posting, since it's related to Xen hypervisor I'm forwarding this message to the freebsd-xen mailing list.

I'm trying to launch a HVM DomU guest from QCOW2 image by using PV driver on FreeBSD 11 Dom0.
The issue is that guest cannot connect to the device/vbd and requires to wait for 4 minutes to proceed, it goes through the countdown and starts fine (disk, networking)

[    6.684115] XENBUS: Waiting for devices to initialise: 25s...20s...15s...10s...5s...0s...235s...230s...225s...220s...215s...210s...205s...200s...195s...190s...185s...180s...175s...170s...165s...160s...155s...150s...145s...140s...135s...130s...125s...120s...115s...110s...105s...100s...95s...90s...85s...80s...75s...70s...65s...60s...55s...50s...45s...40s...35s...30s...25s...20s...15s...10s...5s...0s...
[  271.591403] XENBUS: Timeout connecting to device: device/vbd/51712 (local state 3, remote state 1)
[  271.599963] XENBUS: Device with no driver: device/vkbd/0
[  271.604249]   Magic number: 1:453:334
...
login:


Unlike Linux It's impossible to boot FreeBSD 11 guests from QCOW2 (xenbusb_nop_confighook_cb timeout)

Steps to reproduce:
1. Download qcow2 cirros image (small linux)
http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img <http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img> <http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img <http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img>>
# file cirros-0.3.4-x86_64-disk.img
cirros-0.3.4-x86_64-disk.img: QEMU QCOW Image (v2), 41126400 bytes
2. create DomU from config bellow xl create -c config.cfg

builder = "hvm"
memory = 512
vcpus = 2
name = "cirros"
disk = [ 'file:qcow2:/root/cirros-0.3.4-x86_64-disk.img,xvda,w' ]
boot = "c"
vnc = 1
vnclisten = "0.0.0.0"
usbdevice = 'tablet'
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
acpi = 1
serial = 'pty'

I've also tried multiple configurations like tap:qcow2:. tap2:qcow2:, aio:, switching from xen bus to ide. didn't work.
The only driver that had no issues was PHY but it supports only RAW images.

Is that a bug or I'm missing something?

tested both STABLE snapshot and 11.0-RELEASE

# uname -a
FreeBSD xen 11.0-STABLE FreeBSD 11.0-STABLE #0 r311441: Thu Jan  5 22:45:20 UTC 2017

# pkg info | grep xen
xen-4.7.0_2                    Xen Hypervisor meta port
xen-kernel-4.7.1_3             Hypervisor using a microkernel design
xen-tools-4.7.1_1              Xen management tool, based on LibXenlight

# cat /boot/loader.conf
hw.pci.mcfg=0
xen_kernel="/boot/xen"
xen_cmdline="dom0_mem=8192M dom0_max_vcpus=8 dom0pvh=1 com1=115200,8n1 guest_loglvl=all loglvl=all"

# xenstore-ls -p
 4 = "" . . . . . . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
  vm = "/vm/94b147df-e15d-11e6-a685-002590d7eca6" . . . . .  (n0,r4)
  name = "cirros" . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
  cpu = ""  . . . . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
   0 = "" . . . . . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
    availability = "online" . . . . . . . . . . . . . . . .  (n0,r4)
   1 = "" . . . . . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
    availability = "online" . . . . . . . . . . . . . . . .  (n0,r4)
  memory = "" . . . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
   static-max = "4194304" . . . . . . . . . . . . . . . . .  (n0,r4)
   target = "4186112" . . . . . . . . . . . . . . . . . . .  (n0,r4)
   videoram = "8192"  . . . . . . . . . . . . . . . . . . .  (n0,r4)
  device = "" . . . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
   suspend = "" . . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
    event-channel = ""  . . . . . . . . . . . . . . . . . .  (n4)
   vbd = "" . . . . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
    51712 = ""  . . . . . . . . . . . . . . . . . . . . . .  (n4,r0)
     backend = "/local/domain/0/backend/qdisk/4/51712"  . .  (n4,r0)
     backend-id = "0" . . . . . . . . . . . . . . . . . . .  (n4,r0)
     state = "3"  . . . . . . . . . . . . . . . . . . . . .  (n4,r0)
     virtual-device = "51712" . . . . . . . . . . . . . . .  (n4,r0)
     device-type = "disk" . . . . . . . . . . . . . . . . .  (n4,r0)
     ring-ref = "8" . . . . . . . . . . . . . . . . . . . .  (n4,r0)
     event-channel = "18" . . . . . . . . . . . . . . . . .  (n4,r0)
     protocol = "x86_64-abi"  . . . . . . . . . . . . . . .  (n4,r0)
   vkbd = ""  . . . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
    0 = ""  . . . . . . . . . . . . . . . . . . . . . . . .  (n4,r0)
     backend = "/local/domain/0/backend/vkbd/4/0" . . . . .  (n4,r0)
     backend-id = "0" . . . . . . . . . . . . . . . . . . .  (n4,r0)
     state = "1"  . . . . . . . . . . . . . . . . . . . . .  (n4,r0)
  control = ""  . . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
   shutdown = ""  . . . . . . . . . . . . . . . . . . . . .  (n4)
   platform-feature-multiprocessor-suspend = "1"  . . . . .  (n0,r4)
   platform-feature-xs_reset_watches = "1"  . . . . . . . .  (n0,r4)
  hvmloader = ""  . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
   bios = "seabios" . . . . . . . . . . . . . . . . . . . .  (n0,r4)
   allow-memory-relocate = "0"  . . . . . . . . . . . . . .  (n0,r4)
  data = "" . . . . . . . . . . . . . . . . . . . . . . . .  (n4)
  drivers = ""  . . . . . . . . . . . . . . . . . . . . . .  (n4)
  feature = ""  . . . . . . . . . . . . . . . . . . . . . .  (n4)
  attr = "" . . . . . . . . . . . . . . . . . . . . . . . .  (n4)
  domid = "4" . . . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
  store = ""  . . . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
   port = "1" . . . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
   ring-ref = "1044476" . . . . . . . . . . . . . . . . . .  (n0,r4)
  platform = "" . . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
   acpi = "1" . . . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
   acpi_s3 = "1"  . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
   acpi_s4 = "1"  . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
  console = ""  . . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
   backend = "/local/domain/0/backend/console/4/0"  . . . .  (n0,r4)
   backend-id = "0" . . . . . . . . . . . . . . . . . . . .  (n4,r0)
   limit = "1048576"  . . . . . . . . . . . . . . . . . . .  (n0,r4)
   type = "xenconsoled" . . . . . . . . . . . . . . . . . .  (n0,r4)
   output = "pty" . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
   tty = "/dev/pts/1" . . . . . . . . . . . . . . . . . . .  (n0,r4)
   port = "2" . . . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
   ring-ref = "1044479" . . . . . . . . . . . . . . . . . .  (n0,r4)
   vnc-listen = "0.0.0.0" . . . . . . . . . . . . . . . . .  (n0,r4)
   vnc-port = "5900"  . . . . . . . . . . . . . . . . . . .  (n0,r4)
  image = ""  . . . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
   device-model-pid = "3255"  . . . . . . . . . . . . . . .  (n0,r4)
  serial = "" . . . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
   0 = "" . . . . . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
    tty = "/dev/pts/2"  . . . . . . . . . . . . . . . . . .  (n0,r4)


libxl: debug: libxl_create.c:1710:do_domain_create: ao 0x803247000: create: how=0x0 callback=0x0 poller=0x8032280a0
libxl: debug: libxl_device.c:347:libxl__device_disk_set_backend: Disk vdev=xvda spec.backend=unknown
libxl: debug: libxl_device.c:310:disk_try_backend: Disk vdev=xvda, backend phy unsuitable due to format qcow2
libxl: debug: libxl_device.c:382:libxl__device_disk_set_backend: Disk vdev=xvda, using backend qdisk
libxl: debug: libxl_create.c:970:initiate_domain_create: running bootloader
libxl: debug: libxl_bootloader.c:324:libxl__bootloader_run: not a PV domain, skipping bootloader
libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0x80325aab8: deregister unregistered
domainbuilder: detail: xc_dom_allocate: cmdline="(null)", features="(null)"
domainbuilder: detail: xc_dom_kernel_file: filename="/usr/local/lib/xen/boot/hvmloader"
domainbuilder: detail: xc_dom_malloc_filemap    : 329 kB
domainbuilder: detail: xc_dom_boot_xen_init: ver 4.7, caps xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
domainbuilder: detail: xc_dom_parse_image: called
domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ...
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ...
domainbuilder: detail: xc_dom_probe_bzimage_kernel: kernel is not a bzImage
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying HVM-generic loader ...
domainbuilder: detail: loader probe OK
xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x5ae04
xc: detail: elf_parse_binary: memory: 0x100000 -> 0x15ae04
domainbuilder: detail: xc_dom_mem_init: mem 504 MB, pages 0x1f800 pages, 4k each
domainbuilder: detail: xc_dom_mem_init: 0x1f800 pages
domainbuilder: detail: xc_dom_boot_mem_init: called
domainbuilder: detail: xc_dom_malloc            : 1008 kB
xc: detail: PHYSICAL MEMORY ALLOCATION:
xc: detail:   4KB PAGES: 0x0000000000000200
xc: detail:   2MB PAGES: 0x00000000000000fb
xc: detail:   1GB PAGES: 0x0000000000000000
domainbuilder: detail: xc_dom_build_image: called
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x100+0x5b at 0x8006d0000
domainbuilder: detail: xc_dom_alloc_segment:   kernel       : 0x100000 -> 0x15b000  (pfn 0x100 + 0x5b pages)
xc: detail: elf_load_binary: phdr 0 at 0x80072b000 -> 0x80077c3a0
domainbuilder: detail: alloc_pgtables_hvm: doing nothing
domainbuilder: detail: xc_dom_build_image  : virt_alloc_end : 0x15b000
domainbuilder: detail: xc_dom_build_image  : virt_pgtab_end : 0x0
domainbuilder: detail: xc_dom_boot_image: called
domainbuilder: detail: bootearly: doing nothing
domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_64
domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_32p
domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_32 <= matches
domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_32p
domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_64
domainbuilder: detail: clear_page: pfn 0xfefff, mfn 0xfefff
domainbuilder: detail: clear_page: pfn 0xfeffc, mfn 0xfeffc
domainbuilder: detail: domain builder memory footprint
domainbuilder: detail:    allocated
domainbuilder: detail:       malloc             : 1012 kB
domainbuilder: detail:       anon mmap          : 0 bytes
domainbuilder: detail:    mapped
domainbuilder: detail:       file mmap          : 329 kB
domainbuilder: detail:       domU mmap          : 364 kB
domainbuilder: detail: vcpu_hvm: called
domainbuilder: detail: xc_dom_gnttab_hvm_seed: called, pfn=0xff000
domainbuilder: detail: xc_dom_gnttab_hvm_seed: called, pfn=0xff001
domainbuilder: detail: xc_dom_release: called
libxl: debug: libxl_device.c:347:libxl__device_disk_set_backend: Disk vdev=xvda spec.backend=qdisk
libxl: debug: libxl_device.c:1156:device_hotplug: No hotplug script to execute
libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0x80337a4d0: deregister unregistered
libxl: debug: libxl.c:3166:libxl__device_disk_find_local_path: Directly accessing local QDISK target /root/cirros-0.3.4-x86_64-disk.img
libxl: debug: libxl_dm.c:755:libxl__dm_runas_helper: sysconf(_SC_GETPW_R_SIZE_MAX) failed, setting the initial buffer size to 2048
libxl: debug: libxl_dm.c:755:libxl__dm_runas_helper: sysconf(_SC_GETPW_R_SIZE_MAX) failed, setting the initial buffer size to 2048
libxl: debug: libxl_dm.c:1498:libxl__build_device_model_args_new: Could not find user xen-qemuuser-shared, starting QEMU as root
libxl: debug: libxl_dm.c:2092:libxl__spawn_local_dm: Spawning device-model /usr/local/lib/xen/bin/qemu-system-i386 with arguments:
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   /usr/local/lib/xen/bin/qemu-system-i386
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -xen-domid
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   3
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -chardev
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-3,server,nowait
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -no-shutdown
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -mon
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   chardev=libxl-cmd,mode=control
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -chardev
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   socket,id=libxenstat-cmd,path=/var/run/xen/qmp-libxenstat-3,server,nowait
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -mon
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   chardev=libxenstat-cmd,mode=control
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -nodefaults
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -no-user-config
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -name
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   vm
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -vnc
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   0.0.0.0:0,to=99
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -display
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   none
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -serial
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   pty
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -device
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   cirrus-vga,vgamem_mb=8
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -boot
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   order=c
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -usb
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -usbdevice
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   tablet
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -smp
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   2,maxcpus=2
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -net
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   none
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -machine
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   xenfv
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -m
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   504
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -drive
libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   file=/root/cirros-0.3.4-x86_64-disk.img,if=ide,index=0,media=disk,format=qcow2,cache=writeback
libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm: Spawning device-model /usr/local/lib/xen/bin/qemu-system-i386 with additional environment:
libxl: debug: libxl_dm.c:2098:libxl__spawn_local_dm:   XEN_QEMU_CONSOLE_LIMIT=1048576
libxl: debug: libxl_event.c:636:libxl__ev_xswatch_register: watch w=0x80325adb0 wpath=/local/domain/0/device-model/3/state token=3/0: register slotnum=3
libxl: debug: libxl_create.c:1736:do_domain_create: ao 0x803247000: inprogress: poller=0x8032280a0, flags=i
libxl: debug: libxl_event.c:573:watchfd_callback: watch w=0x80325adb0 wpath=/local/domain/0/device-model/3/state token=3/0: event epath=/local/domain/0/device-model/3/state
libxl: debug: libxl_exec.c:398:spawn_watch_event: domain 3 device model: spawn watch p=(null)
libxl: debug: libxl_event.c:573:watchfd_callback: watch w=0x80325adb0 wpath=/local/domain/0/device-model/3/state token=3/0: event epath=/local/domain/0/device-model/3/state
libxl: debug: libxl_exec.c:398:spawn_watch_event: domain 3 device model: spawn watch p=running
libxl: debug: libxl_event.c:673:libxl__ev_xswatch_deregister: watch w=0x80325adb0 wpath=/local/domain/0/device-model/3/state token=3/0: deregister slotnum=3
libxl: debug: libxl_exec.c:129:libxl_report_child_exitstatus: domain 3 device model (dying as expected) [853] died due to fatal signal Killed
libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0x80325adb0: deregister unregistered
libxl: debug: libxl_qmp.c:707:libxl__qmp_initialize: connected to /var/run/xen/qmp-libxl-3
libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: qmp
libxl: debug: libxl_qmp.c:556:qmp_send_prepare: next qmp command: '{
    "execute": "qmp_capabilities",
    "id": 1
}
'
libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: return
libxl: debug: libxl_qmp.c:556:qmp_send_prepare: next qmp command: '{
    "execute": "query-chardev",
    "id": 2
}
'
libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: return
libxl: debug: libxl_qmp.c:556:qmp_send_prepare: next qmp command: '{
    "execute": "query-vnc",
    "id": 3
}
'
libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: return
libxl: debug: libxl_event.c:2180:libxl__ao_progress_report: ao 0x803247000: progress report: ignored
libxl: debug: libxl_event.c:1869:libxl__ao_complete: ao 0x803247000: complete, rc=0
libxl: debug: libxl_event.c:1838:libxl__ao__destroy: ao 0x803247000: destroy
libxl: debug: libxl_qmp.c:707:libxl__qmp_initialize: connected to /var/run/xen/qmp-libxl-3
libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: qmp
libxl: debug: libxl_qmp.c:556:qmp_send_prepare: next qmp command: '{
    "execute": "qmp_capabilities",
    "id": 1
}
'
libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: return
libxl: debug: libxl_qmp.c:556:qmp_send_prepare: next qmp command: '{
    "execute": "cont",
    "id": 2
}
'
libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: return
xencall:buffer: debug: total allocations:285 total releases:285
xencall:buffer: debug: current allocations:0 maximum allocations:3
xencall:buffer: debug: cache current size:3
xencall:buffer: debug: cache hits:269 misses:3 toobig:13


Thanks,
Alex
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

Roger Pau Monné
On Mon, Jan 23, 2017 at 06:25:23PM +0300, Alexander Nusov wrote:

> Hello,
> Sorry for cross-posting, since it's related to Xen hypervisor I'm forwarding this message to the freebsd-xen mailing list.
>
> I'm trying to launch a HVM DomU guest from QCOW2 image by using PV driver on FreeBSD 11 Dom0.
> The issue is that guest cannot connect to the device/vbd and requires to wait for 4 minutes to proceed, it goes through the countdown and starts fine (disk, networking)
>
> [    6.684115] XENBUS: Waiting for devices to initialise: 25s...20s...15s...10s...5s...0s...235s...230s...225s...220s...215s...210s...205s...200s...195s...190s...185s...180s...175s...170s...165s...160s...155s...150s...145s...140s...135s...130s...125s...120s...115s...110s...105s...100s...95s...90s...85s...80s...75s...70s...65s...60s...55s...50s...45s...40s...35s...30s...25s...20s...15s...10s...5s...0s...
> [  271.591403] XENBUS: Timeout connecting to device: device/vbd/51712 (local state 3, remote state 1)
> [  271.599963] XENBUS: Device with no driver: device/vkbd/0
> [  271.604249]   Magic number: 1:453:334
> ...
> login:
>
>
> Unlike Linux It's impossible to boot FreeBSD 11 guests from QCOW2 (xenbusb_nop_confighook_cb timeout)
>
> Steps to reproduce:
> 1. Download qcow2 cirros image (small linux)
> http://secure-web.cisco.com/1RtWXk7FS6UyRxe5A9ejZVfU2VK9512Yeds80mlP_0LoLwQJLjbPBoILL2e4QyF2OaMyO8fbrQrYVmfOybSYvHgWH1sRz1gK4Zi5XDAzBDUluwhlU4NxVQ7S17tH6vSTrIJmBJ_NO-sdA1Ph_KfSOsNvMkw-swwuKHD9ophVFfqEe6Lnt_PIP4H-LhZfp-5_aCuqbPYciXtMyxWbF1Od65jiFe-_LfmPRt53aCscOk7cBRI_-o603sb7htpDHH06Y8-M4oG5Lt4s1jr1XcKTrIWhnD-Lhz55blWyc2FnCgvk/http%3A%2F%2Fdownload.cirros-cloud.net%2F0.3.4%2Fcirros-0.3.4-x86_64-disk.img <http://secure-web.cisco.com/1RtWXk7FS6UyRxe5A9ejZVfU2VK9512Yeds80mlP_0LoLwQJLjbPBoILL2e4QyF2OaMyO8fbrQrYVmfOybSYvHgWH1sRz1gK4Zi5XDAzBDUluwhlU4NxVQ7S17tH6vSTrIJmBJ_NO-sdA1Ph_KfSOsNvMkw-swwuKHD9ophVFfqEe6Lnt_PIP4H-LhZfp-5_aCuqbPYciXtMyxWbF1Od65jiFe-_LfmPRt53aCscOk7cBRI_-o603sb7htpDHH06Y8-M4oG5Lt4s1jr1XcKTrIWhnD-Lhz55blWyc2FnCgvk/http%3A%2F%2Fdownload.cirros-cloud.net%2F0.3.4%2Fcirros-0.3.4-x86_64-disk.img> <http://secure-web.cisco.com/1h_h-Ne-wDq4bbwU9ZrC1722aqj6tnLpUb48xOrWDDI-W6cCX481vFPY87v33Z6en8zvIqxlgFkymKM5mDMhPoCbZSXzBlp7hYWr2FKVaEAU93FEW0HTQZ8ef6ygHIyGE6XTUgsLjgPZQfhl4_zNjWc
 IYzp6HWWVVZ3VrCNN-GEuMZ0JeedNQaKXavQhUK_dbVxh_4dLA1x9nKvutnTw5DDB-gECJjPjG07SrD4nh15HBLZi7Ua4X0PDRDbt3SGDcsqKO6oHPA2ajZjzWSLVp0l8PKgvNLjckBLRrWCFs8tQ/http%3A%2F%2Fdownload.cirros-cloud.net%2F0.3.4%2Fcirros-0.3.4-x86_64-disk.img <http://secure-web.cisco.com/1h_h-Ne-wDq4bbwU9ZrC1722aqj6tnLpUb48xOrWDDI-W6cCX481vFPY87v33Z6en8zvIqxlgFkymKM5mDMhPoCbZSXzBlp7hYWr2FKVaEAU93FEW0HTQZ8ef6ygHIyGE6XTUgsLjgPZQfhl4_zNjWcIYzp6HWWVVZ3VrCNN-GEuMZ0JeedNQaKXavQhUK_dbVxh_4dLA1x9nKvutnTw5DDB-gECJjPjG07SrD4nh15HBLZi7Ua4X0PDRDbt3SGDcsqKO6oHPA2ajZjzWSLVp0l8PKgvNLjckBLRrWCFs8tQ/http%3A%2F%2Fdownload.cirros-cloud.net%2F0.3.4%2Fcirros-0.3.4-x86_64-disk.img>>

> # file cirros-0.3.4-x86_64-disk.img
> cirros-0.3.4-x86_64-disk.img: QEMU QCOW Image (v2), 41126400 bytes
> 2. create DomU from config bellow xl create -c config.cfg
>
> builder = "hvm"
> memory = 512
> vcpus = 2
> name = "cirros"
> disk = [ 'file:qcow2:/root/cirros-0.3.4-x86_64-disk.img,xvda,w' ]
> boot = "c"
> vnc = 1
> vnclisten = "0.0.0.0"
> usbdevice = 'tablet'
> on_poweroff = 'destroy'
> on_reboot = 'restart'
> on_crash = 'restart'
> acpi = 1
> serial = 'pty'
>
> I've also tried multiple configurations like tap:qcow2:. tap2:qcow2:, aio:, switching from xen bus to ide. didn't work.
> The only driver that had no issues was PHY but it supports only RAW images.
>
> Is that a bug or I'm missing something?
>
> tested both STABLE snapshot and 11.0-RELEASE
>
> # uname -a
> FreeBSD xen 11.0-STABLE FreeBSD 11.0-STABLE #0 r311441: Thu Jan  5 22:45:20 UTC 2017
>
> # pkg info | grep xen
> xen-4.7.0_2                    Xen Hypervisor meta port
> xen-kernel-4.7.1_3             Hypervisor using a microkernel design
> xen-tools-4.7.1_1              Xen management tool, based on LibXenlight

So just that I understand this correctly, this is a FreeBSD 11.0-STABLE Dom0,
plus the Xen packages from pkg?

If that's the case, it's not going to work, FreeBSD 11.0 Dom0 doesn't yet
support qcow image format for HVM/PV guests, you will have to use FreeBSD 12
(HEAD) as your Dom0, or backport r308128 into STABLE (should be self contained,
so I don't expect any conflicts). You will also have to apply the following
patch to the xen-tools package and recompile:

https://lists.freebsd.org/pipermail/freebsd-xen/2016-August/002819.html

IIRC the right syntax to specify the disk device is:

'format=qcow2,vdev=xvda,access=rw,backendtype=qdisk,target=/root/cirros-0.3.4-x86_64-disk.img'

I'm also adding Akshay to the conversation, who did the gntdev implementation.

Roger.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

Alexander Nusov
Yes, it was FreeBSD 11.0-STABLE Dom0 with xen-kernel/xen-tools built from the ports tree (head)



It seems there is an issue with xen pci devices, since booting from QCOW2 images actually works (even on FreeBSD 11.0-RELEASE branch) except communication with /xen/vbd devices from the guest.


By the way, I installed FreeBSD 12-CURRENT r311461 snapshot and applied the patch for xen-utils and now things got worse,

qemu-system-i386 process started to crash at this point:

[    1.162342] GHES: HEST is not enabled!

[    1.166829] xen-platform-pci 0000:00:02.0: PCI INT A -&gt; GSI 24 (level, low) -&gt; IRQ 24

[    1.191301] Grant table initialized

[    1.197758] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled

[    1.238473] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A

[    1.246103] init_memory_mapping: 0000000020000000-0000000028000000

[    1.374895] 00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A

[    1.381290] Linux agpgart interface v0.103

[    1.387732] brd: module loaded

[    1.392518] loop: module loaded

CRASH



root@current:~ # cat /var/log/xen/xl-vm.log

Waiting for domain vm (domid 4) to die [pid 18070]

libxl: debug: libxl_event.c:636:libxl__ev_xswatch_register: watch w=0x80321c3e0 wpath=@releaseDomain token=3/0: register slotnum=3

libxl: debug: libxl_event.c:573:watchfd_callback: watch w=0x80321c3e0 wpath=@releaseDomain token=3/0: event epath=@releaseDomain

libxl: debug: libxl.c:1184:domain_death_xswatch_callback: [evg=0x803221aa0:4] nentries=1 rc=1 4..4

libxl: debug: libxl.c:1195:domain_death_xswatch_callback: [evg=0x803221aa0:4]   got=domaininfos[0] got-&gt;domain=4

libxl: debug: libxl.c:1221:domain_death_xswatch_callback:  exists shutdown_reported=0 dominf.flags=ffff0002

libxl: debug: libxl.c:1188:domain_death_xswatch_callback: [evg=0] all reported

libxl: debug: libxl.c:1250:domain_death_xswatch_callback: domain death search done



Then I did a xen-utils rollback and stuck with the same issue (Waiting for XENBUS), no crash though.



root@current:~ # cat vm.cfg

builder = "hvm"

memory = 512

vcpus = 2

name = "vm"

disk = ['format=qcow2,vdev=xvda,access=rw,backendtype=qdisk,target=/root/cirros-0.3.4-x86_64-disk.img']

boot = "c"

vnc = 1

vnclisten = "0.0.0.0"

usbdevice = 'tablet'

on_poweroff = 'destroy'

on_reboot = 'restart'

on_crash = 'restart'

acpi = 1

serial = 'pty'



root@current:~ # cat /boot/loader.conf

hw.pci.mcfg=0

xen_kernel="/boot/xen"

xen_cmdline="dom0_mem=8192M dom0_max_vcpus=8 dom0pvh=1 com1=115200,8n1 guest_loglvl=all loglvl=all"



root@current:~ # cat /etc/sysctl.conf

vm.max_wired=-1



root@current:~ # xl -vvv create vm.cfg

Parsing config from vm.cfg

libxl: debug: libxl_create.c:1710:do_domain_create: ao 0x803247000: create: how=0x0 callback=0x0 poller=0x8032280a0

libxl: debug: libxl_device.c:347:libxl__device_disk_set_backend: Disk vdev=xvda spec.backend=qdisk

libxl: debug: libxl_create.c:970:initiate_domain_create: running bootloader

libxl: debug: libxl_bootloader.c:324:libxl__bootloader_run: not a PV domain, skipping bootloader

libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0x80325dab8: deregister unregistered

domainbuilder: detail: xc_dom_allocate: cmdline="(null)", features="(null)"

domainbuilder: detail: xc_dom_kernel_file: filename="/usr/local/lib/xen/boot/hvmloader"

domainbuilder: detail: xc_dom_malloc_filemap    : 329 kB

domainbuilder: detail: xc_dom_boot_xen_init: ver 4.7, caps xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64

domainbuilder: detail: xc_dom_parse_image: called

domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ...

domainbuilder: detail: loader probe failed

domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ...

domainbuilder: detail: xc_dom_probe_bzimage_kernel: kernel is not a bzImage

domainbuilder: detail: loader probe failed

domainbuilder: detail: xc_dom_find_loader: trying HVM-generic loader ...

domainbuilder: detail: loader probe OK

xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x5ad0c

xc: detail: elf_parse_binary: memory: 0x100000 -&gt; 0x15ad0c

domainbuilder: detail: xc_dom_mem_init: mem 504 MB, pages 0x1f800 pages, 4k each

domainbuilder: detail: xc_dom_mem_init: 0x1f800 pages

domainbuilder: detail: xc_dom_boot_mem_init: called

domainbuilder: detail: xc_dom_malloc            : 1008 kB

xc: detail: PHYSICAL MEMORY ALLOCATION:

xc: detail:   4KB PAGES: 0x0000000000000200

xc: detail:   2MB PAGES: 0x00000000000000fb

xc: detail:   1GB PAGES: 0x0000000000000000

domainbuilder: detail: xc_dom_build_image: called

domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x100+0x5b at 0x8006d1000

domainbuilder: detail: xc_dom_alloc_segment:   kernel       : 0x100000 -&gt; 0x15b000  (pfn 0x100 + 0x5b pages)

xc: detail: elf_load_binary: phdr 0 at 0x80072c000 -&gt; 0x80077d2a8

domainbuilder: detail: alloc_pgtables_hvm: doing nothing

domainbuilder: detail: xc_dom_build_image  : virt_alloc_end : 0x15b000

domainbuilder: detail: xc_dom_build_image  : virt_pgtab_end : 0x0

domainbuilder: detail: xc_dom_boot_image: called

domainbuilder: detail: bootearly: doing nothing

domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_64

domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_32p

domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_32 &lt;= matches

domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_32p

domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_64

domainbuilder: detail: clear_page: pfn 0xfefff, mfn 0xfefff

domainbuilder: detail: clear_page: pfn 0xfeffc, mfn 0xfeffc

domainbuilder: detail: domain builder memory footprint

domainbuilder: detail:    allocated

domainbuilder: detail:       malloc             : 1012 kB

domainbuilder: detail:       anon mmap          : 0 bytes

domainbuilder: detail:    mapped

domainbuilder: detail:       file mmap          : 329 kB

domainbuilder: detail:       domU mmap          : 364 kB

domainbuilder: detail: vcpu_hvm: called

domainbuilder: detail: xc_dom_gnttab_hvm_seed: called, pfn=0xff000

domainbuilder: detail: xc_dom_gnttab_hvm_seed: called, pfn=0xff001

domainbuilder: detail: xc_dom_release: called

libxl: debug: libxl_device.c:347:libxl__device_disk_set_backend: Disk vdev=xvda spec.backend=qdisk

libxl: debug: libxl_device.c:1156:device_hotplug: No hotplug script to execute

libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0x80337d4d0: deregister unregistered

libxl: debug: libxl.c:3166:libxl__device_disk_find_local_path: Directly accessing local QDISK target /root/cirros-0.3.4-x86_64-disk.img

libxl: debug: libxl_dm.c:755:libxl__dm_runas_helper: sysconf(_SC_GETPW_R_SIZE_MAX) failed, setting the initial buffer size to 2048

libxl: debug: libxl_dm.c:755:libxl__dm_runas_helper: sysconf(_SC_GETPW_R_SIZE_MAX) failed, setting the initial buffer size to 2048

libxl: debug: libxl_dm.c:1498:libxl__build_device_model_args_new: Could not find user xen-qemuuser-shared, starting QEMU as root

libxl: debug: libxl_dm.c:2092:libxl__spawn_local_dm: Spawning device-model /usr/local/lib/xen/bin/qemu-system-i386 with arguments:

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   /usr/local/lib/xen/bin/qemu-system-i386

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -xen-domid

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   4

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -chardev

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-4,server,nowait

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -no-shutdown

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -mon

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   chardev=libxl-cmd,mode=control

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -chardev

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   socket,id=libxenstat-cmd,path=/var/run/xen/qmp-libxenstat-4,server,nowait

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -mon

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   chardev=libxenstat-cmd,mode=control

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -nodefaults

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -no-user-config

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -name

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   vm

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -vnc

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   0.0.0.0:0,to=99

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -display

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   none

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -serial

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   pty

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -device

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   cirrus-vga,vgamem_mb=8

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -boot

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   order=c

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -usb

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -usbdevice

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   tablet

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -smp

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   2,maxcpus=2

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -net

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   none

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -machine

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   xenfv

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -m

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   504

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   -drive

libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm:   file=/root/cirros-0.3.4-x86_64-disk.img,if=ide,index=0,media=disk,format=qcow2,cache=writeback

libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm: Spawning device-model /usr/local/lib/xen/bin/qemu-system-i386 with additional environment:

libxl: debug: libxl_dm.c:2098:libxl__spawn_local_dm:   XEN_QEMU_CONSOLE_LIMIT=1048576

libxl: debug: libxl_event.c:636:libxl__ev_xswatch_register: watch w=0x80325ddb0 wpath=/local/domain/0/device-model/4/state token=3/0: register slotnum=3

libxl: debug: libxl_create.c:1736:do_domain_create: ao 0x803247000: inprogress: poller=0x8032280a0, flags=i

libxl: debug: libxl_event.c:573:watchfd_callback: watch w=0x80325ddb0 wpath=/local/domain/0/device-model/4/state token=3/0: event epath=/local/domain/0/device-model/4/state

libxl: debug: libxl_exec.c:398:spawn_watch_event: domain 4 device model: spawn watch p=(null)

libxl: debug: libxl_event.c:573:watchfd_callback: watch w=0x80325ddb0 wpath=/local/domain/0/device-model/4/state token=3/0: event epath=/local/domain/0/device-model/4/state

libxl: debug: libxl_exec.c:398:spawn_watch_event: domain 4 device model: spawn watch p=running

libxl: debug: libxl_event.c:673:libxl__ev_xswatch_deregister: watch w=0x80325ddb0 wpath=/local/domain/0/device-model/4/state token=3/0: deregister slotnum=3

libxl: debug: libxl_exec.c:129:libxl_report_child_exitstatus: domain 4 device model (dying as expected) [18067] died due to fatal signal Killed

libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0x80325ddb0: deregister unregistered

libxl: debug: libxl_qmp.c:707:libxl__qmp_initialize: connected to /var/run/xen/qmp-libxl-4

libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: qmp

libxl: debug: libxl_qmp.c:556:qmp_send_prepare: next qmp command: '{

    "execute": "qmp_capabilities",

    "id": 1

}

'

libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: return

libxl: debug: libxl_qmp.c:556:qmp_send_prepare: next qmp command: '{

    "execute": "query-chardev",

    "id": 2

}

'

libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: return

libxl: debug: libxl_qmp.c:556:qmp_send_prepare: next qmp command: '{

    "execute": "query-vnc",

    "id": 3

}

'

libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: return

libxl: debug: libxl_event.c:2180:libxl__ao_progress_report: ao 0x803247000: progress report: ignored

libxl: debug: libxl_event.c:1869:libxl__ao_complete: ao 0x803247000: complete, rc=0

libxl: debug: libxl_event.c:1838:libxl__ao__destroy: ao 0x803247000: destroy

libxl: debug: libxl_qmp.c:707:libxl__qmp_initialize: connected to /var/run/xen/qmp-libxl-4

libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: qmp

libxl: debug: libxl_qmp.c:556:qmp_send_prepare: next qmp command: '{

    "execute": "qmp_capabilities",

    "id": 1

}

'

libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: return

libxl: debug: libxl_qmp.c:556:qmp_send_prepare: next qmp command: '{

    "execute": "cont",

    "id": 2

}

'

libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: return

xencall:buffer: debug: total allocations:289 total releases:289

xencall:buffer: debug: current allocations:0 maximum allocations:3

xencall:buffer: debug: cache current size:3

xencall:buffer: debug: cache hits:271 misses:3 toobig:15





Thanks,

Alex






---- On Tue, 24 Jan 2017 14:44:44 +0300 Roger Pau Monné &lt;[hidden email]&gt; wrote ----




On Mon, Jan 23, 2017 at 06:25:23PM +0300, Alexander Nusov wrote:

&gt; Hello,

&gt; Sorry for cross-posting, since it's related to Xen hypervisor I'm forwarding this message to the freebsd-xen mailing list.

&gt;

&gt; I'm trying to launch a HVM DomU guest from QCOW2 image by using PV driver on FreeBSD 11 Dom0.

&gt; The issue is that guest cannot connect to the device/vbd and requires to wait for 4 minutes to proceed, it goes through the countdown and starts fine (disk, networking)

&gt;

&gt; [ 6.684115] XENBUS: Waiting for devices to initialise: 25s...20s...15s...10s...5s...0s...235s...230s...225s...220s...215s...210s...205s...200s...195s...190s...185s...180s...175s...170s...165s...160s...155s...150s...145s...140s...135s...130s...125s...120s...115s...110s...105s...100s...95s...90s...85s...80s...75s...70s...65s...60s...55s...50s...45s...40s...35s...30s...25s...20s...15s...10s...5s...0s...

&gt; [ 271.591403] XENBUS: Timeout connecting to device: device/vbd/51712 (local state 3, remote state 1)

&gt; [ 271.599963] XENBUS: Device with no driver: device/vkbd/0

&gt; [ 271.604249] Magic number: 1:453:334

&gt; ...

&gt; login:

&gt;

&gt;

&gt; Unlike Linux It's impossible to boot FreeBSD 11 guests from QCOW2 (xenbusb_nop_confighook_cb timeout)

&gt;

&gt; Steps to reproduce:

&gt; 1. Download qcow2 cirros image (small linux)

&gt; # file cirros-0.3.4-x86_64-disk.img

&gt; cirros-0.3.4-x86_64-disk.img: QEMU QCOW Image (v2), 41126400 bytes

&gt; 2. create DomU from config bellow xl create -c config.cfg

&gt;

&gt; builder = "hvm"

&gt; memory = 512

&gt; vcpus = 2

&gt; name = "cirros"

&gt; disk = [ 'file:qcow2:/root/cirros-0.3.4-x86_64-disk.img,xvda,w' ]

&gt; boot = "c"

&gt; vnc = 1

&gt; vnclisten = "0.0.0.0"

&gt; usbdevice = 'tablet'

&gt; on_poweroff = 'destroy'

&gt; on_reboot = 'restart'

&gt; on_crash = 'restart'

&gt; acpi = 1

&gt; serial = 'pty'

&gt;

&gt; I've also tried multiple configurations like tap:qcow2:. tap2:qcow2:, aio:, switching from xen bus to ide. didn't work.

&gt; The only driver that had no issues was PHY but it supports only RAW images.

&gt;

&gt; Is that a bug or I'm missing something?

&gt;

&gt; tested both STABLE snapshot and 11.0-RELEASE

&gt;

&gt; # uname -a

&gt; FreeBSD xen 11.0-STABLE FreeBSD 11.0-STABLE #0 r311441: Thu Jan 5 22:45:20 UTC 2017

&gt;

&gt; # pkg info | grep xen

&gt; xen-4.7.0_2 Xen Hypervisor meta port

&gt; xen-kernel-4.7.1_3 Hypervisor using a microkernel design

&gt; xen-tools-4.7.1_1 Xen management tool, based on LibXenlight



So just that I understand this correctly, this is a FreeBSD 11.0-STABLE Dom0,

plus the Xen packages from pkg?



If that's the case, it's not going to work, FreeBSD 11.0 Dom0 doesn't yet

support qcow image format for HVM/PV guests, you will have to use FreeBSD 12

(HEAD) as your Dom0, or backport r308128 into STABLE (should be self contained,

so I don't expect any conflicts). You will also have to apply the following

patch to the xen-tools package and recompile:



https://lists.freebsd.org/pipermail/freebsd-xen/2016-August/002819.html 



IIRC the right syntax to specify the disk device is:



'format=qcow2,vdev=xvda,access=rw,backendtype=qdisk,target=/root/cirros-0.3.4-x86_64-disk.img'



I'm also adding Akshay to the conversation, who did the gntdev implementation.



Roger.






_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

Roger Pau Monné
On Tue, Jan 24, 2017 at 05:45:25PM +0300, Alexander Nusov wrote:
> Yes, it was FreeBSD 11.0-STABLE Dom0 with xen-kernel/xen-tools built from the ports tree (head)
>
>
>
> It seems there is an issue with xen pci devices, since booting from QCOW2 images actually works (even on FreeBSD 11.0-RELEASE branch) except communication with /xen/vbd devices from the guest.

Yes, I'm seeing exactly the same. The QEMU process is killed with a
segmentation fault. Akshay, here is the full debug output:

Program terminated with signal 11, Segmentation fault.
[...]
#0  blk_handle_requests (blkdev=0x807463c00) at hw/block/xen_disk.c:862
862    rp = blkdev->rings.common.sring->req_prod;
[New Thread 8087f9000 (LWP 100947/<unknown>)]
[New Thread 807418800 (LWP 100945/<unknown>)]
[New Thread 807418300 (LWP 100944/<unknown>)]
[New Thread 807417e00 (LWP 100943/<unknown>)]
[New Thread 807417900 (LWP 100942/<unknown>)]
[New Thread 807417400 (LWP 100941/<unknown>)]
[New Thread 807416a00 (LWP 100940/<unknown>)]
[New Thread 807416500 (LWP 100939/<unknown>)]
[New Thread 807416000 (LWP 100091/<unknown>)]
(gdb) bt
#0  blk_handle_requests (blkdev=0x807463c00) at hw/block/xen_disk.c:862
#1  0x00000000005f9dcd in blk_bh (opaque=0x807463c00) at hw/block/xen_disk.c:918
#2  0x000000000080ba69 in aio_bh_call (bh=0x80780d810) at async.c:87
#3  0x000000000080bb10 in aio_bh_poll (ctx=0x8074a0680) at async.c:115
#4  0x000000000081c099 in aio_dispatch (ctx=0x8074a0680) at aio-posix.c:303
#5  0x000000000080c2cd in aio_ctx_dispatch (source=0x8074a0680, callback=0, user_data=0x0)
    at async.c:254
#6  0x0000000802e3903b in g_main_context_dispatch () from /usr/local/lib/libglib-2.0.so.0
#7  0x000000000081a34c in glib_pollfds_poll () at main-loop.c:259
#8  0x0000000000819dc5 in os_host_main_loop_wait (timeout=0) at main-loop.c:306
#9  0x0000000000819c29 in main_loop_wait (nonblocking=0) at main-loop.c:556
#10 0x0000000000588ed7 in main_loop () at vl.c:1966
#11 0x0000000000583b59 in main (argc=38, argv=0x7fffffffe750, envp=0x7fffffffe888) at vl.c:4684
Current language:  auto; currently minimal

It seems like the device is not properly mapping the grants, and QEMU gets a
SEGFAULT when trying to access the ring page.

Roger.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

Akshay Jaggi-2
Hi Alex and Roger,

Without the patch and FreeBSD 12, qcow2 doesn't actually work. We were
thinking of adding code to warn against this, but then thought gntdev
implementation is in process anyway.
With the patch, the crash needs to be investigated (because I did run one
of the gntdev based image, most probably qcow2, iirc).
Sadly, I'm still searching for housing in Dublin, and hence won't be able
to look at this immediately. Two weeks, to find and then move in, if I'm
lucky. Meanwhile, I'll start hunting for a development machine in office.

Regards,
Akshay

On Jan 24, 2017 16:56, Roger Pau Monné <[hidden email]> wrote:

> On Tue, Jan 24, 2017 at 05:45:25PM +0300, Alexander Nusov wrote:
> > Yes, it was FreeBSD 11.0-STABLE Dom0 with xen-kernel/xen-tools built
> from the ports tree (head)
> >
> >
> >
> > It seems there is an issue with xen pci devices, since booting from
> QCOW2 images actually works (even on FreeBSD 11.0-RELEASE branch) except
> communication with /xen/vbd devices from the guest.
>
> Yes, I'm seeing exactly the same. The QEMU process is killed with a
> segmentation fault. Akshay, here is the full debug output:
>
> Program terminated with signal 11, Segmentation fault.
> [...]
> #0  blk_handle_requests (blkdev=0x807463c00) at hw/block/xen_disk.c:862
> 862         rp = blkdev->rings.common.sring->req_prod;
> [New Thread 8087f9000 (LWP 100947/<unknown>)]
> [New Thread 807418800 (LWP 100945/<unknown>)]
> [New Thread 807418300 (LWP 100944/<unknown>)]
> [New Thread 807417e00 (LWP 100943/<unknown>)]
> [New Thread 807417900 (LWP 100942/<unknown>)]
> [New Thread 807417400 (LWP 100941/<unknown>)]
> [New Thread 807416a00 (LWP 100940/<unknown>)]
> [New Thread 807416500 (LWP 100939/<unknown>)]
> [New Thread 807416000 (LWP 100091/<unknown>)]
> (gdb) bt
> #0  blk_handle_requests (blkdev=0x807463c00) at hw/block/xen_disk.c:862
> #1  0x00000000005f9dcd in blk_bh (opaque=0x807463c00) at
> hw/block/xen_disk.c:918
> #2  0x000000000080ba69 in aio_bh_call (bh=0x80780d810) at async.c:87
> #3  0x000000000080bb10 in aio_bh_poll (ctx=0x8074a0680) at async.c:115
> #4  0x000000000081c099 in aio_dispatch (ctx=0x8074a0680) at aio-posix.c:303
> #5  0x000000000080c2cd in aio_ctx_dispatch (source=0x8074a0680,
> callback=0, user_data=0x0)
>     at async.c:254
> #6  0x0000000802e3903b in g_main_context_dispatch () from /usr/local/lib/
> libglib-2.0.so.0
> #7  0x000000000081a34c in glib_pollfds_poll () at main-loop.c:259
> #8  0x0000000000819dc5 in os_host_main_loop_wait (timeout=0) at
> main-loop.c:306
> #9  0x0000000000819c29 in main_loop_wait (nonblocking=0) at main-loop.c:556
> #10 0x0000000000588ed7 in main_loop () at vl.c:1966
> #11 0x0000000000583b59 in main (argc=38, argv=0x7fffffffe750,
> envp=0x7fffffffe888) at vl.c:4684
> Current language:  auto; currently minimal
>
> It seems like the device is not properly mapping the grants, and QEMU gets
> a
> SEGFAULT when trying to access the ring page.
>
> Roger.
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

Alexander Nusov
Got it, thanks.



I found a workaround to avoid XENBUS delay in Linux DomUs by adding xen_platform_pci = 0 to the configuration file.

So FreeBSD 11.0 Dom0 can boot Linux guests and Windows Server (FreeBSD DomU still stuck on xenbusb_nop_confighook_cb) from QCOW2 images (also works with QCOW2 overlay images)



Can you tell me please what is the disadvantage of not using /dev/xen/vbd devices and drivers in guests? like slow I/O?

May it lead to data corruption?


--

Alex




---- On Wed, 25 Jan 2017 12:35:14 +0300 Akshay Jaggi &lt;[hidden email]&gt; wrote ----




Hi Alex and Roger,



Without the patch and FreeBSD 12, qcow2 doesn't actually work. We were thinking of adding code to warn against this, but then thought gntdev implementation is in process anyway.

With the patch, the crash needs to be investigated (because I did run one of the gntdev based image, most probably qcow2, iirc).

Sadly, I'm still searching for housing in Dublin, and hence won't be able to look at this immediately. Two weeks, to find and then move in, if I'm lucky. Meanwhile, I'll start hunting for a development machine in office.



Regards,

Akshay






On Jan 24, 2017 16:56, Roger Pau Monné &lt;[hidden email]&gt; wrote:






On Tue, Jan 24, 2017 at 05:45:25PM +0300, Alexander Nusov wrote:

&gt; Yes, it was FreeBSD 11.0-STABLE Dom0 with xen-kernel/xen-tools built from the ports tree (head)

&gt;

&gt;

&gt;

&gt; It seems there is an issue with xen pci devices, since booting from QCOW2 images actually works (even on FreeBSD 11.0-RELEASE branch) except communication with /xen/vbd devices from the guest.



Yes, I'm seeing exactly the same. The QEMU process is killed with a

segmentation fault. Akshay, here is the full debug output:



Program terminated with signal 11, Segmentation fault.

[...]

#0  blk_handle_requests (blkdev=0x807463c00) at hw/block/xen_disk.c:862

862         rp = blkdev-&gt;rings.common.sring-&gt;req_prod;

[New Thread 8087f9000 (LWP 100947/&lt;unknown&gt;)]

[New Thread 807418800 (LWP 100945/&lt;unknown&gt;)]

[New Thread 807418300 (LWP 100944/&lt;unknown&gt;)]

[New Thread 807417e00 (LWP 100943/&lt;unknown&gt;)]

[New Thread 807417900 (LWP 100942/&lt;unknown&gt;)]

[New Thread 807417400 (LWP 100941/&lt;unknown&gt;)]

[New Thread 807416a00 (LWP 100940/&lt;unknown&gt;)]

[New Thread 807416500 (LWP 100939/&lt;unknown&gt;)]

[New Thread 807416000 (LWP 100091/&lt;unknown&gt;)]

(gdb) bt

#0  blk_handle_requests (blkdev=0x807463c00) at hw/block/xen_disk.c:862

#1  0x00000000005f9dcd in blk_bh (opaque=0x807463c00) at hw/block/xen_disk.c:918

#2  0x000000000080ba69 in aio_bh_call (bh=0x80780d810) at async.c:87

#3  0x000000000080bb10 in aio_bh_poll (ctx=0x8074a0680) at async.c:115

#4  0x000000000081c099 in aio_dispatch (ctx=0x8074a0680) at aio-posix.c:303

#5  0x000000000080c2cd in aio_ctx_dispatch (source=0x8074a0680, callback=0, user_data=0x0)

    at async.c:254

#6  0x0000000802e3903b in g_main_context_dispatch () from /usr/local/lib/libglib-2.0.so.0

#7  0x000000000081a34c in glib_pollfds_poll () at main-loop.c:259

#8  0x0000000000819dc5 in os_host_main_loop_wait (timeout=0) at main-loop.c:306

#9  0x0000000000819c29 in main_loop_wait (nonblocking=0) at main-loop.c:556

#10 0x0000000000588ed7 in main_loop () at vl.c:1966

#11 0x0000000000583b59 in main (argc=38, argv=0x7fffffffe750, envp=0x7fffffffe888) at vl.c:4684

Current language:  auto; currently minimal



It seems like the device is not properly mapping the grants, and QEMU gets a

SEGFAULT when trying to access the ring page.



Roger.





_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

Roger Pau Monné
On Wed, Jan 25, 2017 at 02:20:55PM +0300, Alexander Nusov wrote:
> Got it, thanks.
>
>
>
> I found a workaround to avoid XENBUS delay in Linux DomUs by adding xen_platform_pci = 0 to the configuration file.
>
> So FreeBSD 11.0 Dom0 can boot Linux guests and Windows Server (FreeBSD DomU still stuck on xenbusb_nop_confighook_cb) from QCOW2 images (also works with QCOW2 overlay images)
>

On FreeBSD you can boot with QCOW2 by not setting "xen_platform_pci = 0" on the
guest config file and adding "hw.xen.disable_pv_disks=1" to the
/boot/loader.conf file of the guest. This will prevent FreeBSD from using the
PV disk, but you will still get the PV network interfaces.

>
> Can you tell me please what is the disadvantage of not using /dev/xen/vbd devices and drivers in guests? like slow I/O?

Slow IO only.

> May it lead to data corruption?

No.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

Alexander Nusov
Cool, many thanks!



--

Alex


---- On Wed, 25 Jan 2017 14:50:51 +0300 Roger Pau Monné &lt;[hidden email]&gt; wrote ----




On Wed, Jan 25, 2017 at 02:20:55PM +0300, Alexander Nusov wrote:

&gt; Got it, thanks.

&gt;

&gt;

&gt;

&gt; I found a workaround to avoid XENBUS delay in Linux DomUs by adding xen_platform_pci = 0 to the configuration file.

&gt;

&gt; So FreeBSD 11.0 Dom0 can boot Linux guests and Windows Server (FreeBSD DomU still stuck on xenbusb_nop_confighook_cb) from QCOW2 images (also works with QCOW2 overlay images)

&gt;

 

On FreeBSD you can boot with QCOW2 by not setting "xen_platform_pci = 0" on the

guest config file and adding "hw.xen.disable_pv_disks=1" to the

/boot/loader.conf file of the guest. This will prevent FreeBSD from using the

PV disk, but you will still get the PV network interfaces.

 

&gt;

&gt; Can you tell me please what is the disadvantage of not using /dev/xen/vbd devices and drivers in guests? like slow I/O?

 

Slow IO only.

 

&gt; May it lead to data corruption?

 

No.






_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

Akshay Jaggi-2
[-Alex]

Hi Roger,

Did this get solved with the change you submitted to Xen?

On 25 January 2017 at 11:58, Alexander Nusov <[hidden email]
> wrote:

> Cool, many thanks!
>
> --
> Alex
>
> ---- On Wed, 25 Jan 2017 14:50:51 +0300 *Roger Pau Monné
> <[hidden email] <[hidden email]>>* wrote ----
>
> On Wed, Jan 25, 2017 at 02:20:55PM +0300, Alexander Nusov wrote:
> > Got it, thanks.
> >
> >
> >
> > I found a workaround to avoid XENBUS delay in Linux DomUs by adding
> xen_platform_pci = 0 to the configuration file.
> >
> > So FreeBSD 11.0 Dom0 can boot Linux guests and Windows Server (FreeBSD
> DomU still stuck on xenbusb_nop_confighook_cb) from QCOW2 images (also
> works with QCOW2 overlay images)
> >
>
> On FreeBSD you can boot with QCOW2 by not setting "xen_platform_pci = 0"
> on the
> guest config file and adding "hw.xen.disable_pv_disks=1" to the
> /boot/loader.conf file of the guest. This will prevent FreeBSD from using
> the
> PV disk, but you will still get the PV network interfaces.
>
> >
> > Can you tell me please what is the disadvantage of not using
> /dev/xen/vbd devices and drivers in guests? like slow I/O?
>
> Slow IO only.
>
> > May it lead to data corruption?
>
> No.
>
>
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

Roger Pau Monné
On Thu, Feb 02, 2017 at 11:37:02PM +0000, Akshay Jaggi wrote:
> [-Alex]
>
> Hi Roger,
>
> Did this get solved with the change you submitted to Xen?

This issue is cased by a bug in the VM subsystem, kib is currently looking into
it, and patches will be committed soon hopefully. The Xen patch I've sent is
the FreeBSD handlers for the gnttab lib, with that everything is already
upstream :). I will backport the Xen patch to your Xen package once the VM
issue is solved.

Thanks, Roger.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

Alexander Nusov
Hi!

Please notify me when the issue will be fixed so I could start backporting patches to 11.0 to test qcow backend.

---- On Fri, 03 Feb 2017 13:14:02 +0300 [hidden email] wrote ----

On Thu, Feb 02, 2017 at 11:37:02PM +0000, Akshay Jaggi wrote:
> [-Alex]
>
> Hi Roger,
>
> Did this get solved with the change you submitted to Xen?

This issue is cased by a bug in the VM subsystem, kib is currently looking into
it, and patches will be committed soon hopefully. The Xen patch I've sent is
the FreeBSD handlers for the gnttab lib, with that everything is already
upstream :). I will backport the Xen patch to your Xen package once the VM
issue is solved.

Thanks, Roger.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen 
To unsubscribe, send any mail to "[hidden email]"
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

Alexander Nusov
Hi,
Sorry for top posting.

Any update on the issue?
Please let me know if I need open a bug in Bugzilla.

--
alex

---- On Mon, 13 Feb 2017 06:39:16 -0800 [hidden email] wrote ----

Hi!

Please notify me when the issue will be fixed so I could start backporting patches to 11.0 to test qcow backend.


---- On Fri, 03 Feb 2017 13:14:02 +0300 [hidden email] wrote ----

On Thu, Feb 02, 2017 at 11:37:02PM +0000, Akshay Jaggi wrote:
> [-Alex]
>
> Hi Roger,
>
> Did this get solved with the change you submitted to Xen?

This issue is cased by a bug in the VM subsystem, kib is currently looking into
it, and patches will be committed soon hopefully. The Xen patch I've sent is
the FreeBSD handlers for the gnttab lib, with that everything is already
upstream :). I will backport the Xen patch to your Xen package once the VM
issue is solved.

Thanks, Roger.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen 
To unsubscribe, send any mail to "[hidden email]"
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

Roger Pau Monné
On Mon, Feb 27, 2017 at 06:30:12PM +0300, Alexander Nusov wrote:
> Hi,
> Sorry for top posting.
>
> Any update on the issue?
> Please let me know if I need open a bug in Bugzilla.

Sadly it seems like there are still some loose ends on the VM subsystem. I hope
those will be fixed soon. Have you tried with HEAD recently?

Roger.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

Alexander Nusov
Not yet,
I’ll try the HEAD this week.


alex


> On Feb 27, 2017, at 6:34 PM, Roger Pau Monné <[hidden email]> wrote:
>
> On Mon, Feb 27, 2017 at 06:30:12PM +0300, Alexander Nusov wrote:
>> Hi,
>> Sorry for top posting.
>>
>> Any update on the issue?
>> Please let me know if I need open a bug in Bugzilla.
>
> Sadly it seems like there are still some loose ends on the VM subsystem. I hope
> those will be fixed soon. Have you tried with HEAD recently?
>
> Roger.


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

Alexander Nusov
Hello,

tried booting from qcow2 on FreeBSD 11.1-RELEASE, the issue still exists.



--

thanks,

alex




---- On Mon, 27 Feb 2017 18:45:38 +0300 Alexander Nusov &lt;[hidden email]&gt; wrote ----




Not yet,

I’ll try the HEAD this week.





alex





&gt; On Feb 27, 2017, at 6:34 PM, Roger Pau Monné &lt;[hidden email]&gt; wrote:

&gt;

&gt; On Mon, Feb 27, 2017 at 06:30:12PM +0300, Alexander Nusov wrote:

&gt;&gt; Hi,

&gt;&gt; Sorry for top posting.

&gt;&gt;

&gt;&gt; Any update on the issue?

&gt;&gt; Please let me know if I need open a bug in Bugzilla.

&gt;

&gt; Sadly it seems like there are still some loose ends on the VM subsystem. I hope

&gt; those will be fixed soon. Have you tried with HEAD recently?

&gt;

&gt; Roger.





_______________________________________________

[hidden email] mailing list

https://lists.freebsd.org/mailman/listinfo/freebsd-xen

To unsubscribe, send any mail to "[hidden email]"






_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

Roger Pau Monné
On Tue, Aug 08, 2017 at 07:55:16PM +0300, Alexander Nusov wrote:
> Hello,
>
> tried booting from qcow2 on FreeBSD 11.1-RELEASE, the issue still exists.

Hm, great. Now it's too late to fix 11.1 :(. Have you tried with HEAD?

Thanks, Roger.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "[hidden email]"