Open Stack

Matt,

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?

Chris



---
v/r

Chris Apsey
bitskrieg at bitskrieg.net
https://www.bitskrieg.net

On 2018-08-08 03:07 PM, Matt Riedemann wrote:
> On 8/7/2018 8:54 AM, Chris Apsey wrote:
>> We don't actually have any non-x86 hardware at the moment - we're just 
>> looking to run certain workloads in qemu full emulation mode sans KVM 
>> extensions (we know there is a huge performance hit - it's just for a 
>> few very specific things).  The hosts I'm talking about are normal 
>> intel-based compute nodes with several different qemu packages 
>> installed (arm, ppc, mips, x86_64 w/ kvm extensions, etc.).
>> 
>> Is nova designed to work in this kind of scenario?  It seems like many 
>> pieces are there, but they're just not quite tied together quite 
>> right, or there is some config option I'm missing.
> 
> As far as I know, nova doesn't make anything arch-specific for QEMU.
> Nova will execute some qemu commands like qemu-img but as far as the
> virt driver, it goes through the libvirt-python API bindings which
> wrap over libvirtd which interfaces with QEMU. I would expect that if
> you're on an x86_64 arch host, that you can't have non-x86_64 packages
> installed on there (or they are noarch packages). Like, I don't know
> how your packaging works (are these rpms or debs, or other?) but how
> do you have ppc packages installed on an x86 system?