As a developer I want to have the possibility to run RefKit in a QEMU VM and to access it with ssh.
Does this item include automatic testing under qemu?
(In reply to comment #1) > Does this item include automatic testing under qemu? I'd create a separate bug for that.
With this patch for meta-intel > diff --git a/conf/machine/include/qemuboot-intel.inc b/conf/machine/include/qemuboot-intel.inc > index 82a72ac..cb52330 100644 > --- a/conf/machine/include/qemuboot-intel.inc > +++ b/conf/machine/include/qemuboot-intel.inc > @@ -17,4 +17,3 @@ QB_AUDIO_OPT = "-soundhw ac97,es1370" > QB_KERNEL_CMDLINE_APPEND = "vga=0 uvesafb.mode_option=640x480-32 oprofile.timer=1 uvesafb.task_timeout=-1" > # Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy > QB_OPT_APPEND = "-vga vmware -show-cursor -usb -usbdevice tablet -device virtio-rng-pci" > -QB_SLIRP_OPT = "-net nic,model=e1000 -net user,hostfwd=tcp::2222-:22" I can run successfully > $ runqemu refkit-image-common ext4 intel-corei7-64 slirp (Non-slirp configuration requires a DHCP server running on host and listening on all tap interfaces) The running VM acquires its IP from qemu's built-in DHCP server. Only 2 test cases fail from testplan/refkit-image-common.manifest: - check systemd boot journal error - test_speaker_test (oeqa.runtime.alsa.alsa.AlsaTest). The first failure is caused by the hardcoded "ip=dhcp" bootparam in the runqemu script which prevents renaming eth0 to whatever pleases systemd. Hopefully this can be fixed with making runqemu not override the "bootparam=" user input. The second failure is due to unconfigured sound hardware in the VM. I'd rather exclude this test case from qemuboot test plans because 1) QEMU doesn't really emulate the hardware that our SUT is supposed to have (hdmi:CARD=PCH,DEV=0) and 2) even when modified to run `speaker-test -D front:CARD=I82801AAICH,DEV=0 -c 2 -l 1` (and added qemuparam="-soundhw ac97,es1370") the test case gets killed by OOM killer. Not sure we want to test QEMU here.
(In reply to comment #3) > > $ runqemu refkit-image-common ext4 intel-corei7-64 slirp [...] > The first failure is caused by the hardcoded "ip=dhcp" bootparam in the > runqemu script which prevents renaming eth0 to whatever pleases systemd. > Hopefully this can be fixed with making runqemu not override the > "bootparam=" user input. That will go away once we switch to booting with OVMF as firmware (patch currently stuck because of compile issues on some OE-core configurations) and the wic image, because then runqemu can't set that boot parameter.
(In reply to comment #4) > (In reply to comment #3) > > > $ runqemu refkit-image-common ext4 intel-corei7-64 slirp > [...] > > The first failure is caused by the hardcoded "ip=dhcp" bootparam in the > > runqemu script which prevents renaming eth0 to whatever pleases systemd. > > Hopefully this can be fixed with making runqemu not override the > > "bootparam=" user input. > > That will go away once we switch to booting with OVMF as firmware (patch > currently stuck because of compile issues on some OE-core configurations) > and the wic image, because then runqemu can't set that boot parameter. Oh, that's good. Though I've already submitted a patch to oe-core which won't harm anyway. At least it can help not to override "mem=". https://patchwork.openembedded.org/patch/137475/ And one more patch to meta-intel https://lists.yoctoproject.org/pipermail/meta-intel/2017-February/004602.html
Currently we're waiting for https://github.com/intel/intel-iot-refkit/pull/70 https://github.com/intel/intel-iot-refkit/pull/69 to be merged. Then perhaps Simo can help with enabling automatic tests under QEMU in our CI. To run a test suite one needs to 1. run a VM with `runqemu nographic serial refkit-image-common ext4 intel-corei7-64 bootparams="ip=off" slirp` (when inside bitbake's env) 2. on the same host where the VM is running run the suite with `cd /path/to/iottest; python runtest.py -f testplan/refkit-image-common.manifest -m intel-corei7-64 -t 127.0.0.1:2222 -s 10.0.2.2`. An alternative to the command in the step 1 could be something like > ${BUILD_DIR}/tmp-glibc/work/intel_corei7_64-refkit-linux/refkit-image-common/1.0-r0/recipe-sysroot-native/usr/bin/qemu-system-x86_64 -device virtio-net-pci,netdev=net0,mac=52:54:00:12:35:02 -netdev user,id=net0,hostfwd=tcp::2222-:22,hostfwd=tcp::2323-:23 -drive file=${BUILD_DIR}/tmp-glibc/deploy/images/intel-corei7-64/refkit-image-common-intel-corei7-64.ext4,if=virtio,format=raw -vga vmware -show-cursor -usb -usbdevice tablet -device virtio-rng-pci -nographic -cpu Nehalem -m 256 -serial mon:stdio -serial null -kernel ${BUILD_DIR}/tmp-glibc/deploy/images/intel-corei7-64/bzImage-intel-corei7-64.bin -append 'root=/dev/vda rw highres=off console=ttyS0 mem=256M vga=0 uvesafb.mode_option=640x480-32 oprofile.timer=1 uvesafb.task_timeout=-1 ip=off' I'm trying to understand how EFI would work in QEMU (when QEMU consumes wic images instead of ext4 rootfs and kernel), but I haven't advanced much so far.
(In reply to comment #6) > I'm trying to understand how EFI would work in QEMU (when QEMU consumes wic > images instead of ext4 rootfs and kernel), but I haven't advanced much so > far. Use "bitbake ovmf" (works with current OE-core master) and then "runqemu ovmf refkit-image-common wic intel-corei7-64".
(In reply to comment #7) > > Use "bitbake ovmf" (works with current OE-core master) and then "runqemu > ovmf refkit-image-common wic intel-corei7-64". Thanks! I didn't notice runqemu has got this option.
The PR https://github.com/intel/intel-iot-refkit/pull/69 is in master now, but meta-intel update has been excluded from https://github.com/intel/intel-iot-refkit/pull/70 the new PR is https://github.com/intel/intel-iot-refkit/pull/77.
Running "bitbake ovmf" and then "runqemu refkit-image-common wic" works for me but the problem is that I can't connect to qemu with ssh. It doesn't seem to get the 192.168.7.2 ip address that it should, instead it gets something like 169.254.232.81. Is it only me or is there still some problems using qemu? I also tried runqemu with "slirp" and it throws some error. Also tried without it and using DHCP server on host for "tap" interfaces but didn't work either.
By default QEMU uses tap interfaces, but setting up a local DHCP server can be tricky if you run dnsmasq locally. SLIRP is much easier as QEMU can use its built-in DHCP server in this mode. To avoid the error when using SLIRP your meta-intel layer must contain this patch https://lists.yoctoproject.org/pipermail/meta-intel/2017-February/004602.html Alternatively you can delete the line > qm_slirp_opt = -net nic,model=e1000 -net user,hostfwd=tcp::2222-:22 from your > ${BUILD_DIR}/tmp-glibc/deploy/images/intel-corei7-64/refkit-image-common-intel-corei7-64.qemuboot.conf file. Or just run QEMU directly without the runqemu wrapper: > ${BUILD_DIR}/tmp-glibc/work/intel_corei7_64-refkit-linux/refkit-image-common/1.0-r0/recipe-sysroot-native/usr/bin/qemu-system-x86_64 -device virtio-net-pci,netdev=net0,mac=52:54:00:12:35:02 -netdev user,id=net0,hostfwd=tcp::2222-:22,hostfwd=tcp::2323-:23 -drive if=virtio,file=${BUILD_DIR}/tmp-glibc/deploy/images/intel-corei7-64/refkit-image-common-intel-corei7-64.wic,format=raw -no-reboot -vga vmware -show-cursor -usb -usbdevice tablet -device virtio-rng-pci -drive if=pflash,format=qcow2,file=${BUILD_DIR}/tmp-glibc/deploy/images/intel-corei7-64/ovmf.qcow2 -vga std -cpu Nehalem -m 256 -serial mon:vc -serial null
Dima, I think this is working fine but in order to close the bug we'd still need a short howto doc to explain how to use it. Can you write a short doc explaining how to run the images using runqemu. Simo is looking a simple 'test case' for this.
HOWTO added in https://github.com/intel/intel-iot-refkit/pull/115