Exactly. And I agree, it seems like hw_architecture should dictate
which emulator is chosen, but as you mentioned its currently not. I'm
not sure if this is a bug and it's supposed to 'just work', or just
something that was never fully implemented (intentionally) and would be
more of a feature request/suggestion for a later version. The docs are
kind of sparse in this area.
What are your thoughts? I can open a bug if you think the scope is
reasonable.
---
v/r
Chris Apsey
bitskr...@bitskrieg.net
https://www.bitskrieg.net
On 2018-08-08 06:40 PM, Matt Riedemann wrote:
On 8/8/2018 2:42 PM, Chris Apsey wrote:
qemu-system-arm, qemu-system-ppc64, etc. in our environment are all
x86 packages, but they perform system-mode emulation (via dynamic
instruction translation) for those target environments. So, you run
qemu-system-ppc64 on an x86 host in order to get a ppc64-emulated VM.
Our use case is specifically directed at reverse engineering binaries
and fuzzing for vulnerabilities inside of those architectures for
things that aren't built for x86, but there are others.
If you were to apt-get install qemu-system and then hit autocomplete,
you'd get a list of archiectures that qemu can emulate on x86 hardware
- that's what we're trying to do incorporate. We still want to run
normal qemu-x86 with KVM virtualization extensions, but we ALSO want
to run the other emulators without the KVM virtualization extensions
in order to have more choice for target environments.
So to me, openstack would interpret this by checking to see if a
target host supports the architecture specified in the image (it does
this correctly), then it would choose the correct qemu-system-xx for
spawning the instance based on the architecture flag of the image,
which it currently does not (it always choose qemu-system-x86_64).
Does that make sense?
OK yeah now I'm following you - running ppc guests on an x86 host
(virt_type=qemu rather than kvm right?).
I would have thought the hw_architecture image property was used for
this somehow to configure the arch in the guest xml properly, like
it's used in a few places [1][2][3].
See [4], I'd think we'd set the guest.arch but don't see that
happening. We do set the guest.os_type though [5].
[1]
https://github.com/openstack/nova/blob/c18b1c1bd646d7cefa3d3e4b25ce59460d1a6ebc/nova/virt/libvirt/driver.py#L4649
[2]
https://github.com/openstack/nova/blob/c18b1c1bd646d7cefa3d3e4b25ce59460d1a6ebc/nova/virt/libvirt/driver.py#L4927
[3]
https://github.com/openstack/nova/blob/c18b1c1bd646d7cefa3d3e4b25ce59460d1a6ebc/nova/virt/libvirt/blockinfo.py#L257
[4] https://libvirt.org/formatcaps.html#elementGuest
[5]
https://github.com/openstack/nova/blob/c18b1c1bd646d7cefa3d3e4b25ce59460d1a6ebc/nova/virt/libvirt/driver.py#L5196
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
