Re: [Xen-users] Xen 4.11 Hypervisor does not start HVM

[Kun Cheng <chengkunck@xxxxxxxxx>]

Joao Henrique da Silva < 000jhs@xxxxxxxxx> 于2019年9月11日周三 下午10:24写道：

No, it's not. Thanks for the attention.

I've tried to comment the following lines:

#bootloader='pygrub'

#device_model_override='/usr/lib/xen-4.11/bin/qemu-system-x86_64'

 

Just to reduce the noise. 

Maybe you can also comment 'kernel' and 'ramdisk' lines as they are for direct kernel boot, which may conflict with the kernel in your iso file. 

And the configuration file still led me to the same error. I cannot confirm the pv issue you asked but your affirmations both seem right. I think it has something to do with the NetworkManager (vif21.0-emu) part.

One dumb question: you do have xenbr0 configured correctly (seems that you are using libvirt to manage the bridge), and you have no problems creating a pv domain with that bridge, right?

Then, can you try: xl -vvv create -c YOU_HVM_CONFIG_FILE

And check anything suspicious?

 

Em qua, 11 de set de 2019 às 06:19, Kun Cheng < chengkunck@xxxxxxxxx> escreveu:

Hello

Joao Henrique da Silva < 000jhs@xxxxxxxxx> 于2019年9月11日周三 上午11:55写道：

as posted in https://serverfault.com/questions/981521/xen-4-11-hypervisor-does-not-start-hvm

i'm having this problem to start any xen HMV on my debian server:

    root@server /h/l/Documentos# xl create vm.cfg

    Parsing config from vm.cfg

    libxl: error: libxl_dm.c:2427:device_model_spawn_outcome: Domain 20:domain 20 device model: spawn failed (rc=-3)

    libxl: error: libxl_create.c:1563:domcreate_devmodel_started: Domain 20:device model did not start: -3

    libxl: error: libxl_dm.c:2541:kill_device_model: Device Model already exited

    libxl: error: libxl_domain.c:1034:libxl__destroy_domid: Domain 20:Non-existant domain

    libxl: error: libxl_domain.c:993:domain_destroy_callback: Domain 20:Unable to destroy guest

    libxl: error: libxl_domain.c:920:domain_destroy_cb: Domain 20:Destruction of domain failed

In the logs appear:

    01/09/2019 21:15 server09 /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/20/768

    01/09/2019 21:15 server09 /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/21/768

    01/09/2019 21:15 server09 /etc/xen/scripts/block: Writing backend/vbd/21/768/physical-device fe:9 to xenstore.

    01/09/2019 21:15 server09 /etc/xen/scripts/block: Writing backend/vbd/21/768/physical-device-path /dev/dm-9 to xenstore.

    01/09/2019 21:15 server09 /etc/xen/scripts/block: Writing backend/vbd/21/768/hotplug-status connected to xenstore.

    01/09/2019 21:15 systemd-udevd Using default interface naming scheme 'v240'.

    01/09/2019 21:15 NetworkManager <info>  [1567383358.5189] manager: (vif21.0-emu): new Tun device (/org/freedesktop/NetworkManager/Devices/50)

    01/09/2019 21:15 systemd-udevd link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.

    01/09/2019 21:15 systemd-udevd Could not generate persistent MAC address for vif21.0-emu: No such file or directory

    01/09/2019 21:15 server09 /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/21/768

My system is a:

    root@server:/home/server09# uname -a

    Linux server 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5+deb10u2 (2019-08-08) x86_64 GNU/Linux

    root@server:/home/server09# apt policy qemu

    qemu:

      Instalado: 1:3.1+dfsg-8~deb10u1

      Candidato: 1:3.1+dfsg-8~deb10u1

      Tabela de versão:

     *** 1:3.1+dfsg-8~deb10u1 500

            500 http://deb.debian.org/debian stable/main amd64 Packages

            100 /var/lib/dpkg/status

         1:2.8+dfsg-6+deb9u8 500

            500 http://security.debian.org stretch/updates/main amd64 Packages

            500 http://deb.debian.org/debian-security oldstable/updates/main amd64 Packages

            500 http://security.debian.org/debian-security stretch/updates/main amd64 Packages

         1:2.8+dfsg-6+deb9u5 500

            500 http://ftp.br.debian.org/debian stretch/main amd64 Packages

            500 http://deb.debian.org/debian oldstable/main amd64 Packages

            500 http://ftp.us.debian.org/debian stretch/main amd64 Packages

   

   

   

    root@server:/home/server09# apt policy libxenmisc4.11 xen-hypervisor-4.11-amd64 xen-utils-4.11

    libxenmisc4.11:

      Instalado: 4.11.1+92-g6c33308a8d-2

      Candidato: 4.11.1+92-g6c33308a8d-2

      Tabela de versão:

     *** 4.11.1+92-g6c33308a8d-2 500

            500 http://deb.debian.org/debian stable/main amd64 Packages

            100 /var/lib/dpkg/status

    xen-hypervisor-4.11-amd64:

      Instalado: 4.11.1+92-g6c33308a8d-2

      Candidato: 4.11.1+92-g6c33308a8d-2

      Tabela de versão:

     *** 4.11.1+92-g6c33308a8d-2 500

            500 http://deb.debian.org/debian stable/main amd64 Packages

            100 /var/lib/dpkg/status

    xen-utils-4.11:

      Instalado: 4.11.1+92-g6c33308a8d-2

      Candidato: 4.11.1+92-g6c33308a8d-2

      Tabela de versão:

     *** 4.11.1+92-g6c33308a8d-2 500

            500 http://deb.debian.org/debian stable/main amd64 Packages

            100 /var/lib/dpkg/status

My Xen configuration file points to:

    name='vm'

    type='hvm'

    vcpus='4'

    memory='4096'

    disk=['file:/media/STORAGE01/ISO/vm-linux-kde-2019.2-amd64.iso,hdb,cdrom,ro' , '/dev/vm01/vm,raw,hda,rw']

    boot='dc'

    _on_poweroff_='destroy'

    _on_reboot_='restart'

    bios='seabios'

    bootloader='pygrub'

I remember pygrub is for pv domains only. Can you confirm hvm domus can use that as bootloader? 

    serial='pty'

    kernel='/boot/vmlinuz-4.19.0-5-amd64'

    ramdisk='/boot/initrd.img-4.19.0-5-amd64'

    device_model_version='qemu-xen'

    device_model_override='/usr/lib/xen-4.11/bin/qemu-system-x86_64'

'device_model_override' requires xen to be built with qemu-system support. Can you confirm your installed packages have that support?

see:  https://wiki.xenproject.org/wiki/QEMU_Upstream

 

    vif=['ip=XXX.XXX.XXX.XXX','mac=XX:XX:XX:XX:XX:XX','bridge=xenbr0']

    vnc='1'

    vnclisten='XXX.XXX.XXX.XXX'

    vncdisplay='0'

I've found several threads suggesting a diversity of approaches, none of them worked.

Update: It also appers to be releated with these logs too:

    11/09/2019 00:40 server lucifer /etc/xen/scripts/block: Writing backend/vbd/24/768/physical-device fe:9 to xenstore.

    11/09/2019 00:40 server lucifer /etc/xen/scripts/block: Writing backend/vbd/24/768/physical-device-path /dev/dm-9 to xenstore.

    11/09/2019 00:40 server lucifer /etc/xen/scripts/block: Writing backend/vbd/24/768/hotplug-status connected to xenstore.

    11/09/2019 00:40 server lucifer /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/24/768

   

   

    11/09/2019 00:40 lucifer /etc/xen/scripts/block: Writing backend/vbd/24/768/physical-device fe:9 to xenstore.

    11/09/2019 00:40 lucifer /etc/xen/scripts/block: Writing backend/vbd/24/768/physical-device-path /dev/dm-9 to xenstore.

    11/09/2019 00:40 lucifer /etc/xen/scripts/block: Writing backend/vbd/24/768/hotplug-status connected to xenstore.

    11/09/2019 00:40 lucifer /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/24/768

And this very suspicious:

    10/09/2019 22:45 xen en_evtchn: Event-channel device installed

    10/09/2019 22:45 xenbr0 port 1(enp6s0) entered blocking state

    10/09/2019 22:45 xenbr0 port 1(enp6s0) entered disabled state

    10/09/2019 22:45 IPv6 ADDRCONF(NETDEV_UP): xenbr0: link is not ready

    10/09/2019 22:45 xenbr0 port 1(enp6s0) entered blocking state

    10/09/2019 22:45 xenbr0 port 1(enp6s0) entered forwarding state

    10/09/2019 22:45 IPv6 ADDRCONF(NETDEV_CHANGE): xenbr0: link becomes ready

That led me to check

    root@server:/#  systemctl status -l libvirtd

    ● libvirtd.service - Virtualization daemon

       Loaded: loaded (/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled)

       Active: active (running) since Tue 2019-09-10 22:45:18 -03; 2h 3min ago

         Docs: man:libvirtd(8)

                https://libvirt.org

     Main PID: 1335 (libvirtd)

        Tasks: 18 (limit: 32768)

       Memory: 10.7M

       CGroup: /system.slice/libvirtd.service

               └─1335 /usr/sbin/libvirtd

   

    set 11 00:12:34 server libvirtd[1335]: Failed to open file '/sys/class/net/vif12.2-emu/operstate': Arquivo

    set 11 00:12:34 server libvirtd[1335]: unable to read: /sys/class/net/vif12.2-emu/operstate: Arquivo ou di

    set 11 00:13:56 server libvirtd[1335]: ethtool ioctl error: Dispositivo inexistente

    set 11 00:13:56 server libvirtd[1335]: ethtool ioctl error: Dispositivo inexistente

    set 11 00:13:56 server libvirtd[1335]: ethtool ioctl error: Dispositivo inexistente

    set 11 00:13:56 server libvirtd[1335]: ethtool ioctl error: Dispositivo inexistente

    set 11 00:13:56 server libvirtd[1335]: ethtool ioctl error: Dispositivo inexistente

    set 11 00:13:56 server libvirtd[1335]: ethtool ioctl error: Dispositivo inexistente

    set 11 00:13:56 server libvirtd[1335]: ethtool ioctl error: Dispositivo inexistente

    set 11 00:13:56 server libvirtd[1335]: ethtool ioctl error: Dispositivo inexistente

    lines 1-21/21 (END)

And hat makes me think that there is something wrong with the NIC device or its module; the bridge seems ok:

    root@server:/# brctl show

    bridge name bridge id STP enabled interfaces

    xenbr0 8000.e0d55ef46d39 no enp6s0

any ideas?

_______________________________________________

Xen-users mailing list

Xen-users@xxxxxxxxxxxxxxxxxxxx

https://lists.xenproject.org/mailman/listinfo/xen-users

Regards,

Kun

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-users