Eventually, every driver will be moved to a special module.
But for today the winner is Virtuozzo driver.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

After Jirka's migration patches libvirt is listening on migration
events from qemu instead of actively polling on the monitor. There is,
however, a little regression (introduced in 6d2edb6a). The
problem is, the current status of migration job is updated in
qemuProcessHandleMigrationStatus if and only if migration job was
started. But eventually every asynchronous job may result in
migration. Therefore, since this job is not strictly a
migration job, internal state was not updated and later checks failed:

  virsh # save fedora22 /tmp/fedora22_ble.save
  error: Failed to save domain fedora22 to /tmp/fedora22_ble.save
  error: operation failed: domain save job: is not active
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Commit 45697fe5 added dom0 to driver->domains, but missed
setting its state to 'running'

$ virsh list
 Id    Name                           State
----------------------------------------------------
 0     Domain-0                       shut off

We create a virtual network of special type, which
has the same name as bridge name to create bridged
network adapter in vz. So when we delete such an
adapter we have to remove corresponding virtual
network.

So let's rename prlsdkDelNet to prlsdkCleanupBridgedNet
and don't check for return value.
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>

When QEMU exits on destination during migration, the source reports
either success (if the failure happened at the very end) or unhelpful
"unexpectedly failed" error message. However, the Finish API called on
the destination may report a real error so let's use it instead of the
generic one.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

virDomainMigrateFinish* APIs were unfortunately designed to return the
pointer to the domain on destination and NULL on error. This looks OK in
normal cases but the same API is also called when we know migration
failed and thus we expect Finish to return NULL even if it actually did
all it was supposed to do without any error. The call is defined to
return nonnull domain pointer over RPC, which means returning NULL will
always result in an error being send. If this was not in fact an error,
the API itself wouldn't set anything to the thread local virError, which
makes the RPC layer come up with it's own "Library function returned
error but did not set virError" error.

This is quite confusing and also hard to detect by the caller. This
patch adds a special error code which can be used to check that Finish
successfully aborted migration.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

If QEMU fails during incoming migration, the domain disappears including
a possibly useful error message read from QEMU log file. Let's remember
the error in virQEMUDriver so that Finish can report more than just "no
such domain".
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

A helper function for copying error objects.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

This is a self-locking wrapper around virHashTable. Only a limited set
of APIs are implemented now (the ones which are used in the following
patch) as more can be added on demand.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Corresponding QEMU commits:
    MPX     79e9ebebbf2a00c46fcedb6dc7dd5e12bbd30216
    AVX512  9aecd6f8aef653cea58932f06a2740299dbe5fd3
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

With commit 3f9868a5 virt-aa-helper stopped working due to missing
DomainGuest in the caps.

The test with -c without arch also needs to be
removed since the new capabilities code uses the host arch when none is
provided.

ctl->hvm contains os.type string value, change the name to reflect it.

Initializing libvirt log in virt-aa-helper and getting it to output
libvirt log to stderr. This will help debugging problems happening in
libvirt functions called from within virt-aa-helper

Rules generated for a path like '/' were having '//' which isn't
correct for apparmor. Make virt-aa-helper smarter to avoid these.

Daemon used false logic for determining whether there were any clients.
When the timer was inactive, it was activated if at least one of the
servers did not have clients.  So the bool was being flipped there and
back all the time in case there was one client, for example.

Initially introduced by fa142073.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1240283Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

So callers don't have to iterate over each server.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

In commit 714b38cb I tried to avoid
having two disks with the same WWN in a VM. I forgot to check the
hotplug paths though which make it possible bypass that check. Reinforce
the fix by checking the wwn when attaching the disk.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1208009

When virsh vol-clone is attempted on a raw file where capacity > allocation,
the resulting cloned volume has a size that matches the virtual-size of
the parent; in place of matching its actual, disk size.
This patch fixes the cloned disk to have same _allocated_size_ as
the parent file from which it was cloned.

Ref: http://www.redhat.com/archives/libvir-list/2015-May/msg00050.html

Also fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1130739Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Instead of storing the remaining bytes, store the position of the first
unallocated byte. This will allow changing the amount of bytes copied
by virStorageBackendCopyToFD without changing the safezero call.

No functional impact.

Libvirt's error messages do not end with a LF. However, when reading the
error from QEMU log, we would read the LF from the log and keep it in
the message.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Since we already support the MIGRATION event, we just need to make sure
the domain condition is signalled whenever a p2p connection drops or the
domain is paused due to IO error and we can avoid waking up every 50 ms
to check whether something happened.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

We don't need to call query-migrate every 50ms when we get the current
migration state via MIGRATION event.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

When QEMU supports migration events the qemuDomainJobInfo structure will
no longer be updated with migration statistics. We have to enter a job
and explicitly ask QEMU every time virDomainGetJob{Info,Stats} is
called.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Even if QEMU supports migration events it doesn't send them by default.
We have to enable them by calling migrate-set-capabilities. Let's enable
migration events everytime we can and clear QEMU_CAPS_MIGRATION_EVENT in
case migrate-set-capabilities does not support events.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Thanks to Juan's work QEMU finally emits an event whenever migration
state changes.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

This fixes

  CC     qemu/libvirt_driver_qemu_impl_la-qemu_conf.lo
  qemu/qemu_conf.c: In function 'qemuRemoveSharedDevice':
  qemu/qemu_conf.c:1384:9: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized]

Some guests lock the tray and QEMU eject command will simply fail to
eject the media.  But the guest OS can handle this attempt to eject the
media and can unlock the tray and open it. In this case, we should try
again to actually eject the media.

If the first attempt fails to detect a tray_open we will fail with
error, from monitor.  If we receive that event, we know, that the guest
properly reacted to the eject request, unlocked the tray and opened it.
In this case, we need to run the command again to actually eject the
media from the device.  The reason to call it again is, that QEMU
doesn't wait for the guest to react and report an error, that the tray
is locked.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1147471Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Modify the eject monitor functions to parse the return code and detect,
whether the error contains "is locked" to report this type of failure to
upper layers.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

There are multiple consumers for the domain condition and we should
always wake them all.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

We should distinguish between success and timeout, to let the user
handle those two events differently.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Before:

 # virsh blockjob r7 vdc
 error: An error occurred, but the cause is unknown

After:

 # virsh blockjob r7 vdc
 error: Disk 'vdc' not found in the domain

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1241355Signed-off-by: NLuyao Huang <lhuang@redhat.com>

https://bugzilla.redhat.com/show_bug.cgi?id=1142631

Commit id 'e0e29055' added a check to determine if the same bus
had the same target value.  It seems that's not quite good enough
as the check should check the target name value regardless of bus type.

Also added a DO_TEST_DIFFERENT to exhibit the issue

This patch reverts commit 4749d82a which tried to tweak the logic in
volume creation. We did realloc and update our object list before we executed
volume building within a specific storage backend. If that failed, we
had to update (again) our object list to the original state as it was before the
build and delete the volume from the pool (even though it didn't exist - this
truly depends on the backend).
I misunderstood the base idea to be able to poll the status of the volume
creation using vol-info. After commit 4749d82a this wasn't possible
anymore, although no BZ has been reported yet.

Commit 4749d82a also claimed to fix
https://bugzilla.redhat.com/show_bug.cgi?id=1223177, but commit c8be606b of the
same series as 4749d82ad (which was more of a refactor than a fix)
fixes the same issue so the revert should be pretty straightforward.
Further more, BZ https://bugzilla.redhat.com/show_bug.cgi?id=1241454 can be
fixed with this revert.

Setting of 'val' is a boolean expression, so handle it that way and
adjust the check/return logic to be clearer
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Set to ret = -1 and prove otherwise, like usual
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Since a future patch will need the device path generated when adding a
shared host device, remove the qemuAddSharedHostdev and inline the two
calls into qemuAddSharedHostdev and qemuRemoveSharedHostdev
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Split out the current function in order to share the code with hostdev
in a future patch. Failure to match the expected sgio value against what
is stored will cause an error which the caller would need to handle since
only the caller has the disk (or eventually hostdev) specific data in
order to uniquely identify the disk in an error message.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Set the state of virDomainObj in the functions that
actually change the domain state, instead of the generic
libxlDomainCleanup function. This approach gives functions
calling libxlDomainCleanup more flexibility wrt when and
how they change virDomainObj state via virDomainObjSetState.

The prior approach of calling virDomainObjSetState in
libxlDomainCleanup resulted in the following incorrect
coding pattern in the various functions that change
domain state

 libxlDomain<DoStateTransition>
   call libxl function to do state transition
   emit lifecycle event
   libxlDomainCleanup
     virDomainObjSetState

Once simple manifestation of this bug is seeing a domain
running in virt-manager after selecting the shutdown button,
even after the domain has long shutdown.

In Xen, dom0 is really just another domain that supports ballooning,
adding/removing devices, changing vcpu configuration, etc. This patch
adds support to the libxl driver for managing dom0. Note that the
legacy xend driver has long supported managing dom0.

Operations that are not supported on dom0 are filtered in libvirt
where a sensible error is reported. Errors from libxl are not
always helpful. E.g., attempting a save on dom0 results in

2015-06-23 15:25:05 MDT libxl: debug: libxl_dom.c:1570:libxl__toolstack_save: domain=0 toolstack data size=8
2015-06-23 15:25:05 MDT libxl: debug: libxl.c:979:do_libxl_domain_suspend: ao 0x7f7e68000b70: inprogress: poller=0x7f7e68000930, flags=i
2015-06-23 15:25:05 MDT libxl-save-helper: debug: starting save: Success
2015-06-23 15:25:05 MDT xc: detail: xc_domain_save_suse: starting save of domid 0
2015-06-23 15:25:05 MDT xc: error: Couldn't map live_shinfo (3 = No such process): Internal error
2015-06-23 15:25:05 MDT xc: detail: Save exit of domid 0 with errno=3
2015-06-23 15:25:05 MDT libxl-save-helper: debug: complete r=1: No such process
2015-06-23 15:25:05 MDT libxl: error: libxl_dom.c:1876:libxl__xc_domain_save_done: saving domain: domain did not respond to suspend request: No such process
2015-06-23 15:25:05 MDT libxl: error: libxl_dom.c:2033:remus_teardown_done: Remus: failed to teardown device for guest with domid 0, rc -8
Signed-off-by: NJim Fehlig <jfehlig@suse.com>