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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
