Hi.
I'm trying to get a Xen domU up and running. I'm running FreeBSD 12.0. System is a new install. I'm following the instructions here: https://www.freebsd.org/doc/handbook/virtualization-host-xen.html My config file looks thus: builder = "hvm" name = "titania" memory = 8192 vcpus = 2 vif = [ 'mac=00:16:3E:11:11:21,bridge=bridge0' ] disk = [ '/dev/zvol/zroot/titania0,raw,hda,rw' ] vnc = 1 vnclisten = "0.0.0.0" serial = "pty" Upon trying to create the domU, I think it's trying to tell me that it's got issues with the storage, but that may be a red herring as the qemu command seems to include the storage. Nevertheless, I have also tried with sda and messed around with qcow2 (that one didn't work, but probably due to my wrong incantation). Anyway here's the output from the above config file. Any help would be greatly appreciated. Thanks. Eric root@bianca:/export/vm # xl -vvvv create /export/vm/titania.cfg Parsing config from /export/vm/titania.cfg libxl: debug: libxl_create.c:1670:do_domain_create: Domain 0:ao 0x8008eb0a0: create: how=0x0 callback=0x0 poller=0x8008e50a0 libxl: debug: libxl_device.c:397:libxl__device_disk_set_backend: Disk vdev=hda spec.backend=unknown libxl: debug: libxl_device.c:432:libxl__device_disk_set_backend: Disk vdev=hda, using backend phy libxl: debug: libxl_create.c:1007:initiate_domain_create: Domain 3:running bootloader libxl: debug: libxl_bootloader.c:328:libxl__bootloader_run: Domain 3:not a PV/PVH domain, skipping bootloader libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0x800915b70: deregister unregistered domainbuilder: detail: xc_dom_allocate: cmdline="", features="" domainbuilder: detail: xc_dom_kernel_file: filename="/usr/local/lib/xen/boot/hvmloader" domainbuilder: detail: xc_dom_malloc_filemap : 176 kB libxl: debug: libxl_dom.c:970:libxl__load_hvm_firmware_module: Loading BIOS: /usr/local/share/seabios/bios.bin domainbuilder: detail: xc_dom_boot_xen_init: ver 4.11, 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 multiboot-binary loader ... domainbuilder: detail: loader probe failed domainbuilder: detail: xc_dom_find_loader: trying HVM-generic loader ... domainbuilder: detail: loader probe OK xc: detail: ELF: phdr: paddr=0x100000 memsz=0x337e8 xc: detail: ELF: memory: 0x100000 -> 0x1337e8 domainbuilder: detail: xc_dom_mem_init: mem 8184 MB, pages 0x1ff800 pages, 4k each domainbuilder: detail: xc_dom_mem_init: 0x1ff800 pages domainbuilder: detail: xc_dom_boot_mem_init: called domainbuilder: detail: range: start=0x0 end=0xf0000000 domainbuilder: detail: range: start=0x100000000 end=0x20f800000 domainbuilder: detail: xc_dom_malloc : 16880 kB xc: detail: PHYSICAL MEMORY ALLOCATION: xc: detail: 4KB PAGES: 0x0000000000000200 xc: detail: 2MB PAGES: 0x00000000000003fb xc: detail: 1GB PAGES: 0x0000000000000006 domainbuilder: detail: xc_dom_build_image: called domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x100+0x34 at 0x8009c6000 domainbuilder: detail: xc_dom_alloc_segment: kernel : 0x100000 -> 0x134000 (pfn 0x100 + 0x34 pages) xc: detail: ELF: phdr 0 at 0x802401000 -> 0x80242ad7c domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x134+0x40 at 0x802401000 domainbuilder: detail: xc_dom_alloc_segment: System Firmware module : 0x134000 -> 0x174000 (pfn 0x134 + 0x40 pages) domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x174+0x1 at 0x8009fa000 domainbuilder: detail: xc_dom_alloc_segment: HVM start info : 0x174000 -> 0x175000 (pfn 0x174 + 0x1 pages) domainbuilder: detail: alloc_pgtables_hvm: doing nothing domainbuilder: detail: xc_dom_build_image : virt_alloc_end : 0x175000 domainbuilder: detail: xc_dom_build_image : virt_pgtab_end : 0x0 domainbuilder: detail: xc_dom_boot_image: called 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: domain builder memory footprint domainbuilder: detail: allocated domainbuilder: detail: malloc : 16885 kB domainbuilder: detail: anon mmap : 0 bytes domainbuilder: detail: mapped domainbuilder: detail: file mmap : 176 kB domainbuilder: detail: domU mmap : 468 kB domainbuilder: detail: vcpu_hvm: called domainbuilder: detail: xc_dom_gnttab_hvm_seed: called, pfn=0x20f800 domainbuilder: detail: xc_dom_gnttab_hvm_seed: called, pfn=0x20f801 domainbuilder: detail: xc_dom_release: called libxl: debug: libxl_device.c:397:libxl__device_disk_set_backend: Disk vdev=hda spec.backend=phy libxl: debug: libxl_event.c:636:libxl__ev_xswatch_register: watch w=0x8009c23d0 wpath=/local/domain/0/backend/vbd/3/768/state token=3/0: register slotnum=3 libxl: debug: libxl_create.c:1707:do_domain_create: Domain 0:ao 0x8008eb0a0: inprogress: poller=0x8008e50a0, flags=i libxl: debug: libxl_event.c:573:watchfd_callback: watch w=0x8009c23d0 wpath=/local/domain/0/backend/vbd/3/768/state token=3/0: event epath=/local/domain/0/backend/vbd/3/768/state libxl: debug: libxl_event.c:878:devstate_callback: backend /local/domain/0/backend/vbd/3/768/state wanted state 2 still waiting state 1 libxl: debug: libxl_event.c:573:watchfd_callback: watch w=0x8009c23d0 wpath=/local/domain/0/backend/vbd/3/768/state token=3/0: event epath=/local/domain/0/backend/vbd/3/768/state libxl: debug: libxl_event.c:874:devstate_callback: backend /local/domain/0/backend/vbd/3/768/state wanted state 2 ok libxl: debug: libxl_event.c:673:libxl__ev_xswatch_deregister: watch w=0x8009c23d0 wpath=/local/domain/0/backend/vbd/3/768/state token=3/0: deregister slotnum=3 libxl: debug: libxl_device.c:1117:device_backend_callback: Domain 3:calling device_backend_cleanup libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0x8009c23d0: deregister unregistered libxl: debug: libxl_device.c:1218:device_hotplug: Domain 3:calling hotplug script: /usr/local/etc/xen/scripts/block /local/domain/0/backend/vbd/3/768 libxl: debug: libxl_device.c:1219:device_hotplug: Domain 3:extra args: libxl: debug: libxl_device.c:1225:device_hotplug: Domain 3: add libxl: debug: libxl_device.c:1227:device_hotplug: Domain 3:env: libxl: debug: libxl_aoutils.c:593:libxl__async_exec_start: forking to execute: /usr/local/etc/xen/scripts/block /local/domain/0/backend/vbd/3/768 libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0x8009c24d0: deregister unregistered libxl: debug: libxl_device.c:1203:device_hotplug: Domain 3:No hotplug script to execute libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0x8009c24d0: deregister unregistered libxl: debug: libxl_disk.c:918:libxl__device_disk_find_local_path: Directly accessing local RAW disk /dev/zvol/zroot/titania0 libxl: debug: libxl_dm.c:1656:libxl__build_device_model_args_new: Domain 3:dm_restrict disabled, starting QEMU as root libxl: debug: libxl_dm.c:2331:libxl__spawn_local_dm: Domain 3:Spawning device-model /usr/local/lib/xen/bin/qemu-system-i386 with arguments: libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: /usr/local/lib/xen/bin/qemu-system-i386 libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: -xen-domid libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: 3 libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: -chardev libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-3,server,nowait libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: -no-shutdown libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: -mon libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: chardev=libxl-cmd,mode=control libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: -chardev libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: socket,id=libxenstat-cmd,path=/var/run/xen/qmp-libxenstat-3,server,nowait libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: -mon libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: chardev=libxenstat-cmd,mode=control libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: -nodefaults libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: -no-user-config libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: -name libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: titania libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: -vnc libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: 0.0.0.0:0,to=99 libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: -display libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: none libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: -serial libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: pty libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: -device libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: cirrus-vga,vgamem_mb=8 libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: -boot libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: order=cda libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: -smp libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: 2,maxcpus=2 libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: -device libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: rtl8139,id=nic0,netdev=net0,mac=00:16:3e:11:11:21 libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: -netdev libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: type=tap,id=net0,ifname=xnb3.0-emu,script=no,downscript=no libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: -machine libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: xenfv libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: -m libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: 8184 libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: -drive libxl: debug: libxl_dm.c:2333:libxl__spawn_local_dm: Domain 3: file=/dev/zvol/zroot/titania0,if=ide,index=0,media=disk,format=raw,cache=writeback libxl: debug: libxl_dm.c:2335:libxl__spawn_local_dm: Domain 3:Spawning device-model /usr/local/lib/xen/bin/qemu-system-i386 with additional environment: libxl: debug: libxl_dm.c:2337:libxl__spawn_local_dm: Domain 3: XEN_QEMU_CONSOLE_LIMIT=1048576 libxl: debug: libxl_event.c:636:libxl__ev_xswatch_register: watch w=0x800915e68 wpath=/local/domain/0/device-model/3/state token=3/1: register slotnum=3 libxl: debug: libxl_event.c:573:watchfd_callback: watch w=0x800915e68 wpath=/local/domain/0/device-model/3/state token=3/1: 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:673:libxl__ev_xswatch_deregister: watch w=0x800915e68 wpath=/local/domain/0/device-model/3/state token=3/1: deregister slotnum=3 libxl: error: libxl_dm.c:2427:device_model_spawn_outcome: Domain 3:domain 3 device model: spawn failed (rc=-3) libxl: error: libxl_create.c:1562:domcreate_devmodel_started: Domain 3:device model did not start: -3 libxl: error: libxl_dm.c:2541:kill_device_model: Device Model already exited libxl: debug: libxl_event.c:636:libxl__ev_xswatch_register: watch w=0x8009c29d0 wpath=/local/domain/0/backend/vbd/3/768/state token=3/2: register slotnum=3 libxl: debug: libxl_event.c:573:watchfd_callback: watch w=0x8009c29d0 wpath=/local/domain/0/backend/vbd/3/768/state token=3/2: event epath=/local/domain/0/backend/vbd/3/768/state libxl: debug: libxl_event.c:874:devstate_callback: backend /local/domain/0/backend/vbd/3/768/state wanted state 6 ok libxl: debug: libxl_event.c:673:libxl__ev_xswatch_deregister: watch w=0x8009c29d0 wpath=/local/domain/0/backend/vbd/3/768/state token=3/2: deregister slotnum=3 libxl: debug: libxl_device.c:1117:device_backend_callback: Domain 3:calling device_backend_cleanup libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0x8009c29d0: deregister unregistered libxl: debug: libxl_device.c:1218:device_hotplug: Domain 3:calling hotplug script: /usr/local/etc/xen/scripts/block /local/domain/0/backend/vbd/3/768 libxl: debug: libxl_device.c:1219:device_hotplug: Domain 3:extra args: libxl: debug: libxl_device.c:1225:device_hotplug: Domain 3: remove libxl: debug: libxl_device.c:1227:device_hotplug: Domain 3:env: libxl: debug: libxl_aoutils.c:593:libxl__async_exec_start: forking to execute: /usr/local/etc/xen/scripts/block /local/domain/0/backend/vbd/3/768 libxl: debug: libxl_event.c:542:watchfd_callback: watch epath=/local/domain/0/backend/vbd/3/768/state token=3/2: empty slot libxl: debug: libxl_event.c:542:watchfd_callback: watch epath=/local/domain/0/backend/vbd/3/768/state token=3/2: empty slot libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0x8009c2ad0: deregister unregistered libxl: debug: libxl_device.c:1203:device_hotplug: Domain 3:No hotplug script to execute libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0x8009c2ad0: deregister unregistered libxl: debug: libxl_device.c:1203:device_hotplug: Domain 3:No hotplug script to execute libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0x8009c2dd0: deregister unregistered libxl: debug: libxl_domain.c:1172:devices_destroy_cb: Domain 3:Forked pid 1427 for destroy of domain libxl: debug: libxl_event.c:1869:libxl__ao_complete: ao 0x8008eb0a0: complete, rc=-3 libxl: debug: libxl_event.c:1838:libxl__ao__destroy: ao 0x8008eb0a0: destroy libxl: debug: libxl_domain.c:902:libxl_domain_destroy: Domain 3:ao 0x8008eb0a0: create: how=0x0 callback=0x0 poller=0x8008e50a0 libxl: error: libxl_domain.c:1034:libxl__destroy_domid: Domain 3:Non-existant domain libxl: error: libxl_domain.c:993:domain_destroy_callback: Domain 3:Unable to destroy guest libxl: error: libxl_domain.c:920:domain_destroy_cb: Domain 3:Destruction of domain failed libxl: debug: libxl_event.c:1869:libxl__ao_complete: ao 0x8008eb0a0: complete, rc=-21 libxl: debug: libxl_domain.c:911:libxl_domain_destroy: Domain 3:ao 0x8008eb0a0: inprogress: poller=0x8008e50a0, flags=ic libxl: debug: libxl_event.c:1838:libxl__ao__destroy: ao 0x8008eb0a0: destroy xencall:buffer: debug: total allocations:691 total releases:691 xencall:buffer: debug: current allocations:0 maximum allocations:3 xencall:buffer: debug: cache current size:3 xencall:buffer: debug: cache hits:674 misses:3 toobig:14 xencall:buffer: debug: total allocations:0 total releases:0 xencall:buffer: debug: current allocations:0 maximum allocations:0 xencall:buffer: debug: cache current size:0 xencall:buffer: debug: cache hits:0 misses:0 toobig:0 root@bianca:/export/vm # -- ____ / . Eric A. Bautsch /-- __ ___ ______________________________________ / / / / / (_____/____(___(__________________/ email: [hidden email] |
On Tue, Feb 05, 2019 at 07:17:55AM +0000, Eric Bautsch wrote:
> Hi. > > > I'm trying to get a Xen domU up and running. > > I'm running FreeBSD 12.0. System is a new install. > > > I'm following the instructions here: > > https://www.freebsd.org/doc/handbook/virtualization-host-xen.html > > > My config file looks thus: > > builder = "hvm" > name = "titania" > memory = 8192 > vcpus = 2 > vif = [ 'mac=00:16:3E:11:11:21,bridge=bridge0' ] > disk = [ '/dev/zvol/zroot/titania0,raw,hda,rw' ] > vnc = 1 > vnclisten = "0.0.0.0" > serial = "pty" That seems like a valid configuration. > Upon trying to create the domU, I think it's trying to tell me that it's got > issues with the storage, but that may be a red herring as the qemu command > seems to include the storage. Nevertheless, I have also tried with sda and > messed around with qcow2 (that one didn't work, but probably due to my wrong > incantation). Anyway here's the output from the above config file. It's indeed QEMU failing the start the problem here. Do you have the if_tap module loaded (`kldload if_tap`)? Can you provide the QEMU log, it should be in /var/log/xen/qemu-dm-titania.log. Thanks, Roger. _______________________________________________ [hidden email] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "[hidden email]" |
Hi Roger.
Thanks for that. Yes, tap not being there was the issue..... And yes, the qemu-dm-titania.log would have been the place to look. I feel pretty stupid. It says: qemu-system-i386: -netdev type=tap,id=net0,ifname=xnb3.0-emu,script=no,downscript=no: could not open /dev/tap: No such file or directory Got it running now. Very much appreciated. Eric On 05/02/2019 14:09, Roger Pau Monné wrote: > On Tue, Feb 05, 2019 at 07:17:55AM +0000, Eric Bautsch wrote: >> Hi. >> >> >> I'm trying to get a Xen domU up and running. >> >> I'm running FreeBSD 12.0. System is a new install. >> >> >> I'm following the instructions here: >> >> https://www.freebsd.org/doc/handbook/virtualization-host-xen.html >> >> >> My config file looks thus: >> >> builder = "hvm" >> name = "titania" >> memory = 8192 >> vcpus = 2 >> vif = [ 'mac=00:16:3E:11:11:21,bridge=bridge0' ] >> disk = [ '/dev/zvol/zroot/titania0,raw,hda,rw' ] >> vnc = 1 >> vnclisten = "0.0.0.0" >> serial = "pty" > That seems like a valid configuration. > >> Upon trying to create the domU, I think it's trying to tell me that it's got >> issues with the storage, but that may be a red herring as the qemu command >> seems to include the storage. Nevertheless, I have also tried with sda and >> messed around with qcow2 (that one didn't work, but probably due to my wrong >> incantation). Anyway here's the output from the above config file. > It's indeed QEMU failing the start the problem here. Do you have the > if_tap module loaded (`kldload if_tap`)? > > Can you provide the QEMU log, it should be in > /var/log/xen/qemu-dm-titania.log. > > Thanks, Roger. > ____ / . Eric A. Bautsch /-- __ ___ ______________________________________ / / / / / (_____/____(___(__________________/ email: [hidden email] |
On Tue, 5 Feb 2019, Eric Bautsch wrote:
> And yes, the qemu-dm-titania.log would have been the place to look. I feel > pretty stupid. It says: Don't feel stupid. I am using Xen with Dom0 on FreeBSD for months now and I didn't know where the qemu logs go - I was able to figure out the problem by staring at the configuration file for a long time. Therefore your question was very helpful also for me - thanks! Marcin |
Adding Benedict who wrote the Xen handbook documentation, and
hopefully would be able to fix it :). On Tue, Feb 05, 2019 at 08:18:05PM +0000, Marcin Cieslak wrote: > On Tue, 5 Feb 2019, Eric Bautsch wrote: > > > And yes, the qemu-dm-titania.log would have been the place to look. I feel > > pretty stupid. It says: > > Don't feel stupid. I am using Xen with Dom0 on FreeBSD for months now > and I didn't know where the qemu logs go - I was able to figure out > the problem by staring at the configuration file for a long time. > > Therefore your question was very helpful also for me - thanks! It seems there's one piece missing in the handbook which I didn't realize, the if_tap module needs to be loaded for QEMU to work. I suggest the following is added to the handbook: ``` sysrc -f /boot/loader.conf if_tap_load="YES" ``` And then I've also realized the following line: ``` sysrc -f /boot/loader.conf hw.pci.mcfg=0 ``` Is only needed for Xen 4.7, but not for Xen 4.11. Finally it might be interesting to add a reference to the location of the Xen logs. This should likely be added at the end of the document, I think something along the lines of: ``` Xen toolstack related logs can be found at /var/log/xen/ be sure to check the contents of that directory if experiencing issues. ``` Sorry to bother you Benedict, but do you think you could make the following changes? Thanks, Roger. _______________________________________________ [hidden email] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "[hidden email]" |
> Adding Benedict who wrote the Xen handbook documentation, and
> hopefully would be able to fix it :). > > On Tue, Feb 05, 2019 at 08:18:05PM +0000, Marcin Cieslak wrote: > > On Tue, 5 Feb 2019, Eric Bautsch wrote: > > > > > And yes, the qemu-dm-titania.log would have been the place to look. I feel > > > pretty stupid. It says: > > > > Don't feel stupid. I am using Xen with Dom0 on FreeBSD for months now > > and I didn't know where the qemu logs go - I was able to figure out > > the problem by staring at the configuration file for a long time. > > > > Therefore your question was very helpful also for me - thanks! > > It seems there's one piece missing in the handbook which I didn't > realize, the if_tap module needs to be loaded for QEMU to work. > > I suggest the following is added to the handbook: > > ``` > sysrc -f /boot/loader.conf if_tap_load="YES" > ``` > > And then I've also realized the following line: > > ``` > sysrc -f /boot/loader.conf hw.pci.mcfg=0 > ``` > > Is only needed for Xen 4.7, but not for Xen 4.11. > > Finally it might be interesting to add a reference to the location of > the Xen logs. This should likely be added at the end of the document, > I think something along the lines of: > > ``` > Xen toolstack related logs can be found at /var/log/xen/ be sure to > check the contents of that directory if experiencing issues. > ``` Is there a troubleshooting section in the handbook? If not there should be, and this would defanitly be mentioned in that section. > > Sorry to bother you Benedict, but do you think you could make the > following changes? > > Thanks, Roger. -- Rod Grimes [hidden email] _______________________________________________ [hidden email] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "[hidden email]" |
In reply to this post by Roger Pau Monné
Hello Roger,
Am 06.02.19 um 18:17 schrieb Roger Pau Monné: > Adding Benedict who wrote the Xen handbook documentation, and > hopefully would be able to fix it :). > > On Tue, Feb 05, 2019 at 08:18:05PM +0000, Marcin Cieslak wrote: >> On Tue, 5 Feb 2019, Eric Bautsch wrote: >> >>> And yes, the qemu-dm-titania.log would have been the place to look. I feel >>> pretty stupid. It says: >> >> Don't feel stupid. I am using Xen with Dom0 on FreeBSD for months now >> and I didn't know where the qemu logs go - I was able to figure out >> the problem by staring at the configuration file for a long time. >> >> Therefore your question was very helpful also for me - thanks! > > It seems there's one piece missing in the handbook which I didn't > realize, the if_tap module needs to be loaded for QEMU to work. > > I suggest the following is added to the handbook: > > ``` > sysrc -f /boot/loader.conf if_tap_load="YES" > ``` > > And then I've also realized the following line: > > ``` > sysrc -f /boot/loader.conf hw.pci.mcfg=0 > ``` > > Is only needed for Xen 4.7, but not for Xen 4.11. > > Finally it might be interesting to add a reference to the location of > the Xen logs. This should likely be added at the end of the document, > I think something along the lines of: > > ``` > Xen toolstack related logs can be found at /var/log/xen/ be sure to > check the contents of that directory if experiencing issues. > ``` > > Sorry to bother you Benedict, but do you think you could make the > following changes? > > Thanks, Roger. > Tomorrow is better. The changes themselves seem straightforward enough. I'll come up with a patch and add you to the review on Phabricator. Cheers, Benedict |
In reply to this post by Roger Pau Monné
> On Feb 6, 2019, at 11:17 AM, Roger Pau Monné <[hidden email]> wrote:
> > Adding Benedict who wrote the Xen handbook documentation, and > hopefully would be able to fix it :). > > I suggest the following is added to the handbook: > […] While you’re at it, I think some other updates to that handbook page are in order. I just read it again for the first time in a good while and the following things caught my eye: - 21.8.2 mentions using Xen 4.7 on FreeBSD 11 and Xen 4.11 on FreeBSD-CURRENT >= r336475. As 12.0 has been released, that merits a mention here… while "FreeBSD 12.0-RELEASE r341666 GENERIC" does have a higher rev number, I’m not sure whether or not it contains the necessary stuff for Xen 4.11. - The /var/log/xen dir is created (and owned) by the xen-tools4{7,11} packages, so no need to manually create it. - Wouldn’t 'onifpresent' be a better setting for xc0 in /etc/ttys? Then if you booted back to a vanilla kernel, it won’t try (and fail) to start a getty for a nonexistent device. - The DomU example creates a FreeBSD 10.3 VM. Probably better to showcase a supported release… - Seeing "Xen(TM)" sprinkled throughout the document interrupts the reading flow. Surely it’s enough to use the trademark symbol for the first mention and then simply "Xen" thereafter? - Is it really necessary to 'xl destroy' the DomU after shutting it down? Once it’s shut down, it shouldn’t be in the list any more, and you just 'xl create' with the new config, right? It’s nice to see Xen support in FreeBSD continue to improve! (Even if I I’ve only run it as a DomU so far…) Cheers, Andrew _______________________________________________ [hidden email] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "[hidden email]" |
On Wed, Feb 06, 2019 at 11:45:35PM +0000, Andrew Daugherity wrote:
> > On Feb 6, 2019, at 11:17 AM, Roger Pau Monné <[hidden email]> wrote: > > > > Adding Benedict who wrote the Xen handbook documentation, and > > hopefully would be able to fix it :). > > > > I suggest the following is added to the handbook: > > […] > > > > While you’re at it, I think some other updates to that handbook page are in order. I just read it again for the first time in a good while and the following things caught my eye: Thanks for the feedback! > - 21.8.2 mentions using Xen 4.7 on FreeBSD 11 and Xen 4.11 on FreeBSD-CURRENT >= r336475. As 12.0 has been released, that merits a mention here… while "FreeBSD 12.0-RELEASE r341666 GENERIC" does have a higher rev number, I’m not sure whether or not it contains the necessary stuff for Xen 4.11. FreeBSD 12.0 or FreeBSD-HEAD are all capable of using Xen 4.11. > - The /var/log/xen dir is created (and owned) by the xen-tools4{7,11} packages, so no need to manually create it. > > - Wouldn’t 'onifpresent' be a better setting for xc0 in /etc/ttys? Then if you booted back to a vanilla kernel, it won’t try (and fail) to start a getty for a nonexistent device. > > - The DomU example creates a FreeBSD 10.3 VM. Probably better to showcase a supported release… Right, let me see about this. > - Seeing "Xen(TM)" sprinkled throughout the document interrupts the reading flow. Surely it’s enough to use the trademark symbol for the first mention and then simply "Xen" thereafter? I don't have an opinion here, I don't know whether using Xen^TM is mandatory. > - Is it really necessary to 'xl destroy' the DomU after shutting it down? Once it’s shut down, it shouldn’t be in the list any more, and you just 'xl create' with the new config, right? I don't see the manual suggesting to perform an `xl shutdown ...`, am I missing something? It suggests to destroy the domain after install is finished, there's no need to perform a graceful shutdown of the installer. Thanks, Roger. _______________________________________________ [hidden email] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "[hidden email]" |
In reply to this post by Rodney W. Grimes-4
On Wed, Feb 06, 2019 at 09:39:47AM -0800, Rodney W. Grimes wrote:
> > Adding Benedict who wrote the Xen handbook documentation, and > > hopefully would be able to fix it :). > > > > On Tue, Feb 05, 2019 at 08:18:05PM +0000, Marcin Cieslak wrote: > > > On Tue, 5 Feb 2019, Eric Bautsch wrote: > > > > > > > And yes, the qemu-dm-titania.log would have been the place to look. I feel > > > > pretty stupid. It says: > > > > > > Don't feel stupid. I am using Xen with Dom0 on FreeBSD for months now > > > and I didn't know where the qemu logs go - I was able to figure out > > > the problem by staring at the configuration file for a long time. > > > > > > Therefore your question was very helpful also for me - thanks! > > > > It seems there's one piece missing in the handbook which I didn't > > realize, the if_tap module needs to be loaded for QEMU to work. > > > > I suggest the following is added to the handbook: > > > > ``` > > sysrc -f /boot/loader.conf if_tap_load="YES" > > ``` > > > > And then I've also realized the following line: > > > > ``` > > sysrc -f /boot/loader.conf hw.pci.mcfg=0 > > ``` > > > > Is only needed for Xen 4.7, but not for Xen 4.11. > > > > Finally it might be interesting to add a reference to the location of > > the Xen logs. This should likely be added at the end of the document, > > I think something along the lines of: > > > > ``` > > Xen toolstack related logs can be found at /var/log/xen/ be sure to > > check the contents of that directory if experiencing issues. > > ``` > > Is there a troubleshooting section in the handbook? > If not there should be, and this would defanitly be mentioned > in that section. There doesn't seem to be a virtualization troubleshooting section I'm afraid. I've added something similar to my suggestion above as a tip, which will make it more visible. Thanks, Roger. _______________________________________________ [hidden email] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "[hidden email]" |
In reply to this post by Roger Pau Monné
_______________________________________________
[hidden email] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "[hidden email]" |
In reply to this post by Roger Pau Monné
> On Wed, Feb 06, 2019 at 09:39:47AM -0800, Rodney W. Grimes wrote:
> > > Adding Benedict who wrote the Xen handbook documentation, and > > > hopefully would be able to fix it :). > > > > > > On Tue, Feb 05, 2019 at 08:18:05PM +0000, Marcin Cieslak wrote: > > > > On Tue, 5 Feb 2019, Eric Bautsch wrote: > > > > > > > > > And yes, the qemu-dm-titania.log would have been the place to look. I feel > > > > > pretty stupid. It says: > > > > > > > > Don't feel stupid. I am using Xen with Dom0 on FreeBSD for months now > > > > and I didn't know where the qemu logs go - I was able to figure out > > > > the problem by staring at the configuration file for a long time. > > > > > > > > Therefore your question was very helpful also for me - thanks! > > > > > > It seems there's one piece missing in the handbook which I didn't > > > realize, the if_tap module needs to be loaded for QEMU to work. > > > > > > I suggest the following is added to the handbook: > > > > > > ``` > > > sysrc -f /boot/loader.conf if_tap_load="YES" > > > ``` > > > > > > And then I've also realized the following line: > > > > > > ``` > > > sysrc -f /boot/loader.conf hw.pci.mcfg=0 > > > ``` > > > > > > Is only needed for Xen 4.7, but not for Xen 4.11. > > > > > > Finally it might be interesting to add a reference to the location of > > > the Xen logs. This should likely be added at the end of the document, > > > I think something along the lines of: > > > > > > ``` > > > Xen toolstack related logs can be found at /var/log/xen/ be sure to > > > check the contents of that directory if experiencing issues. > > > ``` > > > > Is there a troubleshooting section in the handbook? > > If not there should be, and this would defanitly be mentioned > > in that section. > > There doesn't seem to be a virtualization troubleshooting section I'm > afraid. I've added something similar to my suggestion above as a tip, > which will make it more visible. There should be a trouble shooting section within the Xen pages of the handbook, and that is where this and other things should probably be placed. How about create sections 21.8.4 Troubleshooting 21.8.4.1 host 21.8.4.2 guest and fill them in with some details. -- Rod Grimes [hidden email] _______________________________________________ [hidden email] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "[hidden email]" |
Free forum by Nabble | Edit this page |