To skip adding a url link to change password within an error message,
update the login.jsp to detect the error code and render the link
directly.
- `AuthenticationException` now holds an error code and message
- JSPs in `enginesso` have been updated to use custom tags to
share logic around accessing SsoContext and SsoSession data
- `SsoContext` updated to pre-create URLs commonly needed across
the package
- `SsoSession` adds `loginErrorCode` to hold the error code that goes
along with `loginMessage` so it can be checked within the JSP layer
Change-Id: I4f3f1c12dd489d2c1d816cd03dd147d88c65b334
Bug-Url: https://bugzilla.redhat.com/1944290
Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
Updates made:
- Change https://zanata.phx.ovirt.org to https://zanata.ovirt.org
- Use a newer version of the zanata maven plugin to manage pull and
push transactions. The older version references a version of JAXB
that no longer works on the current 1.8 JDK.
- Drop the use of Java 1.8 to run the zanata maven plugin, Java 11
works with the updated plugin.
Change-Id: Ided245ab8134f52610cc9aa896d3762fa5378aaf
Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
When an update of the VM/Template had failed during the cluster
upgrade from one compatibility version to another,
the audit.log did not contain any relevant information,
in the engine.log it was hard to find because the reason
might have been logged several hundreds of lines above the
cluster upgrade failed message. The UI error dialog contained
only a generic message and no reason why the edit of a VM/Template
failed.
This patch fixes the processing of the error message returned
from the VM/Template update so that every message is processed
(so far only message matching a specific pattern) and logged
in engine.log and audit.log.
The UI error dialog now contains also the error message from
the first failed VM/Template.
Change-Id: I107067dc41c74078bb2d49c5e86c685bd42fd036
Signed-off-by: Lucia Jelinkova <ljelinko@redhat.com>
Adding type field to the Storage Domain entity, in order to
differentiate between types of SDs in the Domains table. This is
required to enable/disable "Connections" button for iSCSI domains
only.
Change-Id: Id60b782358c8318a88c7250356df8f6ca9170b6e
Bug-Url: https://bugzilla.redhat.com/977379
Signed-off-by: Mark Kemel <mkemel@redhat.com>
A new engine-config parameter 'ClientModeConsoleDefault' was already
added and read by web-ui in https://gerrit.ovirt.org/c/ovirt-engine/+/112536 for
specifying system level default console for all VMs.
This patch supports reading this engine-config parameter by webadmin as well,
such that in case the actual console type is not chosen by the user via
'console options', the global value set by this config will be used (as long as it's
supported).
This will also enable a required functionality of setting console type globally for
all exisiting (and new) VMs just by cleaning the browser local storage domain.
Change-Id: I984b8007e1bb0352d86ef905b8bae817fe45166b
Bug-Url: https://bugzilla.redhat.com/1624015
Signed-off-by: Sharon Gratch <sgratch@redhat.com>
The patch fixes the following issues:
a) Some fields have not been set with data from
model, although they are visible in Blank template dialog.
This was because some of the builders were deliberately
left out. Now the same builders as for the existing VM are
used.
b) If the Cirrus video type was selected, the graphics protocol
was not loaded.
c) If the Cirrus video type was selected, it was not stored in
the backend, but replaced by QXL.
d) The Bios type field has been hidden as it is not possible to
select a value for Blank template anyway. It is now consistent
with cluster field.
e) Setting fields as (non) available has been moved to
initialize() method.
f) Removed call to updateResumeBehavior() as the method requires
the cluster to be selected and if not (e.g. for Blank template),
it returns.
g) The custom compatibility version has been hidden as it makes
no sense on the Blank template
Change-Id: Ic30af467128943d825da711150397ce0306ac456
Signed-off-by: Lucia Jelinkova <ljelinko@redhat.com>
Remove "moVirt for Android" entry from the oVirt welcome page since this
project has been archived and announced as discontinued.
Change-Id: I990bc7b5bc89307134c981490ff44c7cfe8bfc3f
Bug-Url: https://bugzilla.redhat.com/2028359
Signed-off-by: Sharon Gratch <sgratch@redhat.com>
should resolve build error:
+ /usr/libexec/platform-python /usr/share/java-utils/mvn_artifact.py /home/jenkins/workspace/ovirt-engine_standard-check-patch/ovirt-engine/rpmbuild/BUILDROOT/ovirt-engine-4.5.0-0.2.master.20211203133347.git4c11a907d7f.el8.x86_64/usr/share/maven-poms/JPP.ovirt-engine-aaa.pom ovirt-engine/aaa.jar
xmvn-resolve failed:
Unhandled exception
java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext
at org.fedoraproject.xmvn.tools.resolve.ResolverCli.parseRequests(ResolverCli.java:60)
at org.fedoraproject.xmvn.tools.resolve.ResolverCli.run(ResolverCli.java:112)
at org.fedoraproject.xmvn.tools.resolve.ResolverCli.main(ResolverCli.java:152)
Caused by: java.lang.ClassNotFoundException: javax.xml.bind.JAXBContext
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
... 3 more
Change-Id: I77e37aeed809a0c98977da76b8ef9c97972162ed
Signed-off-by: Sandro Bonazzola <sbonazzo@redhat.com>
- Use SHA256 signature in remote_engine CSR
In the Certificate Signing Request (CSR) generated by the remote_engine
code (currently used for engine-setup on separate machine for
websocket-proxy and grafana), use SHA256 instead of SHA1. This is just a
CSR, not a certificate, not really sensitive security-wise - pushing
mainly for completeness.
- Show CA fingerprint using SHA256
Change-Id: I30f0986922178669ffe99680a4dedf81d9951fa6
Bug-Url: https://bugzilla.redhat.com/1912687
Signed-off-by: Yedidyah Bar David <didi@redhat.com>
The current motivation for pushing this patch is to get rid of one more
place that uses SHA-1.
This code is long deprecated - see https://bugzilla.redhat.com/1332813 -
and I think it's ok to just remove it.
Bug-Url: https://bugzilla.redhat.com/1912687
Change-Id: Ie107640100bd7892dbe61a86205659af85e419ba
Signed-off-by: Yedidyah Bar David <didi@redhat.com>
Add dedicated cpu policy to the CpuPinningPolicy
enum and to the webadmin
Change-Id: I90b6cc1bf365de56bf41173a2b736ab79988aa78
Signed-off-by: Saif Abu Saleh <sabusale@redhat.com>
This patch blocks the clone operation for running VMs with MBS disks.
Change-Id: I10de1faf8f1fe1367c7533be80e904d7e30595da
Signed-off-by: Shani Leviim <sleviim@redhat.com>
Instead of failing with TypeError hide the network
that is present already in all Data Centers and
cannot be imported.
Change-Id: I760f925f0eea29759d3c1403802ed5578fa27184
Bug-Url: https://bugzilla.redhat.com/1661875
Signed-off-by: Ales Musil <amusil@redhat.com>
Currently, the VM disks are lock in the database fairly late after
backup is started.
This patch locks the disks at the start of StartVmBackupCommand#execute
as it's better to reflect the disks are in-use sooner rather than later
and adds another line of defence in case another operation does not
properly takes memory locks.
Signed-off-by: Benny Zlotnik <bzlotnik@redhat.com>
Change-Id: Ic82c0f4d072078448453c913c1058de0f4c4af22
When a VM has sap_agent=true custom property,
it expects that the host has the right vhostmd
hook installed. However, this expectation has not
been enforced and the VM could have been started.
This patch adds a new scheduling filter that filters
all hosts without the required vhostmd hook installed
for all VMs with sap_agent=true custom property.
Change-Id: I864cb270d8a037e71d458cf744c4aef97ea60269
Bug-Url: https://bugzilla.redhat.com/2023786
Signed-off-by: Lucia Jelinkova <ljelinko@redhat.com>
Currently a VM is assigned and taken from the pool only by users with
UserRole permission. A user with SuperUser role has permissions to
view/open console to a VM, but he is not assigned to it. The VM is still
marked as non-attached and that's why any user with UserRole permission
can take this VM.
For solving this, this patch makes VMs that there's a console connected
to them ineligible for assignment. This is implemented by checking
vm_dynamic.client_ip field. However, if VDSM restarts while a client is
connected, client_ip gets cleared despite the console is still open. But
this flow is rare and may be resolved later.
Change-Id: I639a72d2bfe2894517f83cb268a74dbec4f2e377
Bug-Url: https://bugzilla.redhat.com/1648985
Signed-off-by: Shmuel Melamud <smelamud@redhat.com>
1. Cache /root/.m2 directory, because maven running inside container is
running under root user
2. Use standard GH cache action
3. Bump maven-assembly-plugin to 3.3.0 to invalidate cache
Change-Id: I0e39c960bd32c2fbcc4ca26130b50d0b029cf70b
Signed-off-by: Martin Perina <mperina@redhat.com>
Use skjolber/maven-cache instead of standard cache action which doesn't
work well with builds inside containers.
Change-Id: I5effdabeb23018b53bc568bfea7e0984aaf5d01f
Signed-off-by: Martin Perina <mperina@redhat.com>
If engine-backup fails, check if there is low free space on the
temporary folder, and if so, report/log this. This might be the reason
for failure, especially with a large history database.
Change-Id: I2754e64c1046b00e16d912de529e936eb2b6e370
Bug-Url: https://bugzilla.redhat.com/2014035
Signed-off-by: Yedidyah Bar David <didi@redhat.com>
Use $HOME/.m2/repository as a directory for maven cache, because cache
action is not able to store files from a directory using
${{github.workspace}} variable.
Change-Id: Id6b52e471f2b01d022f8460d2769d7414e0dca4a
Signed-off-by: Martin Perina <mperina@redhat.com>
When TPM is enabled or disabled for next run configuration, the change
is ignored when next run configuration is applied. When processing
the devices from the next run configuration, TPM is treated as "other"
device, VmDeviceCommonUtils#isSpecialDevice returns false for it and
then TPM is processed as an unmanaged device. But TPM is actually a
managed device, so let's fix the problem by returning true from
VmDeviceCommonUtils#isSpecialDevice for TPM devices.
Change-Id: I99dd9ba97660d86f98d7cf7e26d4112c99ad4bcb
Bug-Url: https://bugzilla.redhat.com/1999028
Signed-off-by: Milan Zamazal <mzamazal@redhat.com>
Use standard ovirt-engine build without producing RPMs
Change-Id: Iff30d1ae696c83e1f8739ae76a083f88c0da200c
Signed-off-by: Martin Perina <mperina@redhat.com>
We have the right limit on the maximum number of parallel migrations
in ClusterModel but an old, incorrect, value was still used in
UnitVmModel. This patch fixes the mistake and introduces common
constants for minimum and maximum connections, used everywhere.
Change-Id: I02536dd1d70db028ff8f953a793c21bfca1082e3
Bug-Url: https://bugzilla.redhat.com/1975720
Signed-off-by: Milan Zamazal <mzamazal@redhat.com>
There are several CVEs on log4j 1.y, which are not going to be fixed, so
we need to switch to some other logging backend and java.util.logging is
the easiest switch for command line tools (we are already using JUL in
other engine command line tools).
Change-Id: I48ef2f47b28cf385fb459bbc445a92c07966117d
Signed-off-by: Martin Perina <mperina@redhat.com>
If CopyImageGroupWithDataCommand is invoked by AddVmFromTemplate we may
get unwanted results, as templates can be located on multiple storage
domains, which may lead to a different size calculation than the ones
desired as we may use a copy of the template that is present on a
Storage Domain different than the one selected.
While AddVmFromTemplate selects the source Storage Domain based on the
target, CopyImageGrupWithDataCommand currently ignores it and uses
sourceImage.getStorageTypes().get(0) which is wrong, as template images
may have multiple elements in the list.
Instead, the code should determine the measurement method using the
provided image and Storage Domain.
Change-Id: I0dced08f8acc413e29a4d42aaac294e979f49850
Bug-Url: https://bugzilla.redhat.com/2034531
Signed-off-by: Benny Zlotnik <bzlotnik@redhat.com>
The fact that this bug occurs on SPM hosts is not related directly to
any SPM flow, simply when SPM is involved we have more operations that
takes some time to execute, allowing to multiple non-responding
treatment commands to be executed by several threads.
This patch fixes the way we update the inFencingFlow flag such that it
does not enable to multiple non-responding treatment commands to be
executed concurrently
Change-Id: Ibf555700b65e7b995fa562532d6b941f71d95764
Bug-Url: https://bugzilla.redhat.com/2000031
Signed-off-by: emesika <emesika@redhat.com>
Adding image transfer session ID to all the logs where possible
and makes sense.
Some logs' rephrase to receive more consistent logs phrasing.
Surrounding UUIDs with quotes for readability.
Few small fixes and warnings eliminations, like:
- Missing or redundant (thus unused) log parameters.
- Unprinted exceptions and VDS error codes.
- Unnecessary "toString()" calls when logging UUIDs.
Signed-off-by: Pavel Bar <pbar@redhat.com>
Change-Id: I67310e147a0df18ac261947e39068dccf598e420
When engine start the NBD server in vdsm during upload (e.g. restore) or
download (e.g. offline backup) it uses the image transfer ticket id as the
server id. This id is used to create a socket at /run/vdsm/nbd/{id} and for
stopping the server.
We have 2 UUIDs for an image transfer:
- The transfer id - the engine command id.
- The ticket id - used for authenticating the client with imageio server.
The ticket id is sensitive information that should not be logged while the
transfer is active. The transfer id is public information that may be logged
everywhere, and we want all events related to image transfer to have this id.
This change remove the ticket id from many logs in vdsm and imageio, and
replace the nbd socket /run/vdsm/nbd/{nbd-server-id} to use the transfer
id.
Change-Id: Ic6cfa674290b30e52f22549b06570906f06c1983
Bug-Url: https://bugzilla.redhat.com/2043283
Signed-off-by: Nir Soffer <nsoffer@redhat.com>
Log also the current phase, so we could detect invalid phase changes.
Don't log entity message, which may be stale since we update the message
just after logging the value.
Don't log the disk id, since it is not clear what is this id, and the
log assumes that this is an image id, while disk id should be an image
group id. Also the log tried to handle case when disk id is not
available which looks impossible.
Also quote the logged values for better readability.
Change-Id: I4d23968f1cc4764570b60283c1e408503245deb9
Signed-off-by: Nir Soffer <nsoffer@redhat.com>
Libvirt allows using multiple network connections for a VM migration.
This patch adds support for the newly introduced Vdsm migration
parameter `parallel'.
Parallel migration connections are disabled by default. They can be
enabled per cluster and per VM. If enabled, they can specify the
number of parallel connections to use explicitly or to let Engine
select the number of parallel connections automatically, with parallel
migration connections being either required (regardless of the
bandwidth) or optional (only if there is enough bandwidth). In the
latter case, the number is based on the migration network
bandwidth (to have enough capacity there) and the number of VM
vCPUs (to not overload the system with too many threads or to use more
CPUs than a CPU-pinned QEMU process has). The vCPU limit applies also
when there is a user-specified number of parallel connections.
There is also a limit on the number of parallel connections accepted
by libvirt & QEMU, which is 255.
Post-copy is disabled when parallel migration connections are enabled.
This is because the current QEMU implementation of multiple migration
connections doesn't allow switching to post-copy. It would be good to
add later some validation of this conflict.
When parallel migration connections are enabled, migration compression
is disabled because XBZRLE compression is not supported with multiple
connections. We may enable gzip/zstd compression with multiple
connections, which is supported and should be more efficient, if
libvirt supports it.
When parallel migration connections are enabled, the available
migration bandwidth is expected to be saturated. For this reason, we
set the maximum number of the outgoing migrations to 1.
The implementation puts information about the parallel migration type
and the custom number of parallel migrations into a single VmBase
field, to keep the number of VmBase fields as low as possible, for the
happiness of clients that query large amounts of VMs.
Parallel migrations require support on Vdsm side. That means they are
restricted to the cluster version 4.7 or higher.
Change-Id: I201946d2e5ba9e31f3bac7e7668bd8cdc82ced61
Bug-Url: https://bugzilla.redhat.com/1975720
Signed-off-by: Milan Zamazal <mzamazal@redhat.com>
When we have strange topology that leaves us with fraction when trying
to assign the CPUs in the NUMA pinning, we may end up with split cores.
If that happens, the topology set from the engine won't fit what the
guest actually has. In addition, the memory will try to align with the
CPU amount per NUMA node.
An example is a host having 1 socket, 24 cores and 2 threads.
A VM with the topology of 1 socket, 23 cores and 2 threads trying to run
and having 4 NUMA nodes pinned to the physical NUMA nodes on that host.
Using the current algorithm CPU 33 will be on NUMA node 3 while CPU 34
will be on NUMA node 4. But, they are supposed to be on the same core.
The result will be wrong topology within the guest, as `lscpu` is
confused from this situation, leading to mismatching topology inside the
guest.
This patch will correct it, by checking the threads and assigning the
whole cores.
Change-Id: I84b17d46c51af2d86c0da164c776ecbd298fbb80
Bug-Url: https://bugzilla.redhat.com/1912967
Signed-off-by: Liran Rotenberg <lrotenbe@redhat.com>
Simple optimization of existing build-artifacts.sh and aligning with
GH action based workflow.
Change-Id: I44f9dd809e4605a9de542ee708733b55efc2a459
Signed-off-by: Martin Perina <mperina@redhat.com>
