* src/Makefile.am src/node_device.[ch] src/node_device_conf.[ch]
src/node_device_hal.[ch] src/node_device_hal_linux.c
src/qemu_driver.c src/remote_internal.c src/storage_backend.c
src/virsh.c src/xen_unified.c tests/nodedevxml2xmltest.c
po/POTFILES.in: implementation for node device create and destroy
in NPIV support, patch by David Allan
Daniel
If two virtual networks have the same hardcoded bridge device (which
prevents them from being active simultaneously) we still want to define
them at daemon startup, so the user has a fighting chance of correcting
the XML error.
Add an extra flag to SetBridge to avoid reporting an error if there is
a bridge collision, and use this when loading network configs at startup.
This regressed via commit 4c3f3b4d.
Parse the command line output a bit earlier so we have a better chance
of reporting the full error output on failure.
I hit this when QEMU would try to boot an invalid kernel (virtinst bug).
There is different spacing when listing active vs. inactive networks. Ex:
Name State Autostart
-----------------------------------------
default active yes
xxxxxx inactive no
* src/qemu_conf.c docs/schemas/domain.rng
tests/capabilityschemadata/caps-qemu-kvm.xml: PPC Qemu Machine Type
changed from g3bw to g3beige some time ago, patch by Thomas Baker
Daniel
* docs/schemas/storagevol.rng docs/formatstorage.html[.in]
tests/storagevolschemadata/vol-qcow2.xml: fix storage volume
inconsistencies in schema and document, patch by Ryota Ozaki
daniel
* src/opennebula/one_conf.[ch] src/opennebula/one_driver.[ch]:
the OpenNebula driver
* configure.in include/libvirt/virterror.h qemud/Makefile.am
qemud/qemud.c src/Makefile.am src/domain_conf.[ch] src/driver.h
src/libvirt.c src/virterror.c: integration of the OpenNebula
driver in the libvirt infrastructure
* AUTHORS: add Abel Miguez Rodriguez
daniel
* qemud/qemud.c src/console.c src/network_driver.c
src/node_device_conf.c src/node_device_hal.c src/storage_conf.c
src/util.c: cleanup of some direct stderr logging
daniel
There is some funkiness here, since we are either dealing with 2 different
pools (which means validation x 2) or the same pool, where we have to be
careful not to deadlock.
The cap_lost and prop_modified callbacks could deadlock if an existing
device needed to be refreshed, since dev_create expects the driver to
be unlocked.
Daniel P. Berrange