The (now assumed) QEMU_CAPS_CHARDEV_SPICEVMC is preferred.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Last use was removed by commit 0586cf98 deprecating
QEMU_CAPS_DEVICE.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Implied by QEMU >= 1.2.0.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Fixed-up-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Implied by QEMU >= 0.12.0.
Deprecated by QEMU commit 1ed2fc1 included in 0.12.0.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Remove the unnecessary goto error followed by goto cleanup
processing.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since there is no way to get to cleanup without dom being NULL,
this is a unnecessary Unref.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The legacy xen driver is removed, so these ACL hacks can be removed
too now.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The last use of qemuMonitorMigrateToCommand was removed years back in
commit 2e90c9daf9
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Fri Nov 6 16:50:26 2015 +0000
qemu: assume support for all migration protocols except rdma
Prior to that commit, 'exec:' to used to replicate the 'unix:' protocol
by spawning 'nc'.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Remove unnecessary virFileIsExecutable check after virFindFileInPath.
Since the commit 9ae992f virFindFileInPath will reject non-executables.
Signed-off-by: Radostin Stoyanov <rstoyanov1@gmail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Avoid the need for the drivers to explicitly check for a NULL path by
making sure it is at least the empty string.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Now that the legacy Xen driver has been dropped, we no longer need to
support URIs such as "/path/to/xend/socket", and so can mandate that a
URI scheme must always be present.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Ensuring that we don't call the virDrvConnectOpen method with a NULL URI
means that the drivers can drop various checks for NULL URIs. These were
not needed anymore since the probe functionality was split
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Declare what URI schemes a driver supports in its virConnectDriver
struct. This allows us to skip trying to open the driver entirely
if the URI scheme doesn't match.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Add a localOnly flag to the virConnectDriver struct which allows a
driver to indicate whether it is local-only, or permits remote
connections. Stateful drivers running inside libvirtd are generally
local only. This allows us to remote the check for uri->server != NULL
from most drivers.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Currently the virDrvConnectOpen method is supposed to handle both
opening an explicit URI and auto-probing a driver if no URI is
given. Introduce a dedicated virDrvConnectURIProbe method to enable the
probing functionality to be split from the driver opening functionality.
It is still possible for NULL to be passed to the virDrvConnectOpen
method after this change, because the remote driver needs special
handling to enable probing of the URI against a remote libvirtd daemon.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Historically we have used a bare lxc:/// URI for connecting to LXC. This
is different from our practice with QEMU, UML, Parallels, Libxl, BHyve
and VirtualBox drivers, which all use a path of '/system' or '/session'
or both.
By making LXC allow '/system', we have fully standardized on the use of
either '/system' or '/session' for all the stateful drivers that run
inside libvirtd.
Support for lxc:/// is of course maintained for back-compat.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Historically we have used a bare xen:/// URI for connecting to the
legacy Xen driver. The new libxl Xen driver follows the new practice
of allowing '/system' as a path, as well as bare '/' for compat with
the old Xen driver.
This documents xen:///system as the preferred format for Xen, leaving
xen:/// as an undocumented feature just for back-compat.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Implied by QEMU >= 1.2.0.
Delete this one first, because QEMU_CAPS_NODEFCONFIG is only used
when QEMU_CAPS_NO_USER_CONFIG is unsupported.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
We require QEMU >= 1.5.0, assume every QEMU supports it.
Sadly that does not let us trivially drop qemuMonitor's
priv->monJSON bool, because of qemuDomainQemuAttach.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Now that we assume QEMU_CAPS_NETDEV, the only thing left to check
is whether we need to use the legacy -net syntax because of
a non-conforming armchitecture.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Now that we assume -netdev support, we no longer set the VLAN
or need the hostPlugged bool.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
This makes qemuDomainSupportsNetdev identical to
qemuDomainSupportsNicdev and leaves some code in
qemuDomainAttachNetDevice to be cleaned up later.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
In 2ada9ef146 we've tried to turn virDomainChrSourceDef into
virObject. Well, this requires 'virObject' member to be stored on
the first position of the struct. This adjustment is missing in
the original commit leading to all sorts of funny memleaks and
data corruptions.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Due to mediation of socket and signal activity currently qemu:///session
connections calling qemu_bridge_helper fail.
We need the profile for libvirtd itself and the subprofile for
qemu-bridge-helper to be able to talk/notify to each other via unix socket and
signals.
Fixes: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1754871
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
All Xen PV and HVM with PV driver support a memory balloon device,
which cannot be disabled through the toolstack. Model the device
in the libxl driver, similar to the recently removed xend-based
driver.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
For openvzDomObjFromDomainLocked and openvzDomainLookupByID
let's return a locked and referenced @vm object so that callers
can then use the common and more consistent virDomainObjEndAPI
in order to handle cleanup rather than needing to know that the
returned object is locked and calling virObjectUnlock.
The LookupByName already returns the ref counted and locked object,
so this will make things more consistent.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
If openvzDomainLookupByID or openvzDomainLookupByName fails
to find a vm, let's be a bit more descriptive by providing
the failing id or name in the error message.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
Rather than repeat code throughout, create and use a couple of
accessors in order to lookup by UUID.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
The virDomainObjListRemove will return an unlocked
@vm after calling with a reffed object, thus prior
to calling virDomainObjEndAPI we should relock.
Signed-off-by: John Ferlan <jferlan@redhat.com>
In error paths, if we call virDomainObjListRemove we will leak
the @vm because we have called with a reffed and locked @vm.
So rather than set it to NULL, relock the @vm and allow the
virDomainObjEndAPI to perform the magic of Unlock/Unref.
Signed-off-by: John Ferlan <jferlan@redhat.com>
For bhyveDomObjFromDomain, bhyveDomainLookupByUUID, and
bhyveDomainLookupByID let's return a locked and referenced
@vm object so that callers can then use the common and more
consistent virDomainObjEndAPI in order to handle cleanup rather
than needing to know that the returned object is locked and
calling virObjectUnlock.
The LookupByName already returns the ref counted and locked object,
so this will make things more consistent.
For bhyveDomainUndefine and bhyveDomainDestroy since the
virDomainObjListRemove will return an unlocked object, we need to
relock before making the EndAPI call.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Up until now we have only formatted non-default GIC versions on
the command line, in order to maintain compatibility with older
QEMU versions that didn't implement the gic-version option to
begin with; however, doing so is entirely unnecessary for newer
QEMU versions, where the option is available. Moreover, having
the GIC version formatted on the command line at all times
ensures that QEMU changing its own defaults doesn't affect the
ABI of libvirt guests.
A few test cases are removed to avoid extra churn. It doesn't
matter for coverage, as those scenarios are already covered by
other parts of the test suite.
This patch is better viewed with 'git show -w'.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This is the responsability of the caller to apply the correct lock
before using these functions. Moreover, the use of a simple boolean
was still racy: two threads may check the boolean and "lock" it
simultaneously.
Users of functions from src/util/virhash.c have to be checked for
correctness. Lookups and iteration should hold a RO
lock. Modifications should hold a RW lock.
Most important uses seem to be covered. Callers have now a greater
responsability, notably the ability to execute some operations while
iterating were reliably forbidden before are now accepted.
Signed-off-by: Vincent Bernat <vincent@bernat.im>
For patches pushed upstream we want builds run on master branch, but
don't want them run on the -maint branches, as we are not keeping the
.travis.yml file on stable branches updated wrt latest needs of travis
CI platforms.
We can't just whitelist 'master' though, because that will prevent
developers triggering their own private travis builds. So we just
blacklist *-maint, since developers will typically use named feature
branches for any work.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
