Dear Ladies and Gentlemen!
I am currently working with the java-sdk and I encountered a problem.
If I would like to retrieve the disk details, I get the following error:
Disk currDisk = ovirtConnection.followLink(diskAttachment.disk());
The Error is occurring in this line:
The getResponst looks quiet ok. (I inspected: [cid:image002.png@01D44537.AF127FD0] and it looks ok).
wrong number of arguments
The code is quiet similar to what you published on github (https://github.com/oVirt/ovirt-engine-sdk-java/blob/master/sdk/src/test/j... ).
Can you confirm the defect?
If I do e.g.:
1. Install CentOS
2. yum install ovirt-releaseSOMETHING
3. yum install vdsm
Then reboot the machine, vdsm starts, and for this, it does all kinds of
things to the system (such as configure various services using vdsm-tool
etc.). Are we sure we want/need this? Why would we want vdsm
configured/running at all at this stage, before being added to an engine?
In particular, if (especially during development) we have a bug in this
configuration process, and then fix it, it might not be enough to upgrade
vdsm - the tooling will then also have to fix the changes done by the buggy
previous version, or require a full machine reinstall.
Thanks and best regards,
A VM Snapshot can be made using
SnapshotBuilder builder = new SnapshotBuilder().vm(VM).name("Snap1").description("Test");
It can be made with no memory by using a builder with persistMemorystate(false)
How can one be made with no disk? .diskAttachments(emptyList) isnt working.
I've seen vdsmd leak memory (RSS increasing) for a while (brought it up
on the lists and opened a BZ ticket), and never gotten anywhere with
diagnosing or resolving it. I reinstalled my dev setup Friday with
up-to-date CentOS 7 (minimal install) and oVirt 4.3, with a hosted
engine on iSCSI (multipath if it matters).
In just 3 days, vdsmd on the host with the engine has gone up to an RSS
of 481 MB. It just continues to steadily increase. Watching with a
script, I see (this is VmRSS from /proc/$(pidof -x vdsmd)/status):
12:26:32.892 482076 +20
12:26:35.300 482096 +20
12:26:38.927 482112 +16
12:26:40.034 482128 +16
12:26:47.534 482132 +4
12:26:48.887 482144 +12
12:26:49.133 482156 +12
12:26:50.955 482172 +16
12:26:53.062 482176 +4
12:26:53.092 482204 +28
12:26:59.065 482212 +8
12:26:59.075 482228 +16
12:26:59.361 482244 +16
12:27:03.131 482252 +8
12:27:07.370 482256 +4
12:27:10.091 482272 +16
12:27:13.205 482296 +24
12:27:18.770 482308 +12
12:27:20.437 482332 +24
12:27:23.313 482340 +8
12:27:23.324 482364 +24
12:27:26.667 482372 +8
12:27:26.687 482376 +4
12:27:28.873 482388 +12
12:27:28.883 482392 +4
12:27:28.976 482396 +4
12:27:29.190 482408 +12
That's an increase of 352 kB in a minute.
There's got to be some way to diagnose this, but I don't know python
Chris Adams <cma(a)cmadams.net>
Installing the latest ovirt-engine master requires package:
java-client-kubevirt >= 0.2.0
But the master nightly snapshot contains only version:
On the patch that bumped the version, there is a comment from the CI, that
the change was not included in nightly builds:
I faced it multiple times during local runs, e.g. first it was missing /tmp/otopi*. Now it fails for me on missing /var/lib/pgsql/upgrade_rh-postgresql95-postgresql.log and /etc/dnf on centos7 engine. It seems like any missing artifact during collection step will fail the test.
I understand some potential benefit of it, but I suggest we do not fail it if we are unable to find any of the artifacts during collection step. Better just to issue a warning in the logs and go on. If somebody needs to test for particular log presence, I suggest it should be included as a test step instead.
Associate Manager - RHV DevOps - Red Hat
When attempting to make the ovirt-provider-ovn integration tests run
in el8 (which requires podman instead of docker), I'm getting trouble
even running it (it being podman).
It fails with the following error - e.g. on a podman info command:
Error: could not get runtime: kernel does not support overlay fs:
overlay: the backing xfs filesystem is formatted without d_type
support, which leads to incorrect behavior. Reformat the filesystem
with ftype=1 to enable d_type support. Running without d_type is not
supported.: driver not supported
Has anyone faced anything like this / is able to provide some pointers ?
Thanks in advance,