Issue getting my first Xen domU up

[Eric Bautsch]

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]

[Roger Pau Monné]

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]"

[Eric Bautsch]

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]

[Marcin Cieslak-3]

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

[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.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "[hidden email]"

[Rodney W. Grimes-4]

> 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]"

[Benedict Reuschling-2]

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.
>

I could make those change, but not today as we are recording BSDNow.tv.
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

[Andrew Daugherity-3]

> 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]"

[Roger Pau Monné]

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]"

[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.

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

[Rodney W. Grimes-4]

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

[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.

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]"