Cisco NX-OSv 9k crashes during boot with qemu 2.10.1(Debian 1:2.10.0+dfsg-2) and ovmf 0~20161202.7bbe0b3e-1

[jean-christophe manciot]

Ubuntu 17.04
qemu 2.10.1(Debian 1:2.10.0+dfsg-2)
gns3 2.0.3
NX-OSv 9k 7.0.3.I6.1

- No such issue with previous qemu 2.8.x
- the issue does not seem to come from the debian packaging
- the issue does not seem to come from GNS3 either, as confirmed by Jeremy Grossmann at https://github.com/GNS3/gns3-server/issues/1193#issuecomment-344240460

Either some parameters usage have changed (for instance -bios) (which would make qemu not backwards compatible) or there is an issue with qemu itself.
The configuration parameters are:
```
                "compute_id": "local",
                "console": 2010,
                "console_type": "telnet",
                "first_port_name": "mgmt0",
                "height": 48,
                "label": {
                    "rotation": 0,
                    "style": "font-family: TypeWriter;font-size: 10.0;font-weight: bold;fill: #000000;fill-opacity: 1.0;",
                    "text": "NX_OSv_9k_Spine_31",
                    "x": -54,
                    "y": -25
                },
                "name": "NX_OSv_9k_Spine_31",
                "node_id": "8d01119a-0adc-41bc-950b-c5639db7708c",
                "node_type": "qemu",
                "port_name_format": "Ethernet1/{port1}",
                "port_segment_size": 0,
                "properties": {
                    "acpi_shutdown": false,
                    "adapter_type": "e1000",
                    "adapters": 10,
                    "bios_image": "",
                    "bios_image_md5sum": null,
                    "boot_priority": "c",
                    "cdrom_image": "",
                    "cdrom_image_md5sum": null,
                    "cpu_throttling": 0,
                    "cpus": 2,
                    "hda_disk_image": "NX-OSv-9k-7.0.3.I6.1.free.qcow2",
                    "hda_disk_image_md5sum": "18bb991b814a508d1190575f99deed99",
                    "hda_disk_interface": "ide",
                    "hdb_disk_image": "",
                    "hdb_disk_image_md5sum": null,
                    "hdb_disk_interface": "ide",
                    "hdc_disk_image": "",
                    "hdc_disk_image_md5sum": null,
                    "hdc_disk_interface": "ide",
                    "hdd_disk_image": "",
                    "hdd_disk_image_md5sum": null,
                    "hdd_disk_interface": "ide",
                    "initrd": "",
                    "initrd_md5sum": null,
                    "kernel_command_line": "",
                    "kernel_image": "",
                    "kernel_image_md5sum": null,
                    "legacy_networking": false,
                    "mac_address": "00:07:00:03:16:01",
                    "options": "-nographic -enable-kvm -cpu host -machine q35 -smp cpus=2 -bios /usr/share/ovmf/OVMF.fd",
                    "platform": "x86_64",
                    "process_priority": "normal",
                    "qemu_path": "/usr/bin/qemu-system-x86_64",
                    "ram": 6144,
                    "usage": ""
```

The logs are:
- [execution log](https://github.com/GNS3/gns3-server/files/1381651/qemu.log.txt)
- [terminal log](https://github.com/GNS3/gns3-server/files/1381660/terminal.log.txt)

With the latest qemu, I can boot:
- Cisco IOSv 15.6(2)T
- Cisco IOSv-L2 15.2(20170321:233949)
- Cisco CSR 1000v 16.5.1b
- Cisco ASAv 9.6(2)

The major difference with NX-OSv 9k is the bios parameter: ```-bios /usr/share/ovmf/OVMF.fd```:
```
ll /usr/share/ovmf/OVMF.fd
-rw-r--r-- 1 root root 2097152 Dec 9 2016 /usr/share/ovmf/OVMF.fd
```
A normal boot log with qemu 2.8.1 is available [here](https://github.com/GNS3/gns3-server/files/1381729/terminal.log.2.8.txt)

Highlighting the differences: qemu 2.8.1 on the left, qemu 2.10.1 on the right hand side with the same boot parameters

[jean-christophe manciot (manciot-jeanchristophe)]

Actually, this issue is solved with a fresher ovmf package than the one shipped by default with Ubuntu 17.04 (0~20161202.7bbe0b3e-1).

This issue should be closed.

[Thomas Huth (th-huth)]

Closing, according to the previous comment.