On Tue, Jul 22, 2008 at 11:42:03AM -0400, Cole Robinson wrote:
Hi all,
I've hit a couple bugs in the qemu driver with the recent domain xml refactoring. I've debugged them but in both cases I'm not sure what the optimal solutions are, so I'm just laying them out here:
1) Previously defining a qemu guest without a 'listen' address specified in the graphics tag would default to 127.0.0.1 (hardcoded in qemu_driver->vncListen). Current xml doesn't set this default, and will build a qemu command line with an entry like '-vnc (null):1'. Not sure if the default should be set at the parsing level or the driver level.
There was a good reason for removing the 127.0.0.1 from the XML parsing stage, but i can't remember what it is :-) Anyway this should really be handled at the point where we build the command line in the qemu driver code
2) If a cpuset isn't specified, def->cpumask is null. However qemudInitCpus from qemu_driver.c doesn't know how to handle this, causing libvirtd to crash. This function is also using QEMUD_CPUMASK_LEN which I think should be replaced with VIR_DOMAIN_CPUMASK_LEN. I tried the obvious fix of just skipping the dependent code if cpumask is null, but there still seemed to be problems and I didn't dig much deeper.
I'm surprised that doesn't work - we should be able to just skip the bit of code within the HAVE_SCHED_GETAFFINITY conditional, and go straight to the part when it issues the 'cont' command to the monitor to start execution. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|