Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

This helper has solely to do with virObjects. Move it together with
other virObject stuff.

This also avoids the potential problem where VIR_AUTOUNREF uses
virObjectAutoUnref which is defined in virobject.h.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Now that all the examples are warning free, keep it that way by enabling
all the normal compiler warning flags.
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The example currently assumes that a NULL URI will open Xen and thus
also assumes that a domain with ID 0 exists. Change it to require the
URI and a domain name as command line arguments.
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Jumping over the declaration and initialization of a variable is bad as
it means the jump target sees a potentially non-initialized variable.
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

libvirt.org/search.php drops into some kind of screen which I guess
is supposed to show a search bar with options, but presently for me
renders as nothing but the following text:

Search the documentation on Libvirt.org

The search service indexes the libvirt APIs and documentation as well as the libvir-list@redhat.com mailing-list archives. To use it simply provide a set of keywords:

The main page search bar now redirects to google, this page is broken,
I say we just remove it and move on.
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

This was used for generating the website search, which now just calls
out to google. Remove it
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

The website search is perpetually broken, has had XSS issues in the
past, and I suspect when it's working it's not as fast or capable as
a simple google site:libvirt.org search

Replace the <form> implementation with one that sends the user to
google.com with 'site:libvirt.org' appended to the search string
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

Acked-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

Acked-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

Acked-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

Acked-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

If we see it, skip all remaining header guard checks
Acked-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

Acked-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

In a constrained CI environment, where it is intentional that attempts
to write outside the current directory will fail, virsh-snapshot was
failing:

@@ -1,2 +1,3 @@
 error: invalid argument: parent s3 for snapshot s2 not found
 error: marker
+error: Failed to create '/home/travis/.cache/libvirt/virsh': Permission denied
FAIL virsh-snapshot (exit status: 1)

But we've already solved the problem in virsh-uriprecedence: tell
virsh to use XDG locations pointing to somewhere we can write rather
than its default of falling back to $HOME with the test being at risk
of breaking due to the user's environment and/or unacceptably altering
the user's normal cache.  Hoist that solution into test-lib.sh, so
that all scripts can use it as needed. While at it, fix a latent typo
where XDG_RUNTIME_HOME was set to a literal relative directory name
"XDG_CACHE_HOME" (the typo did not affect virsh-uriprecedence, but
could matter to other clients).

Fixes: 280a2b41
Fixes: 398de147Reported-by: NDaniel P. Berrangé <berrange@redhat.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

The search.cpan.org site is a transparent redirect to metacpan.org these
days, so we should just point directly to the new site.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

On the modern internet it is not credible to continue to advertize
software downloads over unencrypted connections. Even if users could
theoretically use GPG to verify the signatures, not all our downloads
are signed and few people know how to correctly verify signatures.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NCole Robinson <crobinso@redhat.com>

There are a few differences, but the one we're interested in is
that PCIe Root Ports are finally available: as a result of this,
our riscv64-virt-headless guest will switch from virtio-mmio to
virtio-pci.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NCole Robinson <crobinso@redhat.com>

The rules are the same for all virt guests, regardless of the
architecture.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NCole Robinson <crobinso@redhat.com>

Our PCIe topology depends on the availability of PCIe Root Ports,
so if none of the suitable devices (pcie-root-port, ioh3420) is
compiled into QEMU we should fall back to virtio-mmio rather than
trying to use PCI addresses only to fail immediately afterwards
when we realize we can't use the necessary controllers.

Note that this additional check is basically moot for ARM virt
guests, because PCIe Root Ports were enabled in QEMU builds for
the architecture well before guest OS support had been widely
available; however, the opposite is true for RISC-V, and tweaking
the code this way will allow us to share it between architectures.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NCole Robinson <crobinso@redhat.com>

If the console was disconnected due to a connection problem or a problem on the
server side it is convinient to provide the cause to the user. If the error
come from the API then the error is saved in a virsh global variable. However,
since success is returned from virshRunConsole after we reach the waiting stage,
then the error is never reported. Let's track the error in the event loop.

Next after failure we do a cleanup and this cleanup can overwrite
root cause. Thus let's save root cause immediately and then set it to
virsh error after all cleanup is done.

Since we'll be sending the error to the consumer, each failure path from
the event handlers needs to be augmented to provide what error generated
the failure.
Reviewed-by: NCole Robinson <crobinso@redhat.com>
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

On error in main thread virConsoleShutdown is called which
deletes fd watches/stream callback and yet callbacks can
be called after. Thus we can incorrectly allocate
terminalToStream.data memory and get memory leak for example.
Let's check if console was shutdown in the very beginning of
callbacks.
Reviewed-by: NCole Robinson <crobinso@redhat.com>
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Stream/fd callbacks accessing console object are called from the
event loop thread and the console object is also accessed from
the main thread so we are better add locking to handlers.
Reviewed-by: NCole Robinson <crobinso@redhat.com>
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

We only check now for virObjectWait failures in virshRunConsole but
we'd better check and for other failures too. And we need to shutdown
console on error in the main thread.
Reviewed-by: NCole Robinson <crobinso@redhat.com>
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

We need to turn console into virObject object because stream/fd callbacks
can be called from the event loop thread after freeing console
in main thread. It is convinient to turn into virLockableObject as
we have mutex in console object.
Reviewed-by: NCole Robinson <crobinso@redhat.com>
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Since the STOP event handler can use the pausedReason as sent to
qemuProcessStopCPUs, we no longer need to send duplicate suspended
lifecycle events because we know what caused the stop along with extra
details. This processing allows us to also remove the duplicated state
change from qemuProcessStopCPUs.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Map is based on existing cases in code where we send suspended
event after changing domain state to paused.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Similar to commit [1] which saves and passes the running reason to
the RESUME event handler, during qemuProcessStopCPUs let's save and pass
the pause reason in the domain private data so that the STOP event
handler can use it.

[1] 5dab984e : qemu: Pass running reason to RESUME event handler
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

If there are two concurrent threads, one of which is removing an
nwfilter from the list and the other is trying to add it back they
may serialize in the following order:

1) obj->removing is set and @obj is unlocked.
2) The tread that's trying to add the nwfilter onto the list locks
   the list and tries to find, if the nwfilter already exists.
3) Our lookup functions say it doesn't, so the thread proceeds to
   virHashAddEntry() which fails with 'Duplicate key' error.

This is obviously not helpful error message at all.

The problem lies in our lookup function
(virNWFilterBindingObjListFindByPortDevLocked()) which return
NULL even if the object is still on the list. They do this so
that the object is not mistakenly looked up by some API. The fix
consists of moving 'removing' check one level up and thus
allowing virNWFilterBindingObjListAddLocked() to produce
meaningful error message.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NCole Robinson <crobinso@redhat.com>

If there are two concurrent threads, one of which is removing a
domain from the list and the other is trying to add it back they
may serialize in the following order:

1) vm->removing is set and @vm is unlocked.
2) The tread that's trying to add the domain onto the list locks
   the list and tries to find, if the domain already exists.
3) Our lookup functions say it doesn't, so the thread proceeds to
   virHashAddEntry() which fails with 'Duplicate key' error.

This is obviously not helpful error message at all.

The problem lies in our lookup functions
(virDomainObjListFindByUUIDLocked() and
virDomainObjListFindByNameLocked()) which return NULL even if the
object is still on the list. They do this so that the object is
not mistakenly looked up by some driver. The fix consists of
moving 'removing' check one level up and thus allowing
virDomainObjListAddLocked() to produce meaningful error message.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NCole Robinson <crobinso@redhat.com>

Add native guest format of BSD hypervisor and VMware/ESX. Quote native
guest format of domxml-from-native for domxml-to-native.
Reviewed-by: NCole Robinson <crobinso@redhat.com>
Signed-off-by: NHan Han <hhan@redhat.com>

We have more modern replacements.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Parsing of the cpu affinity list was using virParseNumber. Modernize it
to get rid of the virParseNumber call.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

'cpumasklen' is only written to since ee7d23ba.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Unused since 3c269b51Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

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

Up until memfd introduction (in 24b74d18) we did not need to
know @pagesize because qemuGetDomainHupageMemPath() could deal
with it being zero (value of zero means use the default hugetlbfs
mount). But since for memfd we are not passing a path to
hugetlbfs mount rather the page size value we need to know its
value upfront.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

This helper returns the default hugetlbfs mount point from given
array of mount points.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>