On Fri, Oct 14, 2011 at 01:20:01PM +0530, Prerna Saxena wrote:
On 10/13/2011 06:53 PM, Jiri Denemark wrote:
>On Thu, Oct 13, 2011 at 17:48:52 +0530, Prerna Saxena wrote:
>>>Yep, these 2 are the bulk of the work, mostly in the qemu_command.c
>>>file I expect.
>>
>>Yes. For starters, I'm seeing if qemu-command.c can be split into :
>>qemu-command-common.c
>>qemu-command-x86.c
>>qemu-command-ppc64.c
>>
>>Depending on the host architecture, qemu-command-common.o could be linked
>>with the respective arch-specific device spec.
>>Makefile would resemble something like this:
>>...
>>qemu-command-y = qemu-command-common.o
>>qemu-command-y += qemu-command-$(TARGET_BASE_ARCH)
>>...
>>
>>It is just an initial thought. Suggestions ??
>
>That's not the right approach. The code that needs to be used to generate qemu
>command line doesn't depend on the architecture on which libvirtd is running
>but rather on the architecture of the domain you're going to start. There's
no
>reason you should not be allowed to run qemu-system-ppc64 in purely emulating
>mode on x86_64 host. We should not artificially disable this usage.
>
>Jirka
>
Hi Jirka,
Thanks for pointing it out-- this aspect had escaped my attention.
I'll work on how we can create an additional interface which would
let libvirt choose appropriate devices at runtime, depending on
guest domain
architecture.
If you have a virDomainDefPtr object instance, you can look at the field
def->os.arch
and make decisions from that.
Regards,
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|