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

Reply via email to