Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

starting qemu seems to be underdocumented #76

Closed
GuBi34 opened this issue Nov 29, 2021 · 10 comments
Closed

starting qemu seems to be underdocumented #76

GuBi34 opened this issue Nov 29, 2021 · 10 comments
Assignees

Comments

@GuBi34
Copy link
Contributor

GuBi34 commented Nov 29, 2021

Following the documentation on building and starting mtda with QEMU I could not find a link/getting started about how to start the dispatcher utilizing the sample config?

@chombourger
Copy link
Collaborator

have you checked https://mtda.readthedocs.io/en/latest/build.html#kvm ?

@GuBi34
Copy link
Contributor Author

GuBi34 commented Nov 30, 2021

Hello!

I tried to follow the documentation you mentioned.

  • I could build mtda for nano-pi and qemu-amd64 without any issues
  • I could start mtda-cli after resolving some python dependencies (which probably are not depicted in the requirements.txt?)
  • I failed at step mtda-cli -d -n
    * I understood from the docu that it should create the three disk images automatically on start (which did not happen in my case
    * I manually created usb-sdmux.img which brought me a bit further

I could not understand from the docu how the mtda qemu is to be started ... so I assumed this will probably be done by the mtda-cli -d -n command (just guessing). This one now hangs in

File "/home/siemens/local_repos/mtda/mtda/keyboard/qemu.py", line 34, in probe
     result = self.qemu.variant == "qemu"
AttributeError: 'NoneType' object has no attribute 'variant'

I looked around in the documentation to figure out how the qemu image is expected to be started ... but could not find something on it.

Hope that helps further to understand my state?

From there I am lagging

@chombourger
Copy link
Collaborator

prepared several commits to make it easier to install mtda pre-configured for kvm

for the avoidance of doubt, the qemu backend is to emulate a pc and control it using the same interfaces (power, storage, console).

for instance, I can install my mtda-aware (*) OS installer with:

# make sure mtda is running as a service
$ sudo systemctl start mtda
# check if qemu was properly started
$ sudo journalctl -u mtda|tail -n 5
Nov 30 15:48:22 build systemd[1]: Started Multi-Tenant Device Access.
Nov 30 15:48:22 build mtda-cli[209837]: QEMU emulator version 5.2.0 (Debian 1:5.2+dfsg-11)
Nov 30 15:48:22 build mtda-cli[209837]: Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers
Nov 30 15:48:22 build mtda-cli[209835]: # debug2: power.qemu.start(): swtpm process started [209849]
Nov 30 15:48:22 build mtda-cli[209835]: # debug2: power.qemu.start(): qemu process started [209857]
# write my installer image to the shared storage device
$ mtda-cli target off
$ mtda-cli storage  host
$ mtda-cli storage write service-stick.iso
# configure virtual target to boot from USB
$ mtda-cli storage target
$ mtda-cli setenv boot-from-usb 1
# power virtual target
$ mtda-cli target on
# interactive console
$ mtda-cli

(*) my OS installer is configured to use the USB UART as console if the MTDA USB Function device is detected

@GuBi34
Copy link
Contributor Author

GuBi34 commented Dec 2, 2021

... this already eases things a lot!
I performed the installation by pulling the package from fury....

I now encounter a different issue ... since the code seems to expect that a power switch needs to be necessarily in place (probably this needs not to be a precondition for any case?)

siemens@bullseye:~/local_repos/mtda$ mtda-cli -d -n
Traceback (most recent call last):
  File "/usr/bin/mtda-cli", line 767, in <module>
    app.main()
  File "/usr/bin/mtda-cli", line 724, in main
    status = self.server()
  File "/usr/bin/mtda-cli", line 67, in server
    status = self.agent.start()
  File "/usr/lib/python3/dist-packages/mtda/main.py", line 1243, in start
    status = self.power_controller.probe()
  File "/usr/lib/python3/dist-packages/mtda/power/aviosys_8800.py", line 43, in probe
    raise ValueError("Aviosys 8800 device not found!")
ValueError: Aviosys 8800 device not found!

@chombourger
Copy link
Collaborator

... this already eases things a lot! I performed the installation by pulling the package from fury....

I now encounter a different issue ... since the code seems to expect that a power switch needs to be necessarily in place (probably this needs not to be a precondition for any case?)

siemens@bullseye:~/local_repos/mtda$ mtda-cli -d -n
Traceback (most recent call last):
  File "/usr/bin/mtda-cli", line 767, in <module>
    app.main()
  File "/usr/bin/mtda-cli", line 724, in main
    status = self.server()
  File "/usr/bin/mtda-cli", line 67, in server
    status = self.agent.start()
  File "/usr/lib/python3/dist-packages/mtda/main.py", line 1243, in start
    status = self.power_controller.probe()
  File "/usr/lib/python3/dist-packages/mtda/power/aviosys_8800.py", line 43, in probe
    raise ValueError("Aviosys 8800 device not found!")
ValueError: Aviosys 8800 device not found!

you have apparently configured mtda (daemon) to use an aviosys but none was found on your system. the code is consequently failing. if you do not have one, you will then use to amend your configuration file (e.g. /etc/mtda/config) to use another one (that you have attached to the system running mtda-cli -d)

@chombourger
Copy link
Collaborator

chombourger commented Dec 3, 2021

shared a sample OS installer image wtih @GuBi34

assuming you have apt-get install'ed mtda and mtda-kvm on your Debian system, you should have MTDA pre-configured to emulate a virtual PC

The following commands may then be used to prepare and "flash" the installer to the shared storage

# let's stop mtda so we can create larger disk images
$ sudo systemctl stop mtda
# let's now create blank disk images
$ sudo install -m 0755 -d /var/lib/mtda
$ sudo dd if=/dev/zero of=/var/lib/mtda/usb-shared-storage.img bs=1G count=16
$ sudo dd if=/dev/zero of=/var/lib/mtda/ssd.img bs=1G count=32
# restart mtda
$ sudo systemctl start mtda
# check if qemu was properly started
$ sudo journalctl -u mtda|tail -n 5
Nov 30 15:48:22 build systemd[1]: Started Multi-Tenant Device Access.
Nov 30 15:48:22 build mtda-cli[209837]: QEMU emulator version 5.2.0 (Debian 1:5.2+dfsg-11)
Nov 30 15:48:22 build mtda-cli[209837]: Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers
Nov 30 15:48:22 build mtda-cli[209835]: # debug2: power.qemu.start(): swtpm process started [209849]
Nov 30 15:48:22 build mtda-cli[209835]: # debug2: power.qemu.start(): qemu process started [209857]
# write my installer image to the shared storage device
$ mtda-cli target off
$ mtda-cli storage  host
$ mtda-cli storage write service-stick.iso
# configure virtual target to boot from USB
$ mtda-cli storage target
$ mtda-cli setenv boot-from-usb 1
# power virtual target
$ mtda-cli target on
# interactive console
$ mtda-cli

The installer should eventually show in the MTDA console.
Hit Ctrl-a and then q to leave the interactive console

@GuBi34
Copy link
Contributor Author

GuBi34 commented Dec 6, 2021

Hi Cedric! Thanks a lot for the support and major improvements! I was stuck because of the nested virtualization (KVM within VMWare Workstation) having set insufficient HW virtualization support ... I will write some getting started documentation and propose docu enhancements if appreceated ... thanks to your help I already came that far ... One more question ... will the fury apt repository be the final one to provide mtda? If so we should add it to the documentation ... I think the issue can be closed.

image
my first mtda remote console :-)

@GuBi34
Copy link
Contributor Author

GuBi34 commented Dec 6, 2021

if someone else happens to configure KVM within VMWare workstation/VSphere ESXi client:
Make sure to configure the hardware virtuaization capabilities to the guest OS (hosting mtda as well as emulating DUT on qemu).
image

@chombourger
Copy link
Collaborator

Hi Gunther (@GuBi34),

that's great news. Fury is indeed our repo for now (the team behind code.siemens.com & github.com/siemens is looking for a solution for a uniform package delivery mechanism within our org). PR #96 comes with additional notes for getting folks started with QEMU/KVM. We definitely welcome PRs with docu updates.

@chombourger
Copy link
Collaborator

Hi Gunther (@GuBi34)

#100 will add support the USB HID relay we talked about the other day. I haven't tested that code just yet. Will provide updates in that pull request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants