The https protocol is also accepted by qemu/KVM when specifying the cdrom ISO
image.
The xml should be as following:
<disk type='network' device='cdrom'>
<source protocol='https' name='/url/path'>
<host name='host.name' port='443'/>
</source>
</disk>
Signed-off-by: Aline Manera <alinefm@br.ibm.com>
GCC 4.8.0+ whines about variable "new" being uninitialized since
commit 73bfac0e71. This is a false positive as the
xmlFreeNode(new) statement can be only reached if new was actually
allocated successfully.
CC conf/libvirt_conf_la-domain_conf.lo
conf/domain_conf.c: In function 'virDomainDefSetMetadata':
conf/domain_conf.c:18650:24: error: 'new' may be used uninitialized in this function [-Werror=maybe-uninitialized]
xmlFreeNode(new);
Reported independently by John Ferlan and Michal Privoznik.
Commit 073e1575 tried to set things up so that 1) generated files
to be shipped in the tarball always live in srcdir, and 2) we have
no files in SOURCES that depend on any other files with a literal
$(srcdir) in the name, because that situation can cause confusing
results for the make expansion of $@ depending on whether the file
is found locally or via VPATH. But all my testing for that patch
was done incrementally, where all the protocol.[ch] files had
already been generated prior to the patch and were up-to-date in
the srcdir, and thus I missed one case where $@ causes grief in a
VPATH build from a fresh checkout:
We have a pattern rule for generating remote_protocol.[ch], and
what's more, the rule for protocol.c depends on protocol.h AND
on the protocol.x file. The pattern for protocol.c is only
satisfied via the VPATH lookup for protocol.x, and if protocol.h
doesn't yet exist, the VPATH rule kicks in and we end up with a
dependency on a file with $(srcdir) in the name. Based on make's
rules for $@, this resulted in make building remote_protocol.h
into srcdir (where we want it), then remote_protocol.c into
builddir (oops, not so good for the tarball), and also causes
the build to fail (the compiler can't find the .h if it lives
in a different directory than the .c):
CC remote/libvirt_driver_remote_la-remote_protocol.lo
remote/remote_protocol.c:7:29: fatal error: remote_protocol.h: No such file or directory
#include "remote_protocol.h"
^
compilation terminated.
As before, the fix is to hard-code the output file to go into
srcdir in spite of $@; but since this is in a pattern rule, we
are forced to use $@ in the recipe, so the patch is a bit
trickier than what was done in commit 073e1575.
* src/Makefile.am (%protocol.c, %protocol.h): Force output to srcdir.
Signed-off-by: Eric Blake <eblake@redhat.com>
Eric Blake suggested that we could do a little better in case copying of
the metadata to be set fails. With this patch, the old metadata is
discarded after the new string is copied successfuly.
If the ABI compatibility check with the "migratable" user XML is
successful, we would leak the originally parsed XML from the user that
would not be used in this case.
Reported by Ján Tomko.
virDomainSetMetadata when operating on the metadata element was
requesting the @key argument to be passed even if @metadata was NULL
used to delete the corresponding metadata element. This is not needed as
the key is only used when adding the element and matching is done via
the XML namespace.
The virDomainGetMetadata function was designed to support also retrieval
of app specific metadata from the <metadata> element. This functionality
was never implemented originally.
The function implemented common behavior that can be reused for other
hypervisor drivers that use the virDomainObj data structures. Factor out
the core into a separate helper func.
The function implemented common behavior that can be reused for other
hypervisor drivers that use the virDomainObj data structures. Factor out
the core into a separate helper func.
In the original implementation of external checkpoints I've mistakenly
used the live definition to be stored in the save image. The normal
approach is to use the "migratable" definition. This was discovered when
commit 07966f6a8b changed the behavior to
use a converted XML from the user to do the compatibility check to fix
problem when using the regular machine saving.
As the previous patch added a compatibility layer, we can now change the
type of the XML in the image.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1008340
External checkpoints have a bug in the implementation where they use the
normal definition instead of the "migratable" one. This causes errors
when the snapshot is being reverted using the workaround method via
qemuDomainRestoreFlags() with a custom XML. This issue was introduced
when commit 07966f6a8b changed the code to
compare "migratable" XMLs from the user as we should have used
migratable in the image too.
This patch adds a compatibility layer, so that fixing the snapshot code
won't make existing snapshots fail to load.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1008340
CD-ROMs and Floppies are allowed to have no source to imply they are
empty or disconnected. Since the LUN type is used for raw CD-ROM access
with QEMU (and VMWare in the future), it also needs to allow an empty
source when the raw CD-ROM device is disconnected from the domain.
qemuMigrationEatCookie has flags to control if these should
be parsed, but it does not fill mig->flags. These cookies might
get leaked if these flags are not set by qemuMigrationBakeCookie.
42 (32 direct, 10 indirect) bytes in 1 blocks are definitely lost in
loss record 361 of 662
==123== by 0x1BA33FCA: qemuMigrationEatCookie (qemu_migration.c:678)
==123== by 0x1BA34A1E: qemuMigrationRun (qemu_migration.c:3108)
==123== by 0x1BA3622B: doNativeMigrate (qemu_migration.c:3343)
==123== by 0x1BA3B408: qemuMigrationPerform (qemu_migration.c:4138)
https://bugzilla.redhat.com/show_bug.cgi?id=1008619
1,003 bytes in 1 blocks are definitely lost in loss record 599 of 635
==404== by 0x50728A7: virBufferAddChar (virbuffer.c:185)
==404== by 0x50BC466: virSystemdEscapeName (virsystemd.c:67)
==404== by 0x50BC6B2: virSystemdMakeSliceName (virsystemd.c:108)
==404== by 0x50BC870: virSystemdCreateMachine (virsystemd.c:169)
==404== by 0x5078267: virCgroupNewMachine (vircgroup.c:1498)
Bother those kernel developers. In the latest rawhide, kernel
and glibc have now been unified so that <netinet/in.h> and
<linux/in6.h> no longer clash; but <linux/if_bridge.h> is still
not self-contained. Because of the latest header change, the
build is failing with:
checking for linux/param.h... no
configure: error: You must install kernel-headers in order to compile libvirt with QEMU or LXC support
with details:
In file included from conftest.c:561:0:
/usr/include/linux/in6.h:71:18: error: field 'flr_dst' has incomplete type
struct in6_addr flr_dst;
We need a workaround to avoid our workaround :)
* configure.ac (NETINET_LINUX_WORKAROUND): New test.
* src/util/virnetdevbridge.c (includes): Use it.
Signed-off-by: Eric Blake <eblake@redhat.com>
Since virnetsocket conditionally uses selinux we need to link against it
otherwise the build fails with:
CCLD libvirtd
/usr/bin/ld: ../src/.libs/libvirt-lxc.so: undefined reference to symbol 'freecon'
/lib/i386-linux-gnu/libselinux.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[3]: *** [libvirtd] Error 1
An off-list bug report mentioned some confusion where the public
documentation of libvirt.c:virConnectGetHostname did not match
the private documentation of util/virutil.c:virGetHostname.
* src/libvirt.c (virConnectGetHostname): Tweak docs.
Signed-off-by: Eric Blake <eblake@redhat.com>
The VIR_ACCESS_PERM_CONNECT_DETECT_STORAGE_POOLS enum
constant had its string format be 'detect_storage_pool',
note the missing trailing 's'. This prevent the ACL
check from ever succeeding. Fix this and add a simple
test script to validate this problem of matching names.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Right now we mount selinuxfs even user namespace is enabled and
ignore the error. But we shouldn't ignore these errors when user
namespace is not enabled.
This patch skips mounting selinuxfs when user namespace enabled.
Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
When reverting a live internal snapshot with a live guest the ABI
compatiblity check was comparing a "migratable" definition with a normal
one. This resulted in the check failing with:
revert requires force: Target device address type none does not match source pci
This patch generates a "migratable" definition from the actual one to
check against the definition from the snapshot to avoid this problem.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1006886
This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=983026
The netcf interface driver previously had no state driver associated
with it - as a connection was opened, it would create a new netcf
instance just for that connection, and close it when it was
finished. the problem with this is that each connection to libvirt
used up a netlink socket, and there is a per process maximum of ~1000
netlink sockets.
The solution is to create a state driver to go along with the netcf
driver. The state driver will opens a netcf instance, then all
connections share that same netcf instance, thus only a single
netlink socket will be used no matter how many connections are mde to
libvirtd.
This was rather simple to do - a new virObjectLockable class is
created for the single driverState object, which is created in
netcfStateInitialize and contains the single netcf handle; instead of
creating a new object for each client connection, netcfInterfaceOpen
now just increments the driverState object's reference count and puts
a pointer to it into the connection's privateData. Similarly,
netcfInterfaceClose() just un-refs the driverState object (as does
netcfStateCleanup()), and virNetcfInterfaceDriverStateDispose()
handles closing the netcf instance. Since all the functions already
have locking around them, the static lock functions used by all
functions just needed to be changed to call virObjectLock() and
virObjectUnlock() instead of directly calling the virMutex* functions.
This better fits the modern naming scheme in libvirt, and anticipates
an upcoming change where a single instance of this state will be
maintained by a separate state driver, and every instance of the netcf
driver will share the same state.
If the guest is configured with
<filesystem type='mount'>
<source dir='/'/>
<target dir='/'/>
<readonly/>
</filesystem>
Then any submounts under / should also end up readonly, except
for those setup as basic mounts. eg if the user has /home on a
separate volume, they'd expect /home to be readonly, but we
should not touch the /sys, /proc, etc dirs we setup ourselves.
Users can selectively make sub-mounts read-write again by
simply listing them as new mounts without the <readonly>
flag set
<filesystem type='mount'>
<source dir='/home'/>
<target dir='/home'/>
</filesystem>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Move the array of basic mounts out of the lxcContainerMountBasicFS
function, to a global variable. This is to allow it to be referenced
by other methods wanting to know what the basic mount paths are.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Debian systems may run the 'systemd-logind' daemon, which causes the
/sys/fs/cgroup/systemd mount to be setup, but no other cgroup
controllers are created. While the LXC driver considers cgroups to
be mandatory, the QEMU driver is supposed to accept them as optional.
We detect whether they are present by looking in /proc/mounts for
any mounts of type 'cgroups', but this is not sufficient. We need to
skip any named mounts (as seen by a name=XXX string in the mount
options), so that we only detect actual resource controllers.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721979
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The polkit access driver used the wrong permission names for checks
on storage pools, volumes and node devices. This led to them always
being denied access.
The 'dettach' permission was also mis-spelt and should have been
'detach'. While permission names are ABI sensitive, the fact that
the code used the wrong object name for checking node device
permissions, means that no one could have used the mis-spelt
'dettach' permission.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This fixes the description of virConnectGetType() API function in
API documentation to match the real functionality that it can be
used to get driver name, and provide a hint on how to learn about
full capabilities.
Signed-off-by: Michal Novotny <minovotn@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
This patch introduces virDBusIsServiceEnabled, we can use
this method to get if the service is supported.
In one case, if org.freedesktop.machine1 is unavailable on
host, we should skip creating machine through systemd.
Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
The devpts, dev and fuse filesystems are mounted temporarily.
there is no need to export them to container if container shares
the root directory with host.
Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
Some users in Ubuntu/Debian seem to have a setup where all the
cgroup controllers are mounted on /sys/fs/cgroup rather than
any /sys/fs/cgroup/<controller> name. In the loop which detects
which controllers are present for a mount point we were modifying
'mnt_dir' field in the 'struct mntent' var, but not always restoring
the original value. This caused detection to break in the all-in-one
mount setup.
Fix that logic bug and add test case coverage for this mount
setup.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
After freeing the bitmap pointer, it must set the pointer to NULL.
This will avoid any other use of the freed memory of the bitmap pointer.
https://bugzilla.redhat.com/show_bug.cgi?id=1006710
Signed-off-by: Liuji (Jeremy) <jeremy.liu@huawei.com>
Osier Yang pointed out that ever since commit 31cb030, the
signature of qemuDomainObjEndJob was changed to return a bool.
While comparison against 0 or > 0 still gives the right results,
it looks fishy; we also had one place that was comparing < 0
which is effectively dead code.
* src/qemu/qemu_migration.c (qemuMigrationPrepareAny): Fix dead
code bug.
(qemuMigrationBegin): Use more canonical form of bool check.
* src/qemu/qemu_driver.c (qemuAutostartDomain)
(qemuDomainCreateXML, qemuDomainSuspend, qemuDomainResume)
(qemuDomainShutdownFlags, qemuDomainReboot, qemuDomainReset)
(qemuDomainDestroyFlags, qemuDomainSetMemoryFlags)
(qemuDomainSetMemoryStatsPeriod, qemuDomainInjectNMI)
(qemuDomainSendKey, qemuDomainGetInfo, qemuDomainScreenshot)
(qemuDomainSetVcpusFlags, qemuDomainGetVcpusFlags)
(qemuDomainRestoreFlags, qemuDomainGetXMLDesc)
(qemuDomainCreateWithFlags, qemuDomainAttachDeviceFlags)
(qemuDomainUpdateDeviceFlags, qemuDomainDetachDeviceFlags)
(qemuDomainBlockResize, qemuDomainBlockStats)
(qemuDomainBlockStatsFlags, qemuDomainMemoryStats)
(qemuDomainMemoryPeek, qemuDomainGetBlockInfo)
(qemuDomainAbortJob, qemuDomainMigrateSetMaxDowntime)
(qemuDomainMigrateGetCompressionCache)
(qemuDomainMigrateSetCompressionCache)
(qemuDomainMigrateSetMaxSpeed)
(qemuDomainSnapshotCreateActiveInternal)
(qemuDomainRevertToSnapshot, qemuDomainSnapshotDelete)
(qemuDomainQemuMonitorCommand, qemuDomainQemuAttach)
(qemuDomainBlockJobImpl, qemuDomainBlockCopy)
(qemuDomainBlockCommit, qemuDomainOpenGraphics)
(qemuDomainGetBlockIoTune, qemuDomainGetDiskErrors)
(qemuDomainPMSuspendForDuration, qemuDomainPMWakeup)
(qemuDomainQemuAgentCommand, qemuDomainFSTrim): Likewise.
Signed-off-by: Eric Blake <eblake@redhat.com>
Automake 2.0 will enable subdir-objects by default; in preparation
for that change, automake 1.14 outputs LOADS of warnings:
daemon/Makefile.am:38: warning: source file '../src/remote/remote_protocol.c' is in a subdirectory,
daemon/Makefile.am:38: but option 'subdir-objects' is disabled
automake-1.14: warning: possible forward-incompatibility.
automake-1.14: At least a source file is in a subdirectory, but the 'subdir-objects'
automake-1.14: automake option hasn't been enabled. For now, the corresponding output
automake-1.14: object file(s) will be placed in the top-level directory. However,
automake-1.14: this behaviour will change in future Automake versions: they will
automake-1.14: unconditionally cause object files to be placed in the same subdirectory
automake-1.14: of the corresponding sources.
automake-1.14: You are advised to start using 'subdir-objects' option throughout your
automake-1.14: project, to avoid future incompatibilities.
daemon/Makefile.am:38: warning: source file '../src/remote/lxc_protocol.c' is in a subdirectory,
daemon/Makefile.am:38: but option 'subdir-objects' is disabled
...
As automake 1.9 also supported this option, and the previous patches
fixed up the code base to work with it, it is safe to now turn it on
unconditionally.
* configure.ac (AM_INIT_AUTOMAKE): Enable subdir-objects.
* .gitignore: Ignore .dirstamp directories.
* src/Makefile.am (PDWTAGS, *-protocol-struct): Adjust to
new subdir-object location of .lo files.
Signed-off-by: Eric Blake <eblake@redhat.com>
We have been adding new .x files without keeping the list of
*-structs files up-to-date. This adds the support for the
recent additions.
In the process of testing this, I also noticed that Fedora 19's
use of dwarves-1.10 (providing pdwtags version 1.9) was producing
a single line on stderr but still giving enough useful info on
stdout that we could check structs; the real goal of checking
stderr separately from stdout was to avoid the bug in dwarves-1.9
where stdout was empty (see bug http://bugzilla.redhat.com/772358).
* src/Makefile.am (struct_prefix, PROTOCOL_STRUCTS): Add missing
struct tests.
(PDWTAGS): Work with Fedora 19 pdwtags.
(lxc_monitor_protocol-struct, lock_protocol-struct): New rules.
* src/lxc_monitor_protocol-structs: New file.
* src/lock_protocol-structs): Likewise.
* cfg.mk (generated_files): Enlarge list.
Signed-off-by: Eric Blake <eblake@redhat.com>
Trying to enable automake's subdir-objects option resulted in
the creation of literal directories such as src/$(srcdir)/remote/.
I traced this to the fact that we had used a literal $(srcdir)
in a location that later fed an automake *_SOURCES variable.
This has also been reported as an automake bug:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13928
but it's better to fix our code than to wait for an automake fix.
Some things to remember that affect VPATH builds, and where an
in-tree build is blissfully unaware of the issues: if a VPATH
build fails to find a file that was used as a prereq of any
other target, then the rule for that file will expand $@ to
prefer the current build dir (bad because a VPATH build on a
fresh checkout will then stick $@ in the current directory
instead of the desired srcdir); conversely, if a VPATH build
finds the file in srcdir but decides it needs to be rebuilt,
then the rule for that file will expand $@ to include the
directory where it was found out-of-date (bad for an explicit
listing of $(srcdir)/$@ because an incremental VPATH build will
then expand srcdir twice). As we want these files to go into
srcdir unconditionally, we have to massage or avoid $@ for any
recipe that involves one of these files.
Therefore, this patch removes all uses of $(srcdir) from any
generated file name that later feeds a *_SOURCES variable, and
then rewrites all the recipes to generate those files to
hard-code their creation into srcdir without the use of $@.
* src/Makefile.am (REMOTE_DRIVER_GENERATED): Drop $(srcdir); VPATH
builds know how to find the files, and automake subdir-objects
fails with it in place.
(LXC_MONITOR_PROTOCOL_GENERATED, (LXC_MONITOR_GENERATED)
(ACCESS_DRIVER_GENERATED, LOCK_PROTOCOL_GENERATED): Likewise.
(*_client_bodies.h): Hard-code rules to write into srcdir, as
VPATH tries to build $@ locally if missing.
(util/virkeymaps.h): Likewise.
(lxc/lxc_monitor_dispatch.h): Likewise.
(access/viraccessapi*): Likewise.
(locking/lock_daemon_dispatch_stubs.h): Likewise.
* daemon/Makeflie.am (DAEMON_GENERATED, remote_dispatch.h):
Likewise.
Signed-off-by: Eric Blake <eblake@redhat.com>
fixup DAEMON_GENERATED
Failure to attach to a domain during 'virsh qemu-attach' left
the list of domains in an odd state:
$ virsh qemu-attach 4176
error: An error occurred, but the cause is unknown
$ virsh list --all
Id Name State
----------------------------------------------------
2 foo shut off
$ virsh qemu-attach 4176
error: Requested operation is not valid: domain is already active as 'foo'
$ virsh undefine foo
error: Failed to undefine domain foo
error: Requested operation is not valid: cannot undefine transient domain
$ virsh shutdown foo
error: Failed to shutdown domain foo
error: invalid argument: monitor must not be NULL
It all stems from leaving the list of domains unmodified on
the initial failure; we should follow the lead of createXML
which removes vm on failure (the actual initial failure still
needs to be fixed in a later patch, but at least this patch
gets us to the point where we aren't getting stuck with an
unremovable "shut off" transient domain).
While investigating, I also found a leak in qemuDomainCreateXML;
the two functions should behave similarly. Note that there are
still two unusual paths: if dom is not allocated, the user will
see an OOM error even though the vm remains registered (but oom
errors already indicate tricky cleanup); and if the vm starts
and then quits again all before the job ends, it is possible
to return a non-NULL dom even though the dom will no longer be
useful for anything (but this at least lets the user know their
short-lived vm ran).
* src/qemu/qemu_driver.c (qemuDomainCreateXML): Don't leak vm on
failure to obtain job.
(qemuDomainQemuAttach): Match cleanup of qemuDomainCreateXML.
Signed-off-by: Eric Blake <eblake@redhat.com>
ARM v7 can operate in either little or big endian modes. Add
support for the big-endian version known as armv7b from uname.
Signed-off-by: Yogesh Tillu <tillu.yogesh@gmail.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Currently, only X86 provides users CPU features with CPUID instruction.
If users specify the features for non-x86, it should tell users to
remove them.
This patch is to report one error if features are specified by
users for non-x86 platform.
Signed-off-by: Li Zhang <zhlcindy@linux.vnet.ibm.com>
