If one has e.g.
<guest>
<os_type>hvm</os_type>
<arch name='x86_64'>
<wordsize>64</wordsize>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<machine>pc-0.11</machine>
<machine canonical='pc-0.11'>pc</machine>
<machine>pc-0.10</machine>
<machine>isapc</machine>
<domain type='qemu'>
</domain>
<domain type='kvm'>
<emulator>/usr/bin/kvm</emulator>
<machine>pc</machine>
<machine>isapc</machine>
</domain>
</arch>
</guest>
and start a guest with:
<domain type='kvm'>
...
<os>
<type arch='x86_64'>hvm</type>
...
</os>
</domain>
then the default machine type should be 'pc' and not 'pc-0.11'
Issue was reported by Anton Protopopov.
* src/capabilities.[ch]: pass the domain type to
virCapabilitiesDefaultGuestArch() and use it to look up the default
machine type from a specific guest domain if needed.
* src/conf/domain_conf.c, src/xen/xm_internal.c: update
* tests/qemuxml2argvdata/qemuxml2argv-machine-aliases2.xml: update
the domain type to 'kvm' and remove the machine type to check
that the default gets looked up correctly
The domain/os/type element may have an arch specified without having
a machine variant specified. In fact, this is what python-virtinst
does when defining a guest.
* docs/schemas/domain.rng: allow missing machine type
The existing python demo for domain events does not fully
implement the event loop contract. This makes the code useless
for real world applications. This change re-writes the demo so
that it has a full event loop implementation which is suitable
for application usage & better demonstrates integration
* examples/domain-events/events-python/event-test.py: Rewrite
to include a real world usable event loop implementation
Removes some auto-generated files still under version control.
It also moves the rule for generating NEWS into the Makefile.am
that's in the same directory as the output file to avoid confusion
* docs/libvirt-api.xml, docs/libvirt-refs.xml, NEWS: Remove
auto-generated files from source control
* Makefile.am: Add rule for generating NEWS file
* docs/Makefile.am: Remove rule for generating NEWS file
Introduces several new public API options for migration
- VIR_MIGRATE_PEER2PEER: With this flag the client only
invokes the virDomainMigratePerform method, expecting
the source host driver to do whatever is required to
complete the entire migration process.
- VIR_MIGRATE_TUNNELLED: With this flag the actual data
for migration will be tunnelled over the libvirtd RPC
channel. This requires that VIR_MIGRATE_PEER2PEER is
also set.
- virDomainMigrateToURI: This is variant of the existing
virDomainMigrate method which does not require any
virConnectPtr for the destination host. Given suitable
driver support, this allows for all the same modes as
virDomainMigrate()
The URI for VIR_MIGRATE_PEER2PEER must be a valid libvirt
URI. For non-p2p migration a hypervisor specific migration
URI is used.
virDomainMigrateToURI without a PEER2PEER flag is only
support for Xen currently, and it involves XenD talking
directly to XenD, no libvirtd involved at all.
* include/libvirt/libvirt.h.in: Add VIR_MIGRATE_PEER2PEER
flag for migration
* src/libvirt_internal.h: Add feature flags for peer to
peer migration (VIR_FEATURE_MIGRATE_P2P) and direct
migration (VIR_MIGRATE_PEER2PEER mode)
* src/libvirt.c: Implement support for VIR_MIGRATE_PEER2PEER
and virDomainMigrateToURI APIs.
* src/xen/xen_driver.c: Advertise support for DIRECT migration
* src/xen/xend_internal.c: Add TODO item for p2p migration
* src/libvirt_public.syms: Export virDomainMigrateToURI
method
* src/qemu/qemu_driver.c: Add support for PEER2PEER and
migration, and adapt TUNNELLED migration.
* tools/virsh.c: Add --p2p and --direct args and use the
new virDomainMigrateToURI method where possible.
Re-arrange the doTunnelMigrate method putting all non-QEMU local
state setup steps first. This maximises chances of success before
then starting destination QEMU for receiving incoming migration.
Altogether this can reduce the number of goto cleanup labels to
something more managable.
* qemu/qemu_driver.c: Re-order steps in doTunnelMigrate
Simplify the doTunnelMigrate code by pulling out the code for
sending all tunnelled data into separate helper
* qemu/qemu_driver.c: introduce doTunnelSendAll() method
Simplify the doTunnelMigrate() method by pulling out the code
which opens/closes the virConnectPtr object into a parent
method
* qemu/qemu_driver.c: Add doPeer2PeerMigrate which then calls
doTunnelMigrate with dconn & dom_xml
virStreamAbort is needed when the caller wishes to terminate
the stream early, not when virStreamSend fails.
* qemu/qemu_driver.c: Fix calling of virStreamAbort during
tunnelled migration
The code for tunnelled migration was added in a dedicated method,
but the native migration code is still inline in the top level
qemudDomainMigratePerform() API. Move the native code out into
a dedicated method too to make things more maintainable.
* src/qemu/qemu_driver.c: Pull code for performing a native
QEMU migration out into separate method
The code for tunnelled migration wierdly required the app to pass
a NULL 'dconn' parameter, only to have to use virConnectOpen
itself shortly thereafter to get a 'dconn' object. Remove this
bogus check & require the app to always pas 'dconn' as before
* src/libvirt.c: Require 'dconn' for virDomainMigrate calls again
and remove call to virConnectOpen
Since virMigratePrepareTunnel() is used for migration over the
native libvirt connection, there is never any need to pass the
target URI to this method.
* daemon/remote.c, src/driver.h, src/libvirt.c, src/libvirt_internal.h,
src/qemu/qemu_driver.c, src/remote/remote_driver.c,
src/remote/remote_protocol.c, src/remote/remote_protocol.h,
src/remote/remote_protocol.x: Remove 'uri_in' parameter from
virMigratePrepareTunnel() method
Move the VIR_DRV_FEATURE* constants into libvirt_internal.h
since these flags are indicating whether APIs in the
libvirt_internal.h file are supported by a driver
* src/driver.h: Remove VIR_DRV_FEATURE* constants
* src/libvirt_internal.h: Add VIR_DRV_FEATURE* constants, using
an enum instead of #define
* src/internal.h: pull in libvirt_internal.h
* src/lxc/lxc.conf: new configuration file, there is currently one
tunable "log_with_libvirtd" that controls whether an lxc controller will
log only to the container log file, or whether it will honor libvirtd's
log output configuration. This provides a way to have libvirtd and its
children log to a single file. The default is to log to the container
log file.
* src/Makefile.am libvirt.spec.in: add the new file
* src/lxc/lxc_conf.[ch] src/lxc/lxc_driver.c: read the new log value
from the configuration file and pass the log informations when
starting up a container.
* src/lxc/lxc_driver.c src/lxc/lxc_controller.c: before launching the
lxc controller, have the lxc driver query the log settings and setup
envp[]. This provides the advantage of honoring the actual log
configuration instead of only what had been set in the environment.
The lxc controller now simply has to call virLogSetFromEnv().
When configuring logging settings, keep more information about the
output destination. Add accessors to retrieve the filter and output
settings in the original string form; this to be used to set up
environment for a child process that also logs.
* src/util/logging.[ch]: add virLogGetFilters and virLogGetOutputs
accessors and modify the internals (including virLogDefineOutput())
to save the data needed for the accessors
* src/util/util.[ch]: Add virFileAbsPath() function to ensure an
absolute path for a potentially realtive path.
* src/libvirt_private.syms: add it in libvirt private symbols
* docs/drvqemu.html.in: include documentation for AppArmor sVirt
confinement
* examples/apparmor/TEMPLATE examples/apparmor/libvirt-qemu
examples/apparmor/usr.lib.libvirt.virt-aa-helper
examples/apparmor/usr.sbin.libvirtd: example templates and
configuration files for SVirt Apparmor when using KVM/QEmu
* configure.in: look for AppArmor and devel
* src/security/security_apparmor.[ch] src/security/security_driver.c
src/Makefile.am: add and plug the new driver
* src/security/virt-aa-helper.c: new binary which is used exclusively by
the AppArmor security driver to manipulate AppArmor.
* po/POTFILES.in: registers the new files
* tests/Makefile.am tests/secaatest.c tests/virt-aa-helper-test:
tests for virt-aa-helper and the security driver, secaatest.c is
identical to seclabeltest.c except it initializes the 'apparmor'
driver instead of 'selinux'
The patch implements the missing memory control APIs for lxc, i.e.,
domainGetMaxMemory, domainSetMaxMemory, domainSetMemory, and improves
domainGetInfo to return proper amount of used memory via cgroup.
* src/libvirt_private.syms: Export virCgroupGetMemoryUsage
and add missing virCgroupSetMemory
* src/lxc/lxc_driver.c: Implement missing memory functions
* src/util/cgroup.c, src/util/cgroup.h: Add the function
to get used memory
When James Morris originally submitted his sVirt patches (as seen in
libvirt 0.6.1), he did not require on disk labelling for
virSecurityDomainRestoreImageLabel. A later commit[2] changed this
behavior to assume on disk labelling, which halts implementations for
path-based MAC systems such as AppArmor and TOMOYO where
vm->def->seclabel is required to obtain the label.
* src/security/security_driver.h src/qemu/qemu_driver.c
src/security/security_selinux.c: adds the 'virDomainObjPtr vm'
argument back to *RestoreImageLabel
While running make check, I noticed that it was actually using
the virsh binary from my system, in /usr/bin/virsh, and not the
one that was just compiled. This is actually caused by a bug
in Makefile.am, where we didn't update the PATH to include tools.
While here, I also updated all of the scripts to properly define
the srcdir, abs_top_srcdir, and abs_top_builddir environment
variables. This is required if you want to be able to run the
tests standalone (i.e. ./test instead of from make check). I've
tested this on both RHEL-5 and Fedora-10 machines, and make check
works on both, as does running the individual tests by hand.
Signed-off-by: Chris Lalancette <clalance@redhat.com>
Otherwise logrotate barfs:
error: error accessing /var/log/libvirt/uml: No such file or directory
error: libvirtd:1 glob failed for /var/log/libvirt/uml/*.log
error: found error in /var/log/libvirt/qemu/*.log /var/log/libvirt/uml/*.log /var/log/libvirt/lxc/*.log , skipping
* qemud/Makefile.am: always create /var/log/libvirt/{lxc,uml} when
installing the logrotate conf; not ideal, but easier than making
the logrotate conf depend on which drivers are enabled
The devhelp/ directory files depend on libvirt-api.xml being
uptodate, but automake always processes SUBDIRS before the
current directory. So devhelp would be built and then the
libvirt-api.xml re-build, invalidating the devhelp data again.
To fix this all the rules for devhelp are moved directly
into the docs/Makefile.am allowing make to see the global
dependancy chain and thus build things in the correct order
* docs/Makefile.am: Add rules for devhelp rebuild
* docs/devhelp/Makefile.am: Remove devhelp rebuild
* configure.in: Remove docs/devhelp/Makefile.am
Add virNodeDeviceParseFile, and make virNodeDeviceParseNode non-static. These
will be used by the test driver.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Add a simple 'computer' device for the default driver. Only implement
the basic calls, no creation or destroy happening.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
A mistake in the generator was causing virInterface methods to be generated
with unpredicatable names ('ceUndefine', instead of just 'undefine'). This
fixes the method names to match existing convention.
Does anyone care if we are breaking API compat? My guess is that no one is
using the python interface bindings yet.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The API docs explictly warn that we shouldn't use the C vir*GetConnect calls
in bindings: doing so can close the internal connection pointer and cause
things to get screwy. Implement these calls in python.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
A special case in the generator wasn't doing its job, and duplicate
conn.createXML functions were being generated. The bindings diff is:
@@ -1079,14 +1079,6 @@ class virConnect:
return __tmp
def createXML(self, xmlDesc, flags):
- """Create a new device on the VM host machine, for example,
- virtual HBAs created using vport_create. """
- ret = libvirtmod.virNodeDeviceCreateXML(self._o, xmlDesc, flags)
- if ret is None:raise libvirtError('virNodeDeviceCreateXML() failed', conn=self)
- __tmp = virNodeDevice(self, _obj=ret)
- return __tmp
-
- def createXML(self, xmlDesc, flags):
"""Launch a new guest domain, based on an XML description
similar to the one returned by virDomainGetXMLDesc() This
function may requires privileged access to the hypervisor.
@@ -1327,6 +1319,14 @@ class virConnect:
__tmp = virNetwork(self, _obj=ret)
return __tmp
+ def nodeDeviceCreateXML(self, xmlDesc, flags):
+ """Create a new device on the VM host machine, for example,
+ virtual HBAs created using vport_create. """
+ ret = libvirtmod.virNodeDeviceCreateXML(self._o, xmlDesc, flags)
+ if ret is None:raise libvirtError('virNodeDeviceCreateXML() failed', conn=self)
+ __tmp = virNodeDevice(self, _obj=ret)
+ return __tmp
+
def nodeDeviceLookupByName(self, name):
"""Lookup a node device by its name. """
ret = libvirtmod.virNodeDeviceLookupByName(self._o, name)
Signed-off-by: Cole Robinson <crobinso@redhat.com>
xmllib has been deprecated since python 2.0, and running the generator throws
a warning. Move to using xml.sax
Signed-off-by: Cole Robinson <crobinso@redhat.com>
FastParser uses sgmlop, a non-standard python module meant as a replacement
for xmllib (which is deprecated since python 2.0). Fedora doesn't even carry
this module, and the generator doesn't have high performance requirements, so
just rip the code out.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
--with-python currently already works for enabling/disabling the python
bindings, but doesn't show up in the help output.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
