Mostly straight-forward, although this is the first API that
returns a new snapshot based on a snapshot rather than a domain.
* src/remote/remote_protocol.x
(REMOTE_PROC_DOMAIN_SNAPSHOT_GET_PARENT): New rpc.
(remote_domain_snapshot_get_parent_args)
(remote_domain_snapshot_get_parent_ret): New structs.
* src/rpc/gendispatch.pl: Adjust generator.
* src/remote/remote_driver.c (remote_driver): Use it.
* src/remote_protocol-structs: Update.
Although a client can already obtain a snapshot's parent by
dumping and parsing the xml, then doing a snapshot lookup by
name, it is more efficient to get the parent in one step, which
in turn will make operations that must traverse a snapshot
hierarchy easier to perform.
* include/libvirt/libvirt.h.in (virDomainSnapshotGetParent):
Declare.
* src/libvirt.c (virDomainSnapshotGetParent): New function.
* src/libvirt_public.syms: Export it.
* src/driver.h (virDrvDomainSnapshotGetParent): New callback.
Coupled with the recent virsh nodedev-* doc patch, this should now
give a better picture of libvirt node device handling.
* docs/formatnode.html.in: Fill in page.
This section of the man page was completely missing; I stumbled on
it when I had no clue that I had to use nodedev-reattach after
I was done playing with <hostdev> device passthrough to one of my
guests.
* tools/virsh.pod (NODEDEV COMMANDS): New section.
(attach-device, detach-device): Add cross-references.
This patch fixes the regression with using named pipes for qemu serial
devices noted in:
https://bugzilla.redhat.com/show_bug.cgi?id=740478
The problem was that, while new code in libvirt looks for a single
bidirectional fifo of the name given in the config, then relabels that
and continues without looking for / relabelling the two unidirectional
fifos named ${name}.in and ${name}.out, qemu looks in the opposite
order. So if the user had naively created all three fifos, libvirt
would relabel the bidirectional fifo to allow qemu access, but qemu
would attempt to use the two unidirectional fifos and fail (because it
didn't have proper permissions/rights).
This patch changes the order that libvirt looks for the fifos to match
what qemu does - first it looks for the dual fifos, then it looks for
the single bidirectional fifo. If it finds the dual unidirectional
fifos first, it labels/chowns them and ignores any possible
bidirectional fifo.
(Note commit d37c6a3a (which first appeared in libvirt-0.9.2) added
the code that checked for a bidirectional fifo. Prior to that commit,
bidirectional fifos for serial devices didn't work because libvirt
always required the ${name}.(in|out) fifos to exist, and qemu would
always prefer those.
If a domain started with -no-shutdown shuts down while libvirtd is not
running, it will be seen as paused when libvirtd reconnects to it. Use
the paused reason to detect if a domain was stopped because of shutdown
and finish the process just as if a SHUTDOWN event is delivered from
qemu.
The AppArmor security driver adds only the path specified in the domain
XML for character devices of type 'pipe'. It should be using <path>.in
and <path>.out. We do this by creating a new vah_add_file_chardev() and
use it for char devices instead of vah_add_file(). Also adjust
valid_path() to accept S_FIFO (since qemu chardevs of type 'pipe' use
fifos). This is https://launchpad.net/bugs/832507
This patch cleans the cpu baseline function using new libvirt helper
functions and fixes XPath expression that selects <cpu> elements from
the source file, that can contain concatenated <capabilities> XMLs,
domain XMLs and bare <cpu> elements. The fixed XPath expression ensures
not to select NUMA <cpu id=... elements.
This patch also removes vshRealloc function, that remained unused after
cleaning up cpu-baseline.
https://bugzilla.redhat.com/show_bug.cgi?id=731645
pod2man from perl-5.8.8 (RHEL 5) errors out on ill-formed POD:
*** ERROR: unterminated I<...> at line 1114 in file virsh.pod
*** ERROR: unterminated I<...> at line 1851 in file virsh.pod
Newer pod2man appears to be more tolerant (which is a shame,
because it meant that this error is harder to detect).
* tools/virsh.pod (undefine, snapshot-current): Add missing >.
This patch was made in response to:
https://bugzilla.redhat.com/show_bug.cgi?id=738095
In short, qemu's default for the rombar setting (which makes the
firmware ROM of a PCI device visible/not on the guest) was previously
0 (not visible), but they recently changed the default to 1
(visible). Unfortunately, there are some PCI devices that fail in the
guest when rombar is 1, so the setting must be exposed in libvirt to
prevent a regression in behavior (it will still require explicitly
setting <rom bar='off'/> in the guest XML).
rombar is forced on/off by adding:
<rom bar='on|off'/>
inside a <hostdev> element that defines a PCI device. It is currently
ignored for all other types of devices.
At the moment there is no clean method to determine whether or not the
rombar option is supported by QEMU - this patch uses the advice of a
QEMU developer to assume support for qemu-0.12+. There is currently a
patch in the works to put this information in the output of "qemu-kvm
-device pci-assign,?", but of course if we switch to keying off that,
we would lose support for setting rombar on all the versions of qemu
between 0.12 and whatever version gets that patch.
Commit ecd8725c dropped attempts to probe the cgconfig service on
new enough Fedora where systemd took over that aspect of the system,
but mistakenly used F14 instead of F15 as the cutoff point.
https://bugzilla.redhat.com/show_bug.cgi?id=741358
Also, RHEL does not include HyperV support yet.
* libvirt.spec.in (with_cgconfig): Check cgconfig service in F15.
(%{?rhel}): Provide default for with_hyperv.
SIGTERM handling for -no-shutdown is already fixed in qemu git and
libvirt can safely use it. The downside is that 0.15.50 version of qemu
can be any qemu compiled from git, even that without the fix for
SIGTERM. However, I think this patch is worth it since excluding 0.15.50
from the check makes testing current qemu with libvirt much easier and
someone running qemu from git should be able to rebuild fixed qemu from
git if they hit the problem with a hang on shutdown.
Some virsh commands start a (long-running) job that can be monitored
using domjobinfo and aborted with domjobabort. Let's be explicit about
this in virsh man page.
* src/storage/storage_driver.c: As virStorageVolLookupByPath lookups
all the pool objs of the drivers, breaking when failing on getting
the stable path of the pool will just breaks the whole lookup process,
it can cause the API fails even if the vol exists indeed. It won't get
any benefit. This patch is to fix it.
QEMU 0.13 introduced cache=unsafe for -drive, this patch exposes
it in the libvirt layer.
* Introduced a new QEMU capability flag ($prefix_CACHE_UNSAFE),
as even if $prefix_CACHE_V2 is set, we can't know if unsafe
is supported.
* Improved the reliability of qemu cache type detection.
commit 984840a2c2 removed the
notification of waiting calls when VIR_NET_CONTINUE messages
arrive. This was to fix the case of a virStreamAbort() call
being prematurely notified of completion.
The problem is that sometimes there are dummy calls from a
virStreamRecv() call waiting that *do* need to be notified.
These dummy calls should have a status VIR_NET_CONTINUE. So
re-add the notification upon VIR_NET_CONTINUE, but only if
the waiter also has a status of VIR_NET_CONTINUE.
* src/rpc/virnetclient.c: Notify waiting call if stream data
arrives
* src/rpc/virnetclientstream.c: Mark dummy stream read packet
with status VIR_NET_CONTINUE
Commit 0a22f54 added --min-guarantee option for the memtune command.
This option is supported only by the ESX hypervisor. This patch adds a
statement about this fact, to prevent user confusion.
This patch also adds explanation how to clear/set to unlimited the
memory tunables. (documments the -1 value).
If a domain has inactive XML we want to transfer it to destination
when migrating with VIR_MIGRATE_PERSIST_DEST. In order to harm
the migration protocol as least as possible, a optional cookie was
chosen.
The previous patch removed all snapshots, but not the directory
where the snapshots lived, which is still a form of stale data.
* src/qemu/qemu_domain.c (qemuDomainRemoveInactive): Wipe any
snapshot directory.
Commit 282fe1f0 documented that transient domains will auto-delete
any snapshot metadata when the last reference to the domain is
removed, and that management apps are in charge of grabbing any
snapshot metadata prior to that point. However, this was not
actually implemented for qemu until now.
* src/qemu/qemu_driver.c (qemudDomainCreate)
(qemuDomainDestroyFlags, qemuDomainSaveInternal)
(qemudDomainCoreDump, qemuDomainRestoreFlags, qemudDomainDefine)
(qemuDomainUndefineFlags, qemuDomainMigrateConfirm3)
(qemuDomainRevertToSnapshot): Clean up snapshot metadata.
* src/qemu/qemu_migration.c (qemuMigrationPrepareAny)
(qemuMigrationPerformJob, qemuMigrationPerformPhase)
(qemuMigrationFinish): Likewise.
* src/qemu/qemu_process.c (qemuProcessHandleMonitorEOF)
(qemuProcessReconnect, qemuProcessReconnectHelper)
(qemuProcessAutoDestroyDom): Likewise.
This patch is mostly code motion - moving some functions out
of qemu_driver and into qemu_domain so they can be reused by
multiple qemu_* files (since qemu_driver.h must not grow).
It also adds a new helper function, qemuDomainRemoveInactive,
which will be used in the next patch.
* src/qemu/qemu_domain.h (qemuFindQemuImgBinary)
(qemuDomainSnapshotWriteMetadata, qemuDomainSnapshotForEachQcow2)
(qemuDomainSnapshotDiscard, qemuDomainSnapshotDiscardAll)
(qemuDomainRemoveInactive): New prototypes.
(struct qemu_snap_remove): New struct.
* src/qemu/qemu_domain.c (qemuDomainRemoveInactive)
(qemuDomainSnapshotDiscardAllMetadata): New functions.
(qemuFindQemuImgBinary, qemuDomainSnapshotWriteMetadata)
(qemuDomainSnapshotForEachQcow2, qemuDomainSnapshotDiscard)
(qemuDomainSnapshotDiscardAll): Move here...
* src/qemu/qemu_driver.c (qemuFindQemuImgBinary)
(qemuDomainSnapshotWriteMetadata, qemuDomainSnapshotForEachQcow2)
(qemuDomainSnapshotDiscard, qemuDomainSnapshotDiscardAll): ...from
here.
(qemuDomainUndefineFlags): Update caller.
* src/conf/domain_conf.c (virDomainRemoveInactive): Doc fixes.
Commit 19f8c98 introduced VIR_DOMAIN_UNDEFINE_SNAPSHOTS_METADATA,
with the intent that omitting the flag makes undefine fail, and
including the flag deletes metadata. But it used the wrong logic.
Also, hoist the transient domain sooner, so that we don't
accidentally remove metadata of a transient domain.
* src/qemu/qemu_driver.c (qemuDomainUndefineFlags): Check correct
flag value.
Detected by Coverity. The only way to get to error_unlink is if
path was successfully assigned, so the if was useless. Meanwhile,
there was a return statement that did not free path.
* src/locking/lock_driver_sanlock.c
(virLockManagerSanlockSetupLockspace): Fix mem-leak, and drop
useless if.
Prior to commit 85d2810, we had an issue where:
snapshot-create-as dom name --diskspec spec --diskspec spec
failed to parse the second spec, because the first spec had marked
that option as no longer requiring an argument.
In commit 85d2810, I fixed it by making argv options no longer mark
the option as seen. But this in turn breaks mandatory argv options,
which now complain that the argv option is missing.
This patch reverts that part of 85d2810, and instead replaces it with
fixes to no longer clear opts_need_arg of an argv argument.
* tools/virsh.c (vshCmddefGetOption, vshCmddefGetData)
(vshCommandParse): Fix option parsing for required argv option.
(vshCmddefOptParse): Check that argv option is last.
* tests/virsh-optparse: Enhance test.
There are 3 ways to lookup a volume, only virStorageVolLookupByName
needs pool object. So if no --pool is specified, it will tries to
get the volume via virStorageVolLookupByPath/virStorageVolLookupByKey.
But if all 3 ways fails, and no --pool is specified, a friendly
error might help the user get right way quickly.
Related #BZ: https://bugzilla.redhat.com/show_bug.cgi?id=702260.
There are two problems described in the BZ:
1) "Can't remove open logical volume".
2) "Unable to deactivate logical volume "foo""
This patch just intends to fix 2), as 1) is expected if the vol
is still used by something, and you never known if "lvchange -an"
will fail or not either (sometime, it will succeed, sometimes not).
We'd better not look for trouble, :-)
For 2), that's caused by race between lvremove and udev event handling,
the only workable way now is to wait the events handling are finished,
though it might introduce latencies, as "udevadmin settle" exits
after *all* events are handled, it's the only way we can fix
the racing in libvirt layer.
See https://bugzilla.redhat.com/show_bug.cgi?id=570359 for more
details.
* src/qemu/qemu_process.c: Taking if (qemuDomainObjEndJob(driver, obj) == 0)
true branch then 'obj' is NULL, virDomainObjIsActive(obj) and
virDomainObjUnref(obj) will dereference NULL pointer.
Signed-off-by: Alex Jia <ajia@redhat.com>
Once virDomainReboot is called for a domain, guest OS initiated shutdown
would always result in reboot instead of shutdown. Only
virDomainShutdown would actually shutd such domain down. That's because
we forgot to reset fakeReboot flag once we asked the domain to reboot.
The commit that prevents disk corruption on domain shutdown
(96fc478417) causes regression with QEMU
0.14.* and 0.15.* because of a regression bug in QEMU that was fixed
only recently in QEMU git. The affected versions of QEMU do not quit on
SIGTERM if started with -no-shutdown, which we use to implement fake
reboot. Since -no-shutdown tells QEMU not to quit automatically on guest
shutdown, domains started using the affected QEMU cannot be shutdown
properly and stay in a paused state.
This patch disables fake reboot feature on such QEMU by not using
-no-shutdown, which makes shutdown work as expected. However,
virDomainReboot will not work in this case and it will report "Requested
operation is not valid: Reboot is not supported with this QEMU binary".
Bug introduced in commit 675464b. On an OOM, this would try to
dereference a char* and free the contents as a pointer, which is
doomed to failure.
Adding a syntax check will prevent mistakes like this in the future.
* cfg.mk (sc_prohibit_internal_functions): New syntax check.
(exclude_file_name_regexp--sc_prohibit_internal_functions): Add
exemptions.
* daemon/remote.c (remoteRelayDomainEventIOError)
(remoteRelayDomainEventIOErrorReason)
(remoteRelayDomainEventGraphics, remoteRelayDomainEventBlockJob):
Use correct free function.
The next patch will add a syntax check that flags this usage in xen
as awkward - while it was valid memory management, it was very hard
to maintain. Swapping to a more traditional allocation may be a bit
slower, but easier to understand.
* src/xen/xend_internal.c (xenDaemonListDomainsOld): Use two-level
allocation, rather than abusing allocation function.
(xenDaemonLookupByUUID): Update caller.
gcc warns when building libvirt 0.9.5 on a 32-bit machine:
qemu/qemu_migration.c: In function 'qemuMigrationToFile':
qemu/qemu_migration.c:2727:38: error: large integer implicitly truncated to unsigned type [-Woverflow]
* src/qemu/qemu_domain.h (QEMU_DOMAIN_FILE_MIG_BANDWIDTH_MAX): Cap
to long when building for 32-bit platform.
remoteRelayDomainEventBlockJob, remoteRelayDomainEventIOError,
remoteRelayDomainEventIOErrorReason and remoteRelayDomainEventGraphics
were using const string directly in rpc structure, before calling
remoteDispatchDomainEventSend(). But that routine now frees up all
the pointed allocated memory from the rpc structure and we end up
with a double free.
This now strdup() all the strings passed and provide mem_error goto
labels to be used when an allocation error occurs.
Note that the cleanup isn't completely finished because all relaying
function also call make_nonnull_domain() which also allocate a string
and never handle the error case. This patches doesn't try to address
this as this is only error correctness a priori and touches far more
functions in this module:
* daemon/remote.c: fix string allocations and memory error handling
for remoteRelayDomainEventBlockJob, remoteRelayDomainEventIOError,
remoteRelayDomainEventIOErrorReason and remoteRelayDomainEventGraphics
Inexplicably the sanlock code all got placed under the GPLv2-only,
so libvirt's use of sanlock introduces a license incompatibility.
The sanlock developers have now rearranged the code such that there
is a 'sanlock_client.so' which is LGPLv2+ while their daemon remains
GPLv2-only. To use the new client library we need to call the new
sanlock_init and sanlock_align APIs instead of sanlock_direct_init
and sanlock_direct_align. These APIs calls are now routed via the
sanlock daemon, instead of doing direct I/O calls to disk.
For all this we require sanlock >= 1.8
* configure.ac: Check for sanlock_client.so instead of sanlock.so
and fix various comments
* libvirt.spec.in: Mandate sanlock >= 1.8
* src/Makefile.am: Link to -lsanlock_client
* src/locking/lock_driver_sanlock.c: Use sanlock_init and
sanlock_align
