Open Stack

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
bitskrieg at 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