[libvirt] Couple qemu driver bugs after xml refactoring

Daniel P. Berrange berrange at redhat.com
Tue Jul 22 15:53:19 UTC 2008


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 :|




More information about the libvir-list mailing list