May 2019 - Devel - oVirt List Archives

[VDSM] Started getting virNetTLSContextCheckCertTimes:154 : The server certificate /etc/pki/vdsm/certs/vdsmcert.pem has expired
by Edward Haas 11 Jan '24

11 Jan '24

Hi, I have a VM which acts as an oVirt host with VDSM installed. I use it for testing without connecting it to Engine. Recently VDSM fails to come up and I see this error: Sep 26 17:58:18 localhost libvirtd: 2018-09-26 14:58:18.978+0000: 12176: error : virNetTLSContextCheckCertTimes:154 : The server certificate /etc/pki/vdsm/certs/vdsmcert.pem has expired Any hint on how to generate or fetch a new certificate without the help of Engine? Thanks, Edy.

3 5

Error Java SDK Issue??
by Geschwentner, Patrick 02 Apr '21

02 Apr '21

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: [cid:image001.png@01D44537.AF127FD0] The getResponst looks quiet ok. (I inspected: [cid:image002.png@01D44537.AF127FD0] and it looks ok). Error: 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/jav… ). Can you confirm the defect? Best regards Patrick

6 11

OST's basic suite UI sanity tests optimization
by Marcin Sobczyk 07 Aug '19

07 Aug '19

Hi, _TL; DR_ Let's cut the running time of '008_basic_ui_sanity.py' by more than 3 minutes by sacrificing Firefox and Chrome screenshots in favor of Chromium. During the OST hackathon in Brno this year, I saw an opportunity to optimize basic UI sanity tests from basic suite. The way we currently run them, is by setting up a Selenium grid using 3 docker containers, with a dedicated network... that's insanity! (pun intended). Let's a look at the running time of '008_basic_ui_sanity.py' scenario (https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-test…) 01:31:50 @ Run test: 008_basic_ui_sanity.py: 01:31:50 nose.config: INFO: Ignoring files matching ['^\\.', '^_', '^setup\\.py$'] 01:31:50 # init: 01:31:50 # init: Success (in 0:00:00) 01:31:50 # start_grid: 01:34:05 # start_grid: Success (in 0:02:15) 01:34:05 # initialize_chrome: 01:34:18 # initialize_chrome: Success (in 0:00:13) 01:34:18 # login: 01:34:27 # login: Success (in 0:00:08) 01:34:27 # left_nav: 01:34:45 # left_nav: Success (in 0:00:18) 01:34:45 # close_driver: 01:34:46 # close_driver: Success (in 0:00:00) 01:34:46 # initialize_firefox: 01:35:02 # initialize_firefox: Success (in 0:00:16) 01:35:02 # login: 01:35:11 # login: Success (in 0:00:08) 01:35:11 # left_nav: 01:35:29 # left_nav: Success (in 0:00:18) 01:35:29 # cleanup: 01:35:36 # cleanup: Success (in 0:00:06) 01:35:36 # Results located at /dev/shm/ost/deployment-basic-suite-master/008_basic_ui_sanity.py.junit.xml 01:35:36 @ Run test: 008_basic_ui_sanity.py: Success (in 0:03:45) Starting the Selenium grid takes 2:15 out of 3:35 of total running time! I've investigated a lot of approaches and came up with something like this: * install 'chromium-headless' package on engine VM * download 'chromedriver' and 'selenium hub' jar and deploy them in '/var/opt/' on engine's VM * run 'selenium.jar' on engine VM from '008_basic_ui_sanity.py' by using Lago's ssh * connect to the Selenium instance running on the engine in '008_basic_ui_sanity.py' * make screenshots This series of patches represent the changes: https://gerrit.ovirt.org/#/q/topic:selenium-on-engine+(status:open+OR+statu…. This is the new running time (https://jenkins.ovirt.org/view/oVirt system tests/job/ovirt-system-tests_manual/4195/): 20:13:26 @ Run test: 008_basic_ui_sanity.py: 20:13:26 nose.config: INFO: Ignoring files matching ['^\\.', '^_', '^setup\\.py$'] 20:13:26 # init: 20:13:26 # init: Success (in 0:00:00) 20:13:26 # make_screenshots: 20:13:27 * Retrying (Retry(total=2, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fdb6004f8d0>: Failed to establish a new connection: [Errno 111] Connection refused',)': /wd/hub 20:13:27 * Retrying (Retry(total=1, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fdb6004fa10>: Failed to establish a new connection: [Errno 111] Connection refused',)': /wd/hub 20:13:27 * Retrying (Retry(total=0, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fdb6004fb50>: Failed to establish a new connection: [Errno 111] Connection refused',)': /wd/hub 20:13:28 * Redirecting http://192.168.201.4:4444/wd/hub -> http://192.168.201.4:4444/wd/hub/static/resource/hub.html 20:14:02 # make_screenshots: Success (in 0:00:35) 20:14:02 # Results located at /dev/shm/ost/deployment-basic-suite-master/008_basic_ui_sanity.py.junit.xml 20:14:02 @ Run test: 008_basic_ui_sanity.py: Success (in 0:00:35) (The 'NewConnectionErrors' is waiting for Selenium hub to be up and running, I can silence these later). And the screenshots are here: https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-test… _The pros:_ * we cut the running time by more than 3 minutes _The cons:_ * we don't get Firefox or Chrome screenshots - we get Chromium screenshots (although AFAIK, QE has much more Selenium tests which cover both Firefox and Chrome) * we polute the engine VM with 'chromium-headless' package and deps (in total: 'chromium-headless', 'chromium-common', 'flac-libs' and 'minizip'), although we can remove these after the tests _Some design choices explained:_ Q: Why engine VM? A: Because the engine VM already has 'X11' libs. We could install 'chromium-headless' (and even other browsers) on our Jenkins executors, but that would mess them up a lot. Q: Why Chromium? A: Because it has a separate 'headless' package. Q: Why not use 'chromedriver' RPM in favor of https://chromedriver.storage.googleapis.com Chromedriver builds? A: Because the RPM version pulls a lot of extra dependencies even on the engine VM ('gtk3', 'cairo' etc.). Builds from the URL are the offical Google Chromedriver builds, they contain a single binary, and they work for us. _What still needs to be polished with the patches:_ * Currently 'setup_engine_selenium.sh' script downloads each time 'selenium.jar' and 'chromedriver.zip' (even with these downloads we get much faster set-up times) - we should bake these into the engine VM image template. * 'selenium_hub_running' function in 'selenium_on_engine.py' is hackish - an ability to run an ssh command with a context manager (and auto-terminate on it exits) should be part of Lago. Can be refactored. Questions, comments, reviews are welcome. Regards, Marcin

7 10

Storage test case needs to be fixed: 002_bootstrap.resize_and_refresh_storage_domain
by Dafna Ron 02 Jul '19

02 Jul '19

Hi Tal, I am seeing random failures for test 002_bootstrap.resize_and_refresh_storage_domain It looks like this is a timing issue since by the time we print out the error we actually see the resize succeeded. see example below: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/14185/testRep… Can you please assign someone from the storage team to fix this test? Thanks, Dafna

4 14

ovirt-engine has been tagged (ovirt-engine-4.3.4.2)
by Tal Nisan 29 May '19

29 May '19

1 0

Fwd: Fedora 28 End Of Life
by Sandro Bonazzola 29 May '19

29 May '19

FYI. Fedora 29 oVirt packages building is still in progress. The following package still need to be built, help with getting them built on fedora 29 will be appreciated. cockpit-ovirt engine-db-query ovirt-engine-api-explorer ovirt-engine-appliance ovirt-engine-extension-aaa-misc ovirt-engine-nodejs-modules ovirt-engine-sdk-python (sdk3) ovirt-engine-ui-extensions ovirt-engine-yarn ovirt-guest-agent-windows ovirt-guest-tools-iso ovirt-host ovirt-hosted-engine-ha ovirt-hosted-engine-setup ovirt-node-ng-image ovirt-provider-ovn ovirt-scheduler-proxy vdsm Thanks ---------- Forwarded message --------- Da: Mohan Boddu <mboddu(a)bhujji.com> Date: mer 29 mag 2019 alle ore 01:05 Subject: Fedora 28 End Of Life To: <announce(a)lists.fedoraproject.org>, < test-announce(a)lists.fedoraproject.org>, < devel-announce(a)lists.fedoraproject.org> As of the 28th of May 2019, Fedora 28 has reached its end of life for updates and support. No further updates, including security updates, will be available for Fedora 28. Fedora 29 will continue to receive updates until approximately one month after the release of Fedora 31. The maintenance schedule of Fedora releases is documented on the Fedora Project wiki [0]. The Fedora Project wiki also contains instructions [1] on how to upgrade from a previous release of Fedora to a version receiving updates. Regards, Mohan Boddu. [0] https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedu… [1]https://fedoraproject.org/wiki/Upgrading?rd=DistributionUpgrades _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr… -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig> <https://redhat.com/summit>

1 0

VDSM Python 3 RPMs are available
by Marcin Sobczyk 28 May '19

28 May '19

Hi, I'm happy to announce, that with [1] landing in master, we're now building Python 3 packages for VDSM. Example pipeline run can be found here [2]. Currently the py3 RPMs still have some broken dependencies and there are ongoing efforts to fix these. All scripts in built RPMs have py3 shebang lines, but there is no guarantee that all of them will work. We also build for Fedora 28 only - more patches are on the way that will build RPMs for Fedora 30. If you want to make py3 RPMs out of your VDSM patch, you simply need to post 'ci please build' in gerrit - that will launch 'build-artifacts' stdci stage which produces py2 and py3 RPMs in its sub-stages. Regards, Marcin [1] https://gerrit.ovirt.org/#/c/100135/ [2] https://jenkins.ovirt.org/job/vdsm_standard-on-merge/755/artifact/

2 1

vdsm has been tagged (v4.30.17)
by Milan Zamazal 28 May '19

28 May '19

1 0

sanlock 3.7.3-1 is available for testing
by Nir Soffer 28 May '19

28 May '19

This is the first version providing proper 4K API, and will be consumed by vdsm soon when the package is available. We will have soft dependency to allow testing 4k sorage on platforms that provide this package. sanlock 3.7.3 is available now for testing on: ## CentOS Enable this repo: http://buildlogs.centos.org/centos/$releasever/virt/$basearch/ovirt-4.3/ Sandro, shouldn't it be in: https://cbs.centos.org/repos/virt7-ovirt-43-testing/$basearch/os/ ## Fedora I requested sanlock-3.7.3 for update-testing yesterday in the morning, but the package is still pending after more than a day. To get the package now, you can download the rpms from koji: f28: https://kojipkgs.fedoraproject.org//packages/sanlock/3.7.3/1.fc28/x86_64/ f29: https://kojipkgs.fedoraproject.org//packages/sanlock/3.7.3/1.fc29/x86_64/ f30: https://kojipkgs.fedoraproject.org//packages/sanlock/3.7.3/1.fc30/x86_64/ Thanks for testing sanlock! Nir

4 5

Re: [ovirt-users] Donating hardware to the oVirt project - a great opportunity to contribute
by Eyal Edri 27 May '19

27 May '19

Also adding infra and devel lists. On Thu, May 23, 2019 at 11:19 AM Evgheni Dereveanchin <ederevea(a)redhat.com> wrote: > Hi everyone, > > My name is Evgheni and I'm in charge of the infrastructure used by oVirt > to host the code, test it and serve packages to users. Currently we heavily > rely on our PHX data center [1] for these tasks. It consists of several > dozen bare metal servers that work as hypervisors, storage servers and bare > metal CI hosts. We use them quite effectively yet the amount of workload is > always growing so now is a good time to ask our community for help. If you > happen to have physical servers or VMs that could be used as part of oVirt > infra - please let us know. We created a page [2] describing hardware specs > that would allow us make the infra more stable and grow its capacity. > > If you have any other ideas or input about the oVirt infra - feel free to > reach out to me or start a discussion on the Infra list [3]. > > Regards, > Evgheni > > [1] > https://ovirt-infra-docs.readthedocs.io/en/latest/Phoenix_Lab/Overview/inde… > [2] https://ovirt.org/community/get-involved/donate-hardware.html > [3] https://lists.ovirt.org/ > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/users@ovirt.org/message/H3BHMU3DHFS7N… > -- Eyal edri MANAGER CONTINUOUS PRODUCTIZATION SYSTEM ENGINEERING Red Hat <https://www.redhat.com/> <https://red.ht/sig> phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ #cp-devel)

1 0

Lago oVirt plugin v0.46 Release Announcement
by Galit Rosenthal 26 May '19

26 May '19

Hi, On behalf of the Lago team, I'm pleased to announce that lago-ost-plugin v0.46, is available. This release adds support for Fedora 29 and includes some bug fixes and new features. New Features - Fedora29 requires gcc which is missing - Fedora requires dnf-utils - Lago ost plugin does not need to depend directly on createrepo. repoman depends on it (on createrepo_c which is OK). This a This allows us to get rid of 'yum' if needed. Bug Fixes - Fix Lago ExtractPathNoPathError - Fix "with_repo_server" docstrings Installing And Upgrading To upgrade using yum or dnf, simply run: yum/dnf update lago-ost-plugin Resources Docs: http://lago-ost-plugin.readthedocs.io/en/latest/ GitHub: https://github.com/lago-project/lago-ost-plugin YUM Repository: http://resources.ovirt.org/repos/lago/stable/0.0/rpm/ OST Docs: http://ovirt-system-tests.readthedocs.io/en/latest/ Changelog: http://lago-ost-plugin.readthedocs.io/en/latest/_static/ChangeLog.txt As always, if you find any issues, please open an issue on the GitHub page. Enjoy! Galit -- GALIT ROSENTHAL SOFTWARE ENGINEER Red Hat <https://www.redhat.com/> galit(a)redhat.com T: 972-9-7692230 <https://red.ht/sig>

1 0

I find no method to modify the vm's os type by using java sdk
by weizhengya16＠gmail.com 26 May '19

26 May '19

I use following code to change it's os information ``` vmService.update(). vm( vm() .os( operatingSystem() .type("other") ) ) .send(); ``` then I get an error like following: Exception in thread "main" org.ovirt.engine.sdk4.Error: Fault reason is "Operation Failed". Fault detail is "[Cannot edit VM. Invalid time zone for given OS type., Attribute: vmStatic]". HTTP response code is "400". HTTP response message is "Bad Request". In my test, I find for the virtual machine which is in "down" status, it's running as same as I expect.But with those alive virtual machine with current os is not "other" ,it will make the mistake as above. Could someone know what's the problem is and how to change the os type for alive virtual machine?

2 1

Testing sanlock development build with OST
by Nir Soffer 23 May '19

23 May '19

Looking in https://jenkins.ovirt.org/job/ovirt-system-tests_manual/build <https://jenkins.ovirt.org/job/ovirt-system-tests_manual/build?delay=0sec> CUSTOM_REPOS: You can add multiple Jenkins build urls/Yum repos, one per line. Supported formats are: * Jenkins Build url: e.g., http://jenkins.ovirt.org/job/vdsm_master_build-artifacts-on-demand-el7-x86_… * Yum repo: "rec:yum_repo_url" e.g., rec: http://jenkins.ovirt.org/job/vdsm_master_build-artifacts-on-demand-el7-x86_… It seems that this should work: 1. build sanlock rpms from my sanlock tree 2. copy to some public web server 3. create yum repo 4. add rec:http://my.server/sanlock-repo/ OST will pull sanlock from this repo, right? The biggest issue seems to be a public web server, I don't have one. Do we have something that I can use in jenkins.ovirt.org or other domain we control? I want to run these tests regularly, to make sure that sanlock always works with vdsm, without manual testing. Nir

2 3

vdsm failing on kernel package in CQ - Fix will be merged soon
by Dafna Ron 21 May '19

21 May '19

Hi, vdsm project is failing on 4.3 and master due to a kernel package dependency [1] Galit already has a patch and will merge once it passes CI [2] [1] http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/14195/artifac… [2] https://gerrit.ovirt.org/#/c/100182/ Thanks, Dafna

1 0

ovirt-engine has been tagged (ovirt-engine-4.3.4.1)
by Tal Nisan 21 May '19

21 May '19

3 2

vdsm has been tagged (v4.30.16)
by Milan Zamazal 21 May '19

21 May '19

1 0

ovirt-engine has been tagged (ovirt-engine-4.2.8.8)
by Tal Nisan 20 May '19

20 May '19

1 0

Ovirt: Upload Disk Snapshots problems with iSCSI storage and Java SDK
by francisco.garcia＠wbsgo.com 20 May '19

20 May '19

Description of the problem: I am not able to restore (upload) a VM when its disk (Either Thin provisioning or Thick provisioned) is located in an iSCSI storage and this VM has at least one snapshot larger than 1Gb. I am using REST API through Java SDK. I am using the same upload procedure described here: https://ovirt.org/develop/release-management/features/storage/backup-restor…, of course, making little adjustments to disk format (COW, Sparse.. Depending on the type of the VM to be restored). When I try restore any VM with this conditions, all snapshot disks with a size smaller than 1Gb are uploaded correctly. But when I am uploading a snapshot disk with a size bigger than 1Gb, the following error ocurrs: The error triggered from Java SDK is: "The server response was 403 in the range request {bytes 1073741824-1207959551/4831838208}" In the host's imageio log: "2019-05-07 14:26:30,253 WARNING (Thread-71960) [web] ERROR [172.19.33.146] PUT /images/8d353735-0a29-463c-b772-ec37f451e2e9 [403] Requested range out of allowed range [request=0.000488]" For example (real scenario), I have these snapshot disks from a vm: 2.1G DiskSnap_47c4e157-edd8-4bfc-b838-4d57ac8396bd_33b3e74a-cc6b-474a-97cc-960891716110_0.img -> First snap chain -> OK upload 1.1G DiskSnap_47c4e157-edd8-4bfc-b838-4d57ac8396bd_9349e4dd-85b3-4145-8674-bb3f39546020_1.img -> Ok upload 1.1G DiskSnap_47c4e157-edd8-4bfc-b838-4d57ac8396bd_4d10cb58-9f52-4d64-b6e9-ead4bed4c6a6_2.img -> Ok upload 4.6G DiskSnap_47c4e157-edd8-4bfc-b838-4d57ac8396bd_429cbe6d-1148-4a84-861a-56ad6902859e_3.img -> Last snap chain -> Fail upload with previous error [Qemu-img info in attached file: qemu-imgs-iSCSI.txt] In the restore process, when I create the disk(In this case), I put the following values: Disk: { Name:T_iSCSI_Thin_Disk1_restore, Id:null, Interface:VIRTIO_SCSI, Format:COW, WipeAfterDelete: false, Shareable: false, Sparse: true, Boot:true, Activo:true, Sizes:{ Initial:4294967296, Actual:null, Total:null, Provisioned: 4294967296 } } And the disk created is: Disk: { Name:T_iSCSI_Thin_Disk1_restore, Id:aac28ff3-abdb-4bf9-beed-c08e7e19b0ba, Image:c8654d05-a18c-47bd-ab0b-f4d746e23efb, Format:COW, WipeAfterDelete: false, Shareable: false, Sparse: true, Sizes:{ Initial:null, Actual:0, Total:0, Provisioned: 4294967296 } } Therefore, the first upload can finish correctly. However, when I create snapshots with this disk, the snapshot disks have these parameters: DiskSnapshot: { Id: 29dd6a18-c17c-4938-be67-d7af6de713ec, Disk:aac28ff3-abdb-4bf9-beed-c08e7e19b0ba, Snapshot:ceb2f29e-1ae8-441c-a5a7-836308cfeb8d, Sizes:{ Actual:1073741824 Provisioned:4294967296 Total: 0 Initial: null } } DiskSnapshot: { Id: 69620911-d490-4872-b353-ba29a762ea3e, Disk:aac28ff3-abdb-4bf9-beed-c08e7e19b0ba, Snapshot:c35423d5-ddd6-46f2-a5d7-0080941c3f30, Sizes:{ Actual:1073741824 Provisioned:4294967296 Total: 0 Initial: null } } DiskSnapshot: { Id: c8654d05-a18c-47bd-ab0b-f4d746e23efb, Disk:aac28ff3-abdb-4bf9-beed-c08e7e19b0ba, Snapshot:fc135efd-a67b-4eb3-bfdb-9090aa3b267e, Sizes:{ Actual:4831838208 Provisioned:4294967296 Total: 0 Initial: null } } DiskSnapshot: { Id: e3389916-4e80-4593-a116-3484f295ff7f, Disk:aac28ff3-abdb-4bf9-beed-c08e7e19b0ba, Snapshot:74aff5e7-e1c1-4f51-ae31-ea44caa180ef, Sizes:{ Actual:1073741824 Provisioned:4294967296 Total: 0 Initial: null } } As we can observe with these values, the actual size of snapshot disks indicates 1Gb, and when I try upload a snapshot disk (Bigger than 1.1Gb), the system doesn't allow to complete the upload, launching the mentionated previous error. However, using NFS storage, the previous error doesn't ocurr. The system allows me upload disks bigger than 1 Gb, and when the upload finishes, the system refreshs the actualSize to actual value. For example (real scenario), I have these snapshot disks from a vm: 3.1G DiskSnap_985a02a0-0752-420a-a2fb-a3e89d1ac3bc_3dffb5f4-3f9c-410c-8b97-133922721f9a_0.img -> First snap chain -> OK upload 22M DiskSnap_985a02a0-0752-420a-a2fb-a3e89d1ac3bc_d3307b3c-f930-4faa-90cb-6aedd38bea93_1.img -> Ok upload 31M DiskSnap_985a02a0-0752-420a-a2fb-a3e89d1ac3bc_aa8648dd-d6c0-4d9d-8373-6764e806359f_2.img -> Ok upload 1.3G DiskSnap_985a02a0-0752-420a-a2fb-a3e89d1ac3bc_2cf31d95-3b86-4d97-b39b-672d0066f503_3.img -> Last snap chain -> OK upload [Qemu-img info in attached file: qemu-imgs-NFS.txt] The restore with NFS storage is the same process but I change the format disk and sparse. With following values: Disk: { Name:985a02a0-0752-420a-a2fb-a3e89d1ac3bc_restore, Id:null, Interface:VIRTIO_SCSI, Format:RAW, WipeAfterDelete: false, Shareable: false, Sparse: true, Boot:true, Activo:true, Sizes:{ Initial:3221225472, Actual:null, Total:null, Provisioned: 3221225472 } } And the disk created was: Disk: { Name:985a02a0-0752-420a-a2fb-a3e89d1ac3bc_restore, Id:f2a89f5a-d8ac-4ea4-b17c-591cd86855e9, Image:9c80aead-88de-48f9-be7e-0fde917e7f55, Format:RAW, WipeAfterDelete: false, Shareable: false, Sparse: true, Sizes:{ Initial:null, Actual:0, Total:0, Provisioned: 3221225472 } } When I create snapshots with this disk, the snapshot disks have these parameters: DiskSnapshot: { Id: 87c4cb08-502a-4937-bbba-6d455395e990, Disk:f2a89f5a-d8ac-4ea4-b17c-591cd86855e9, Snapshot:dd257190-ef50-4990-a61f-40d84e2b08e9, Sizes:{ Actual:200704 Provisioned:3221225472 Total: 0 Initial: null } } DiskSnapshot: { Id: e7d6f1fb-ab37-45f8-8e23-5964ed194581, Disk:f2a89f5a-d8ac-4ea4-b17c-591cd86855e9, Snapshot:b9f3f3d3-710e-4ce2-b05f-563227f5ec04, Sizes:{ Actual:200704 Provisioned:3221225472 Total: 0 Initial: null } } DiskSnapshot: { Id: 8ef6f502-d00f-4fa5-b407-2cdc0e876045, Disk:f2a89f5a-d8ac-4ea4-b17c-591cd86855e9, Snapshot:274994de-5c2b-4b38-965f-4cadea3e0db3, Sizes:{ Actual:200704 Provisioned:3221225472 Total: 0 Initial: null } } DiskSnapshot: { Id: 9c80aead-88de-48f9-be7e-0fde917e7f55, Disk:f2a89f5a-d8ac-4ea4-b17c-591cd86855e9, Snapshot:f1d7382d-4427-4e21-9544-1b3cd85f23ae, Sizes:{ Actual:0 Provisioned:3221225472 Total: 0 Initial: null } } As we can observe with these values, the actual size of snapshot disks indicates 196Kb, and when I try upload any snapshot disk (Even more 1.1Gb), the system allows upload all content disk and when it is finalished, it changes actual and total size. When the restore ends, I obtain these values: Disk: { Name:985a02a0-0752-420a-a2fb-a3e89d1ac3bc_restoreBacula, Id:f2a89f5a-d8ac-4ea4-b17c-591cd86855e9, Image:8ef6f502-d00f-4fa5-b407-2cdc0e876045, Format:COW, WipeAfterDelete: false, Shareable: false, Status: OK, Sparse: true, Sizes:{ Initial:null, Actual:1318850560, Total:4593303552, Provisioned: 3221225472 } } DiskSnapshot: { Id: 87c4cb08-502a-4937-bbba-6d455395e990, Disk:f2a89f5a-d8ac-4ea4-b17c-591cd86855e9, Snapshot:dd257190-ef50-4990-a61f-40d84e2b08e9, Sizes:{ Actual:22282240 Provisioned:3221225472 Total: 0 Initial: null } } DiskSnapshot: { Id: e7d6f1fb-ab37-45f8-8e23-5964ed194581, Disk:f2a89f5a-d8ac-4ea4-b17c-591cd86855e9, Snapshot:b9f3f3d3-710e-4ce2-b05f-563227f5ec04, Sizes:{ Actual:32374784 Provisioned:3221225472 Total: 0 Initial: null } } DiskSnapshot: { Id: 9c80aead-88de-48f9-be7e-0fde917e7f55, Disk:f2a89f5a-d8ac-4ea4-b17c-591cd86855e9, Snapshot:f1d7382d-4427-4e21-9544-1b3cd85f23ae, Sizes:{ Actual:3219795968 Provisioned:3221225472 Total: 0 Initial: null } } There is a disk snapshot less since at the end of the restoration I merge the last snapshot. But the values showed changes in actual Size in the DiskSnapshot. Could you help me, please? Is there a different procedure to the one described in https://ovirt.org/develop/release-management/features/storage/backup-restor… to work with iSCSI storage or is this simply a bug? How reproducible: Backup and restore VM with snapshots in an iSCSI storage, using Java SDK. Steps to Reproduce: 1.- Follow steps indicated in https://ovirt.org/develop/release-management/features/storage/backup-restor… to backup a VM allocated iSCSI Storage and containing snapshots bigger than 1.1GB 2.- Try to restore it using the instructions of that documment Actual results: Upload of images of disk snapshots bigger than 1.1Gb do not suceed ant the restore process fails. Expected results: Restored vm

2 15

Local domain, Intel Optane DC
by Hetz Ben Hamo 20 May '19

20 May '19

Hi, In oVirt 4.3 it looks like the storage domains has been consolidated to data only and ISO, export are being deprecated, which IMHO is a good thing. However, when it comes to local storage and storage domains (when trying to mount local directory etc..) - the behavior of oVirt, IMHO, is weird, compared to other virtualization - your VM's are being switched to another domain, instead of just leaving them in the same domain and disabling live migration. So, as I mentioned above, I don't see any reason for this switching if using local storage, but now there's a new technology on the block - the Optane DC, and Samsung will probably show their NVDiMM solution soon. In both cases - in order to use this persistent memory, you'll need to "cut" part of the NVDiMM and mount it on the VM along side with your other NFS/iSCSI disks. This could probably kill live migration (at least in the first stage - see AMD MxGPU in the KVM forum video's work from AMD and Alibaba with live migration) - but that's a pretty good solution to utilize Optane DC/NVDiMM. So my question is: Is there any chance that oVirt 4.4 will finally allow local storage to be just like NFS/iSCSI instead of kicking the node to another domain? Also, will there be a functionality through the web interface to copy/move files between storage domains? I don't see it anywhere. (In case you guys in Israel need some Optane DC's sticks, I can talk to Intel Israel about it) Thanks Hetz

3 2

Lago v0.46 Release Announcement
by Galit Rosenthal 19 May '19

19 May '19

Hi All, On behalf of the Lago team, I'm pleased to announce Lago v0.46 is available! For a detailed release announcement please refer to our Github page at: https://github.com/lago-project/lago/releases/tag/0.46 Resources ========== Lago Docs: http://lago.readthedocs.io/en/latest/ GitHub: https://github.com/lago-project/lago/ YUM Repository: http://resources.ovirt.org/repos/lago/stable/0.0/rpm/ Pypi: https://pypi.python.org/pypi/lago Docker Hub: https://hub.docker.com/r/lagoproject/lago/ Changelog: https://lago.readthedocs.io/en/latest/_static/ChangeLog.txt As always, if you find any problems, or willing to contribute, visit our GitHub page. Enjoy! -- GALIT ROSENTHAL SOFTWARE ENGINEER Red Hat

1 0

Search Storage Domain [Ruby SDK]
by andres.b.dev＠gmail.com 18 May '19

18 May '19

I tried multiple example but none of them returns something. I want to get the first SD available, type=data and available > Required new disk size. 1) storage_domain = instance.system_service.storage_domains_service. list(search: "available >= #{(size * 2**30).to_i} AND status=\"active\" AND type=\"data\"").first 2) Also tested: storage_domain = instance.system_service.storage_domains_service. list(search: "available >= #{(size * 2**30).to_i} AND status=active AND type=data").first 3) Then, I decided to check with only 1 criteria storage_domain = instance.system_service.storage_domains_service. list(search: "type=data").first But all of them returns nothing. What I'm doing wrong?

1 1

Re: Ovirt: Upload Disk Snapshots problems with iSCSI storage and Java SDK
by fmgbDeb 17 May '19

17 May '19

Hi Nir, I attach ovirt-engine and, vdsm and image-io for if they help something. Thanks for your time, Regards, Fran

1 0

Re: Ovirt: Upload Disk Snapshots problems with iSCSI storage and Java SDK
by fmgbDeb 17 May '19

17 May '19

Hello Nir, I attach the files: engine.log of manager vdsm.log of host daemon.log of host

1 0

[Ovirt] [CQ weekly status] [17-05-2019]
by Dafna Ron 17 May '19

17 May '19

Hi, This mail is to provide the current status of CQ and allow people to review status before and after the weekend. Please refer to below colour map for further information on the meaning of the colours. *CQ-4.2*: GREEN (#1) Last failure was on 15-5 for project ovirt-ansible-engine-setup due to failure in test 002_bootstrap.add_master_storage_domain. The fix for this test was submitted and merged in ost: https://gerrit.ovirt.org/#/c/100089/ *CQ-4.3*: GREEN (#1) Last failure was on 16-05 for project ovirt-host due to a build-artifacts for fc28. the issue has been resolved. *CQ-Master:* RED (#1) We have a current failure in project ovirt-engine which started last night. The failure is in run vm test and caused by change: https://gerrit.ovirt.org/#/c/99372/6 - core: Initial Ignition support over custom script <https://gerrit.ovirt.org/#/c/99372/6> It already has a fix (thank you Roy for the fast response) and we are awaiting a merge for the patch: https://gerrit.ovirt.org/#/c/100133/ - core: handle a case where cloudinit script is null Current running jobs for 4.2 [1], 4.3 [2] and master [3] can be found here: [1] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-4.2_change-qu… [2] https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-4.3_change-q… [3] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change… Happy week! Dafna ------------------------------------------------------------------------------------------------------------------- COLOUR MAP Green = job has been passing successfully ** green for more than 3 days may suggest we need a review of our test coverage 1. 1-3 days GREEN (#1) 2. 4-7 days GREEN (#2) 3. Over 7 days GREEN (#3) Yellow = intermittent failures for different projects but no lasting or current regressions ** intermittent would be a healthy project as we expect a number of failures during the week ** I will not report any of the solved failures or regressions. 1. Solved job failures YELLOW (#1) 2. Solved regressions YELLOW (#2) Red = job has been failing ** Active Failures. The colour will change based on the amount of time the project/s has been broken. Only active regressions would be reported. 1. 1-3 days RED (#1) 2. 4-7 days RED (#2) 3. Over 7 days RED (#3)

1 0

[ OST Failure Report ] [ oVirt Master (ovirt-engine) ] [ 17-05-19 ] [ 004_basic_sanity.run_vms ]
by Dafna Ron 17 May '19

17 May '19

Hi, We are failing to run vm in project ovirt-engine on master branch on both basic and upgrade suites CQ reported this patch as root cause: https://gerrit.ovirt.org/#/c/99372/6 - core: Initial Ignition support over custom script <https://gerrit.ovirt.org/#/c/99372/6> I can see errors in the log related to cloud-init which happen at the same time we try to run the vm. There are also NPE on GetVMLeaseInfo happening before. Roy can you please take a look? Full logs from first failure can be found here: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/14148/artifac… Thanks, Dafna Error from log: 2019-05-16 12:53:46,184-04 INFO [org.ovirt.engine.core.vdsbroker.CreateVDSCommand] (default task-2) [ad7888f0-4368-4792-b6a8-f7cd4b0ebbe6] START, CreateVDSCommand( CreateVD SCommandParameters:{hostId='31dd3a99-5821-437b-8995-232cfcd67d84', vmId='362080c4-4d08-4b40-b6e7-9c04bf854d68', vm='VM [vm0]'}), log id: 522026aa 2019-05-16 12:53:46,190-04 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCommand] (default task-2) [ad7888f0-4368-4792-b6a8-f7cd4b0ebbe6] START, CreateBrok erVDSCommand(HostName = lago-basic-suite-master-host-1, CreateVDSCommandParameters:{hostId='31dd3a99-5821-437b-8995-232cfcd67d84', vmId='362080c4-4d08-4b40-b6e7-9c04bf854d68 ', vm='VM [vm0]'}), log id: 6bbd62c6 2019-05-16 12:53:46,201-04 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCommand] (default task-2) [ad7888f0-4368-4792-b6a8-f7cd4b0ebbe6] Failed in 'CreateBrokerVDS' method, for vds: 'lago-basic-suite-master-host-1'; host: 'lago-basic-suite-master-host-1': Failed to build cloud-init data: 2019-05-16 12:53:46,201-04 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCommand] (default task-2) [ad7888f0-4368-4792-b6a8-f7cd4b0ebbe6] Command 'CreateBrokerVDSCommand(HostName = lago-basic-suite-master-host-1, CreateVDSCommandParameters:{hostId='31dd3a99-5821-437b-8995-232cfcd67d84', vmId='362080c4-4d08-4b40-b6e7-9c04bf854d68', vm='VM [vm0]'})' execution failed: Failed to build cloud-init data: 2019-05-16 12:53:46,201-04 DEBUG [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCommand] (default task-2) [ad7888f0-4368-4792-b6a8-f7cd4b0ebbe6] Exception: java.lang.RuntimeException: Failed to build cloud-init data: at org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCommand.getPayload(CreateBrokerVDSCommand.java:177) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCommand.generateDomainXml(CreateBrokerVDSCommand.java:90) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCommand.createInfo(CreateBrokerVDSCommand.java:52) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCommand.executeVdsBrokerCommand(CreateBrokerVDSCommand.java:44) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.executeVdsCommandWithNetworkEvent(VdsBrokerCommand.java:123) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.executeVDSCommand(VdsBrokerCommand.java:111) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VDSCommandBase.executeCommand(VDSCommandBase.java:65) [vdsbroker.jar:] at org.ovirt.engine.core.dal.VdcCommandBase.execute(VdcCommandBase.java:31) [dal.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.DefaultVdsCommandExecutor.execute(DefaultVdsCommandExecutor.java:14) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.ResourceManager.runVdsCommand(ResourceManager.java:397) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.ResourceManager$Proxy$_$$_WeldSubclass.runVdsCommand(Unknown Source) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.CreateVDSCommand.executeVmCommand(CreateVDSCommand.java:37) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.ManagingVmCommand.executeVDSCommand(ManagingVmCommand.java:17) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VDSCommandBase.executeCommand(VDSCommandBase.java:65) [vdsbroker.jar:] at org.ovirt.engine.core.dal.VdcCommandBase.execute(VdcCommandBase.java:31) [dal.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.DefaultVdsCommandExecutor.execute(DefaultVdsCommandExecutor.java:14) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.ResourceManager.runVdsCommand(ResourceManager.java:397) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.ResourceManager$Proxy$_$$_WeldSubclass.runVdsCommand$$super(Unknown Source) [vdsbroker.jar:] at sun.reflect.GeneratedMethodAccessor253.invoke(Unknown Source) [:1.8.0_212] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_212] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_212] at org.jboss.weld.interceptor.proxy.TerminalAroundInvokeInvocationContext.proceedInternal(TerminalAroundInvokeInvocationContext.java:51) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.interceptor.proxy.AroundInvokeInvocationContext.proceed(AroundInvokeInvocationContext.java:78) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] : 2019-05-16 12:48:16,187-04 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmLeaseInfoVDSCommand] (default task-2) [47e9eeee-b7d1-44d3-b0fc-4807e5d0d582] Command 'GetVmLeaseInfoVDSCommand( VmLeaseVDSParameters:{expectedEngineErrors='[NoSuchVmLeaseOnDomain]', storagePoolId='3db881ca-6202-494c-a1e6-9b5db3aaec7e', ignoreFailoverLimit='false', leaseId='7f2d015e-c8a9-44c7-85e9-b26b55f946a7', storageDomainId='9b5428b8-8eb1-47de-8d0a-c5669d131630'})' execution failed: IRSGenericException: IRSErrorException: No such lease: 'lease=7f2d015e-c8a9-44c7-85e9-b26b55f946a7' 2019-05-16 12:48:16,187-04 DEBUG [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmLeaseInfoVDSCommand] (default task-2) [47e9eeee-b7d1-44d3-b0fc-4807e5d0d582] Exception: org.ovirt.engine.core.vdsbroker.irsbroker.IrsOperationFailedNoFailoverException: IRSGenericException: IRSErrorException: No such lease: 'lease=7f2d015e-c8a9-44c7-85e9-b26b55f946a7' at org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase.proceedProxyReturnValue(BrokerCommandBase.java:181) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmLeaseInfoVDSCommand.executeIrsBrokerCommand(GetVmLeaseInfoVDSCommand.java:21) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.irsbroker.IrsBrokerCommand.lambda$executeVDSCommand$0(IrsBrokerCommand.java:98) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.irsbroker.IrsProxy.runInControlledConcurrency(IrsProxy.java:274) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.irsbroker.IrsBrokerCommand.executeVDSCommand(IrsBrokerCommand.java:95) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VDSCommandBase.executeCommand(VDSCommandBase.java:65) [vdsbroker.jar:] at org.ovirt.engine.core.dal.VdcCommandBase.execute(VdcCommandBase.java:31) [dal.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.DefaultVdsCommandExecutor.execute(DefaultVdsCommandExecutor.java:14) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.ResourceManager.runVdsCommand(ResourceManager.java:397) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.ResourceManager$Proxy$_$$_WeldSubclass.runVdsCommand$$super(Unknown Source) [vdsbroker.jar:] at sun.reflect.GeneratedMethodAccessor253.invoke(Unknown Source) [:1.8.0_212] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_212] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_212] at org.jboss.weld.interceptor.proxy.TerminalAroundInvokeInvocationContext.proceedInternal(TerminalAroundInvokeInvocationContext.java:51) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.interceptor.proxy.AroundInvokeInvocationContext.proceed(AroundInvokeInvocationContext.java:78) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.ovirt.engine.core.common.di.interceptor.LoggingInterceptor.apply(LoggingInterceptor.java:12) [common.jar:] at sun.reflect.GeneratedMethodAccessor61.invoke(Unknown Source) [:1.8.0_212] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_212] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_212] at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeAroundInvoke(InterceptorMethodHandler.java:84) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:72) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:56) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:79) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:68) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.ovirt.engine.core.vdsbroker.ResourceManager$Proxy$_$$_WeldSubclass.runVdsCommand(Unknown Source) [vdsbroker.jar:] at org.ovirt.engine.core.bll.VDSBrokerFrontendImpl.runVdsCommand(VDSBrokerFrontendImpl.java:33) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.runVdsCommand(CommandBase.java:2075) [bll.jar:] at org.ovirt.engine.core.bll.storage.lease.GetVmLeaseInfoCommand.executeCommand(GetVmLeaseInfoCommand.java:65) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeWithoutTransaction(CommandBase.java:1157) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeActionInTransactionScope(CommandBase.java:1315) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:1964) [bll.jar:] at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInSuppressed(TransactionSupport.java:164) [utils.jar:] at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInScope(TransactionSupport.java:103) [utils.jar:] at org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1375) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:419) [bll.jar:] at org.ovirt.engine.core.bll.executor.DefaultBackendActionExecutor.execute(DefaultBackendActionExecutor.java:13) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:451) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:433) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:639) [bll.jar:] at sun.reflect.GeneratedMethodAccessor264.invoke(Unknown Source) [:1.8.0_212] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_212] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_212] at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:79) at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:89) at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:102) at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-15.0.1.Final.jar:15.0.1.Final]at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-15.0.1.Final.jar:15.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53) [wildfly-ejb3-15.0.1.Final.jar:15.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:216) [wildfly-ejb3-15.0.1.Final.jar:15.0.1.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.supports(CMTTxInterceptor.java:418) [wildfly-ejb3-15.0.1.Final.jar:15.0.1.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:148) [wildfly-ejb3-15.0.1.Final.jar:15.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:72) [weld-ejb-3.0.5.Final.jar:3.0.5.Final] at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-15.0.1.Final.jar:15.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) [wildfly-ejb3-15.0.1.Final.jar:15.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) [wildfly-ejb3-15.0.1.Final.jar:15.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) [wildfly-ejb3-15.0.1.Final.jar:15.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-15.0.1.Final.jar:15.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) [wildfly-ejb3-15.0.1.Final.jar:15.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:618) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:81) at org.ovirt.engine.core.bll.interfaces.BackendInternal$$$view2.runInternalAction(Unknown Source) [bll.jar:] at sun.reflect.GeneratedMethodAccessor263.invoke(Unknown Source) [:1.8.0_212] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_212] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_212] at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:410) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.module.ejb.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:134) [weld-ejb-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.module.ejb.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:68) [weld-ejb-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:106) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.ovirt.engine.core.bll.BackendCommandObjectsHandler$BackendInternal$BackendLocal$2049259618$Proxy$_$$_Weld$EnterpriseProxy$.runInternalAction(Unknown Source) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.runInternalAction(CommandBase.java:2348) [bll.jar:] at org.ovirt.engine.core.bll.storage.lease.AddVmLeaseCommand.executeCommand(AddVmLeaseCommand.java:48) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeWithoutTransaction(CommandBase.java:1157) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeActionInTransactionScope(CommandBase.java:1315) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:1964) [bll.jar:] at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInSuppressed(TransactionSupport.java:164) [utils.jar:] at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInSuppressed(TransactionSupport.java:164) [utils.jar:] at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInScope(TransactionSupport.java:103) [utils.jar:] at org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1375) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:419) [bll.jar:] at org.ovirt.engine.core.bll.executor.DefaultBackendActionExecutor.execute(DefaultBackendActionExecutor.java:13) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:451) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:433) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:639) [bll.jar:] at sun.reflect.GeneratedMethodAccessor264.invoke(Unknown Source) [:1.8.0_212] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_212] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_212] at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:79) at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:89) at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:102) at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-15.0.1.Final.jar:15.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-15.0.1.Final.jar:15.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53) [wildfly-ejb3-15.0.1.Final.jar:15.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:185) [wildfly-ejb3-15.0.1.Final.jar:15.0.1.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.supports(CMTTxInterceptor.java:420) [wildfly-ejb3-15.0.1.Final.jar:15.0.1.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:148) [wildfly-ejb3-15.0.1.Final.jar:15.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:72) [weld-ejb-3.0.5.Final.jar:3.0.5.Final] at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-15.0.1.Final.jar:15.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) [wildfly-ejb3-15.0.1.Final.jar:15.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) [wildfly-ejb3-15.0.1.Final.jar:15.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) [wildfly-ejb3-15.0.1.Final.jar:15.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-15.0.1.Final.jar:15.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) [wildfly-ejb3-15.0.1.Final.jar:15.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:618) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:81) at org.ovirt.engine.core.bll.interfaces.BackendInternal$$$view2.runInternalAction(Unknown Source) [bll.jar:] at sun.reflect.GeneratedMethodAccessor263.invoke(Unknown Source) [:1.8.0_212] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_212] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_212] at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:410) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.module.ejb.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:134) [weld-ejb-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.module.ejb.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:68) [weld-ejb-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:106) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.ovirt.engine.core.bll.BackendCommandObjectsHandler$BackendInternal$BackendLocal$2049259618$Proxy$_$$_Weld$EnterpriseProxy$.runInternalAction(Unknown Source) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.runInternalAction(CommandBase.java:2354) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.runInternalActionWithTasksContext(CommandBase.java:2379) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.runInternalActionWithTasksContext(CommandBase.java:2374) [bll.jar:] at org.ovirt.engine.core.bll.VmCommand.addVmLease(VmCommand.java:541) [bll.jar:] at org.ovirt.engine.core.bll.UpdateVmCommand.updateVmLease(UpdateVmCommand.java:428) [bll.jar:] at org.ovirt.engine.core.bll.UpdateVmCommand.executeVmCommand(UpdateVmCommand.java:316) [bll.jar:] at org.ovirt.engine.core.bll.VmCommand.executeCommand(VmCommand.java:172) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeWithoutTransaction(CommandBase.java:1157) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeActionInTransactionScope(CommandBase.java:1315) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:1964) [bll.jar:] at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInNewTransaction(TransactionSupport.java:202) [utils.jar:] at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInRequired(TransactionSupport.java:137) [utils.jar:] at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInScope(TransactionSupport.java:105) [utils.jar:] at org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1375) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:419) [bll.jar:] at org.ovirt.engine.core.bll.executor.DefaultBackendActionExecutor.execute(DefaultBackendActionExecutor.java:13) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:451) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:433) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:388) [bll.jar:] at sun.reflect.GeneratedMethodAccessor195.invoke(Unknown Source) [:1.8.0_212] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_212] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_212] at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) at org.jboss.as.weld.ejb.DelegatingInterceptorInvocationContext.proceed(DelegatingInterceptorInvocationContext.java:92) [wildfly-weld-ejb-15.0.1.Final.jar:15.0.1.Final]at org.jboss.weld.interceptor.proxy.WeldInvocationContextImpl.interceptorChainCompleted(WeldInvocationContextImpl.java:107) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.interceptor.proxy.WeldInvocationContextImpl.proceed(WeldInvocationContextImpl.java:126) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.ovirt.engine.core.common.di.interceptor.LoggingInterceptor.apply(LoggingInterceptor.java:12) [common.jar:] at sun.reflect.GeneratedMethodAccessor61.invoke(Unknown Source) [:1.8.0_212] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_212] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_212] at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.interceptor.proxy.WeldInvocationContextImpl.invokeNext(WeldInvocationContextImpl.java:92) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.interceptor.proxy.WeldInvocationContextImpl.proceed(WeldInvocationContextImpl.java:124) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.bean.InterceptorImpl.intercept(InterceptorImpl.java:105) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.as.weld.ejb.DelegatingInterceptorInvocationContext.proceed(DelegatingInterceptorInvocationContext.java:82) [wildfly-weld-ejb-15.0.1.Final.jar:15.0.1.Final] at org.jboss.as.weld.interceptors.EjbComponentInterceptorSupport.delegateInterception(EjbComponentInterceptorSupport.java:60) at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:77) at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:89) at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:102) at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) at org.ovirt.engine.core.bll.interceptors.CorrelationIdTrackerInterceptor.aroundInvoke(CorrelationIdTrackerInterceptor.java:13) [bll.jar:] at sun.reflect.GeneratedMethodAccessor56.invoke(Unknown Source) [:1.8.0_212] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_212] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_212] at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:89) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-15.0.1.Final.jar:15.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-15.0.1.Final.jar:15.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53) [wildfly-ejb3-15.0.1.Final.jar:15.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:216) [wildfly-ejb3-15.0.1.Final.jar:15.0.1.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.supports(CMTTxInterceptor.java:418) [wildfly-ejb3-15.0.1.Final.jar:15.0.1.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:148) [wildfly-ejb3-15.0.1.Final.jar:15.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81) [weld-ejb-3.0.5.Final.jar:3.0.5.Final] at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-15.0.1.Final.jar:15.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) [wildfly-ejb3-15.0.1.Final.jar:15.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) [wildfly-ejb3-15.0.1.Final.jar:15.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) [wildfly-ejb3-15.0.1.Final.jar:15.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-15.0.1.Final.jar:15.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) [wildfly-ejb3-15.0.1.Final.jar:15.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:618) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:81) at org.ovirt.engine.core.common.interfaces.BackendLocal$$$view3.runAction(Unknown Source) [common.jar:] at org.ovirt.engine.api.restapi.resource.BackendResource.doAction(BackendResource.java:250) at org.ovirt.engine.api.restapi.resource.BackendResource.performAction(BackendResource.java:182) at org.ovirt.engine.api.restapi.resource.BackendResource.performAction(BackendResource.java:174) at org.ovirt.engine.api.restapi.resource.AbstractBackendSubResource.doUpdate(AbstractBackendSubResource.java:92) at org.ovirt.engine.api.restapi.resource.AbstractBackendSubResource.performUpdate(AbstractBackendSubResource.java:81) at org.ovirt.engine.api.restapi.resource.BackendVmResource.update(BackendVmResource.java:173) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_212] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_212] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_212] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_212] at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.6.2.Final.jar:3.6.2.Final] at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509) [resteasy-jaxrs-3.6.2.Final.jar:3.6.2.Final] at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399) [resteasy-jaxrs-3.6.2.Final.jar:3.6.2.Final] at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363) [resteasy-jaxrs-3.6.2.Final.jar:3.6.2.Final] at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355) [resteasy-jaxrs-3.6.2.Final.jar:3.6.2.Final] at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365) [resteasy-jaxrs-3.6.2.Final.jar:3.6.2.Final] at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337) [resteasy-jaxrs-3.6.2.Final.jar:3.6.2.Final] at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:137) [resteasy-jaxrs-3.6.2.Final.jar:3.6.2.Final] at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:106) [resteasy-jaxrs-3.6.2.Final.jar:3.6.2.Final] at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:132) [resteasy-jaxrs-3.6.2.Final.jar:3.6.2.Final] at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:100) [resteasy-jaxrs-3.6.2.Final.jar:3.6.2.Final] at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:439) [resteasy-jaxrs-3.6.2.Final.jar:3.6.2.Final] at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:229) [resteasy-jaxrs-3.6.2.Final.jar:3.6.2.Final] at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:135) [resteasy-jaxrs-3.6.2.Final.jar:3.6.2.Final] at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355) [resteasy-jaxrs-3.6.2.Final.jar:3.6.2.Final] at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:138) [resteasy-jaxrs-3.6.2.Final.jar:3.6.2.Final] at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:215) [resteasy-jaxrs-3.6.2.Final.jar:3.6.2.Final] at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227) [resteasy-jaxrs-3.6.2.Final.jar:3.6.2.Final] at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.6.2.Final.jar:3.6.2.Final] at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.6.2.Final.jar:3.6.2.Final] at javax.servlet.http.HttpServlet.service(HttpServlet.java:791) [jboss-servlet-api_4.0_spec-1.0.0.Final.jar:1.0.0.Final] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74) at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:81) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:274) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:209) at io.undertow.servlet.spec.RequestDispatcherImpl.forwardImpl(RequestDispatcherImpl.java:223) at io.undertow.servlet.spec.RequestDispatcherImpl.forwardImplSetup(RequestDispatcherImpl.java:149) at io.undertow.servlet.spec.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:111) at org.ovirt.engine.api.restapi.invocation.VersionFilter.doFilter(VersionFilter.java:178) at org.ovirt.engine.api.restapi.invocation.VersionFilter.doFilter(VersionFilter.java:98) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.api.restapi.invocation.CurrentFilter.doFilter(CurrentFilter.java:117) at org.ovirt.engine.api.restapi.invocation.CurrentFilter.doFilter(CurrentFilter.java:72) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.core.aaa.filters.RestApiSessionMgmtFilter.doFilter(RestApiSessionMgmtFilter.java:78) [aaa.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.core.aaa.filters.EnforceAuthFilter.doFilter(EnforceAuthFilter.java:42) [aaa.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.core.aaa.filters.SsoRestApiNegotiationFilter.doFilter(SsoRestApiNegotiationFilter.java:84) [aaa.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.core.aaa.filters.SsoRestApiAuthFilter.doFilter(SsoRestApiAuthFilter.java:47) [aaa.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.core.aaa.filters.SessionValidationFilter.doFilter(SessionValidationFilter.java:59) [aaa.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.core.aaa.filters.RestApiSessionValidationFilter.doFilter(RestApiSessionValidationFilter.java:35) [aaa.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.api.restapi.security.CSRFProtectionFilter.doFilter(CSRFProtectionFilter.java:111) at org.ovirt.engine.api.restapi.security.CSRFProtectionFilter.doFilter(CSRFProtectionFilter.java:102) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.core.utils.servlet.CORSSupportFilter.doFilter(CORSSupportFilter.java:283) [utils.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830) at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_212] 2019-05-16 12:48:16,231-04 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmLeaseInfoVDSCommand] (default task-2) [47e9eeee-b7d1-44d3-b0fc-4807e5d0d582] FINISH, GetVmLeaseInfoVDSCommand, return: , log id: 1735f267 2019-05-16 12:48:16,231-04 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (default task-2) [47e9eeee-b7d1-44d3-b0fc-4807e5d0d582] method: runVdsCommand, params: [GetVmLeaseInfo, VmLeaseVDSParameters:{expectedEngineErrors='[NoSuchVmLeaseOnDomain]', storagePoolId='3db881ca-6202-494c-a1e6-9b5db3aaec7e', ignoreFailoverLimit='false', leaseId='7f2d015e-c8a9-44c7-85e9-b26b55f946a7', storageDomainId='9b5428b8-8eb1-47de-8d0a-c5669d131630'}], timeElapsed: 109ms 2019-05-16 12:48:16,235-04 INFO [org.ovirt.engine.core.bll.storage.lease.AddVmLeaseCommand] (default task-2) [47e9eeee-b7d1-44d3-b0fc-4807e5d0d582] Creating new VM '7f2d015e-c8a9-44c7-85e9-b26b55f946a7' lease, because the VM lease doesn't exists on storage domain '9b5428b8-8eb1-47de-8d0a-c5669d131630' 2019-05-16 12:48:16,303-04 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.AddVmLeaseVDSCommand] (default task-2) [47e9eeee-b7d1-44d3-b0fc-4807e5d0d582] START, AddVmLeaseVDSCommand( VmLeaseVDSParameters:{storagePoolId='3db881ca-6202-494c-a1e6-9b5db3aaec7e', ignoreFailoverLimit='false', leaseId='7f2d015e-c8a9-44c7-85e9-b26b55f946a7', storageDomainId='9b5428b8-8eb1-47de-8d0a-c5669d131630'}), log id: 2bcf059e 2019-05-16 12:48:16,304-04 DEBUG [org.ovirt.vdsm.jsonrpc.client.reactors.stomp.impl.Message] (default task-2) [47e9eeee-b7d1-44d3-b0fc-4807e5d0d582] SEND ovirtCorrelationId:47e9eeee-b7d1-44d3-b0fc-4807e5d0d582 destination:jms.topic.vdsm_irs_requests reply-to:jms.topic.vdsm_irs_responses content-length:203

2 1

Re: Ovirt: Upload Disk Snapshots problems with iSCSI storage and Java SDK
by fmgb 17 May '19

17 May '19

Hi Nir and Daniel, I am trying this case(Restore with snapshots' size > 1Gb in iSCSI storage) in RHV4.3, and I am getting the same error. I try to create the diskSnapshots with same sizes (with initialSize > 1Gb, when it is needed) and they are created with initialSize = 1Gb. Regards, Fran

1 0

proposing Ales Musil as a frontend maintainer
by Greg Sheremeta 17 May '19

17 May '19

Hi all, I'd like to propose Ales Musil as a frontend maintainer for network parts of the admin portal UI. Since joining the team 2 years ago, Ales has quickly become very knowledgeable about all of the GWT intricacies of the admin portal. I trust his expertise and judgment. Best wishes, Greg -- Greg Sheremeta Senior Software Engineer Red Hat <https://www.redhat.com/> <https://www.redhat.com/>

7 8

ovirt-system-tests_compat-4.2-suite-master failing for 3 weeks?
by Doron Fediuck 17 May '19

17 May '19

https://jenkins.ovirt.org/job/ovirt-system-tests_compat-4.2-suite-master/55… The current failure is on adding a storage domain. Did anyone review it?

7 10

Fedora 30 is available in STD-CI.
by Ehud Yonasi 16 May '19

16 May '19

Hey everyone, If you want to build your packages on top of fc30 it is now available. Also, we are planning to drop the support for fc27 as it is EOL, so if you could please prepare patches to remove it, it would be greatly appreciated. Regards, Ehud Yonasi.

2 1

engine setup on F30 is broken due to missing python3-ovirt_setup_lib
by Roy Golan 16 May '19

16 May '19

We still didn't build python3-ovirt-setup-lib for f30, so engine-setup will fail for those of you using f30. If you want it to work, install the f29 version: https://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc29/noarch/pytho… +Gal Zaidman <gzaidman(a)redhat.com> +Yedidyah Bar David <didi(a)redhat.com>

2 1

Re: make rpm for vdsm on CentOS Linux release 7.6.1810 (Core)
by Nir Soffer 15 May '19

15 May '19

On Wed, May 15, 2019 at 4:28 PM Amit Bawer <abawer(a)redhat.com> wrote: > Hi, > > I am trying to follow the basic procedure described here > https://github.com/oVirt/vdsm > This is not a good place to look for the instructions. The right place is: https://ovirt.org/develop/developer-guide/vdsm/developers.html > to build vdsm rpm from source on my CentOS Linux release 7.6.1810 (Core) > host. > had to add some dependencies on the way ofcourse, so at that point i am > able to make most of it except for python error described below resulting > from the "make rpm" part of procedure. > > Am I missing something? > This is a good topic for devel, adding. > > Thanks > > make[1]: Entering directory `/home/abawer/rpmbuild/BUILD/vdsm-4.40.0' > Makefile:1002: warning: overriding recipe for target `check-recursive' > Makefile:533: warning: ignoring old recipe for target `check-recursive' > Making all in contrib > make[2]: Entering directory > `/home/abawer/rpmbuild/BUILD/vdsm-4.40.0/contrib' > make[2]: Nothing to be done for `all'. > make[2]: Leaving directory > `/home/abawer/rpmbuild/BUILD/vdsm-4.40.0/contrib' > Making all in helpers > make[2]: Entering directory > `/home/abawer/rpmbuild/BUILD/vdsm-4.40.0/helpers' > make[2]: Nothing to be done for `all'. > make[2]: Leaving directory > `/home/abawer/rpmbuild/BUILD/vdsm-4.40.0/helpers' > Making all in init > make[2]: Entering directory `/home/abawer/rpmbuild/BUILD/vdsm-4.40.0/init' > Making all in systemd > make[3]: Entering directory > `/home/abawer/rpmbuild/BUILD/vdsm-4.40.0/init/systemd' > MKDIR_P ./ > SED vdsm-tmpfiles.d.conf > make[3]: Leaving directory > `/home/abawer/rpmbuild/BUILD/vdsm-4.40.0/init/systemd' > make[3]: Entering directory `/home/abawer/rpmbuild/BUILD/vdsm-4.40.0/init' > MKDIR_P ./ > SED vdsmd_init_common.sh > make[3]: Leaving directory `/home/abawer/rpmbuild/BUILD/vdsm-4.40.0/init' > make[2]: Leaving directory `/home/abawer/rpmbuild/BUILD/vdsm-4.40.0/init' > Making all in lib > make[2]: Entering directory `/home/abawer/rpmbuild/BUILD/vdsm-4.40.0/lib' > Making all in sos > make[3]: Entering directory > `/home/abawer/rpmbuild/BUILD/vdsm-4.40.0/lib/sos' > MKDIR_P ./ > SED vdsm.py > make[3]: Leaving directory > `/home/abawer/rpmbuild/BUILD/vdsm-4.40.0/lib/sos' > Making all in vdsm > make[3]: Entering directory > `/home/abawer/rpmbuild/BUILD/vdsm-4.40.0/lib/vdsm' > Making all in api > make[4]: Entering directory > `/home/abawer/rpmbuild/BUILD/vdsm-4.40.0/lib/vdsm/api' > Generate vdsm-api.html > chmod u+w . > PYTHONPATH=./../../:./../../vdsm \ > python2.7 ./schema_to_html.py vdsm-api ./vdsm-api.html > Traceback (most recent call last): > File "./schema_to_html.py", line 250, in <module> > main() > File "./schema_to_html.py", line 240, in main > > * choices=[st.value for st in vdsmapi.SchemaType])TypeError: 'type' > object is not iterable* > Never had this error. After you prepare the host as described in: https://ovirt.org/develop/developer-guide/vdsm/developers.html#installing-t… https://ovirt.org/develop/developer-guide/vdsm/developers.html#getting-the-… https://ovirt.org/develop/developer-guide/vdsm/developers.html#installing-t… is to install latest release of vdsm: yum install vdsm vdsm-client Otherwise you will have to painfully install some of the packages or install lot of packages you don't need (e.g. mostly lot of hooks). When your host is ready, you can build vdsm from source and upgrade the installed packages: git clean -dxf ./autogen.sh --system --enable-timestamp make rm -rf ~/rpmbuild make rpm (cd ~/rpmbuild/RPMS && sudo yum upgrade */*.rpm) I think we should drop instructions in vdsm README, and point to the page on ovirt.org, or replace them with short version that works and easier to maintain. Nir

2 1

Running sub stages using https://jenkins.ovirt.org/job/standard-manual-runner/
by Nir Soffer 15 May '19

15 May '19

I tried to run check-patch and check-patch linters substage from the command line: using: https://github.com/nirs/oci/pull/37 I assumed that this will run the entire check-patch stage, including all the sub stages: ./ovirt-ci run -s check-patch 100007 But it run something that looks like check-patch with el7: https://jenkins.ovirt.org/blue/organizations/jenkins/standard-manual-runner… The test environment seems to be different that what we have when check-patch is triggered from gerrit. Then I tried to run the linters substage: ./ovirt-ci run -s check-patch.linters 100007 https://jenkins.ovirt.org/blue/organizations/jenkins/standard-manual-runner… ./ovirt-ci run -s check-patch.linters 100007 https://jenkins.ovirt.org/blue/organizations/jenkins/standard-manual-runner… Both succeeded without running anything :-) Running build-artifacts works, not sure about check-network. Can we fix the manual job so: - it run exactly the same way as it run when gerrit trigger the job - allow selection of a sub stage? - nice to have - allow selection of multiple sub stages Nir

1 1

vdsm has been tagged (v4.30.15)
by Milan Zamazal 14 May '19

14 May '19

1 0

import VM from data domain
by IT INFRA 14 May '19

14 May '19

Hi, This forum really help me a lot..Thanks everyone I have an problem on importing VM from newly imported data domain storage, this is the scenario. 1) New engine restore from backup (4.1 version) 2) Import old storage domain using domain function (data) problem: I can't see any VM to import in (VM Import tab) Please help me import my old VM... Sorry for my bad English,... Thanks,

1 0

ovirt 4.1 backup/restore
by IT INFRA 14 May '19

14 May '19

Hi, It is possible to install ovirt 4.1 the old version upong checking on this link (http://mirror.centos.org/centos/7/virt/x86_64/) no 4.1 version, Used for restoring old backup engine. Thanks,

3 4

vdsm has been tagged (v4.30.14)
by Milan Zamazal 14 May '19

14 May '19

1 0

ovirt-engine has been tagged (ovirt-engine-4.3.4)
by Tal Nisan 14 May '19

14 May '19

1 0

Re: Ovirt: Upload Disk Snapshots problems with iSCSI storage and Java SDK
by fmgbDeb 13 May '19

13 May '19

Hello Nir, Thanks for your response and your time. I tried put the initial_size when I create the snapshot, but it hasn't worked. I attached 3 files: 1.- A bit of my code -> code.java 2.- Log where it show the JSON content of request SDK -> request.log I create 4 snapshots, the POST requests are in lines: 31-163 363-494 605-736 849-980 3.- Text with size of disks and its disksSnapshots -> sizes.txt I'm trying in RHVM 4.2 version. Regards, Fran

1 0

Help needed: VDSM code to check is a host is up
by Kaustav Majumder 13 May '19

13 May '19

Hi, i am working on https://bugzilla.redhat.com/show_bug.cgi?id=1699512 in which i am required to check if a host with a given hostuuid is up before I can issues another commands. Is there any code which I can reuse to check the host status. -- Thanks, Kaustav Majumder

2 1

Testing oVirt with Gluster 6
by Simone Tiraboschi 13 May '19

13 May '19

Hi, according to https://bugzilla.redhat.com/show_bug.cgi?id=1673058 the network throughput usage increases by a x5 upgrading from Gluster 3.12 to Gluster 5.y. This seems definitively problematic on our hyper-converged environments: I read more than one report where, over 1 Gbps network, sanlock could not be refreshed quickly enough and so killed the engine VM if not rebooted the host due to the watchdog. This is probably due to the fact that, according to that bug, the network got completely saturated. Faster networks seems still fine. https://bugzilla.redhat.com/show_bug.cgi?id=1673058 is probably going to be solved for Gluster 5.6. On the other side we have https://bugzilla.redhat.com/1693998 <https://bugzilla.redhat.com/show_bug.cgi?id=1693998> about rebasing over Gluster 6 which seems not affected by that issue. Do you have concrete plans about testing oVirt with Gluster 6? thanks, Simone

5 7

Build artifacts failed - not enough free space on file system
by Nir Soffer 12 May '19

12 May '19

I had this failure in yum install: [2019-05-12T14:54:55.706Z] Error Summary [2019-05-12T14:54:55.706Z] ------------- [2019-05-12T14:54:55.706Z] Disk Requirements: [2019-05-12T14:54:55.706Z] At least 70MB more space needed on the / filesystem. Build: https://jenkins.ovirt.org/blue/organizations/jenkins/standard-manual-runner… Trying build again, hopefully will get a slave with more space... Nir

2 4

Re: [CQ]: 99533,1 (ovirt-vmconsole) failed "ovirt-4.2" system tests
by Eyal Edri 12 May '19

12 May '19

Adding Galit. Not sure why it requires new image, can you elaborate? On Fri, May 10, 2019, 17:10 Dafna Ron <dron(a)redhat.com> wrote: > we may need new lago images as I think the selinux conf is overwritten > when we upgrade newer packages. > > > http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/4323/testReport/… > > On Fri, May 10, 2019 at 2:25 PM oVirt Jenkins <jenkins(a)ovirt.org> wrote: > >> Change 99533,1 (ovirt-vmconsole) is probably the reason behind recent >> system >> test failures in the "ovirt-4.2" change queue and needs to be fixed. >> >> This change had been removed from the testing queue. Artifacts build from >> this >> change will not be released until it is fixed. >> >> For further details about the change see: >> https://gerrit.ovirt.org/#/c/99533/1 >> >> For failed test results see: >> http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/4323/ >> _______________________________________________ >> Infra mailing list -- infra(a)ovirt.org >> To unsubscribe send an email to infra-leave(a)ovirt.org >> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >> oVirt Code of Conduct: >> https://www.ovirt.org/community/about/community-guidelines/ >> List Archives: >> https://lists.ovirt.org/archives/list/infra@ovirt.org/message/NI7TPHGBKRGWI… >> > _______________________________________________ > Infra mailing list -- infra(a)ovirt.org > To unsubscribe send an email to infra-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/infra@ovirt.org/message/VDWLW6XCGNAGQ… >

2 3

[Ovirt] [CQ weekly status] [10-05-2019]
by Dafna Ron 10 May '19

10 May '19

Hi, This mail is to provide the current status of CQ and allow people to review status before and after the weekend. Please refer to below colour map for further information on the meaning of the colours. *CQ-4.2*: RED (#1) mom is failing on package dependency: mom-0.5.12-0.0.master.el7.noarch requires python2-libvirt. The package is a fc package and should not be a dependency for centos. This was introduced with this patch: https://gerrit.ovirt.org/#/c/99791/ Sandro has been notified and he will have a look once he finishes handling more urgent issues. *CQ-4.3*: RED (#1) Last Failure was yesterday for mom. its the same issue as in 4.2 *CQ-Master:* RED (#1) we have a failure in vdsm project. mail was reported to the list and being investigated further by Marcin and Milan. The issue seems to be in the upgrade from release suite in run_vm test (RPC call VM.create failed (error 16)) patch submitted to fix https://gerrit.ovirt.org/#/c/99899/ The random failures seemed to have been solved by Galit and help from developers. I will continue to monitor and report in case we have further failures Current running jobs for 4.2 [1], 4.3 [2] and master [3] can be found here: [1] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-4.2_change-qu… [2] https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-4.3_change-q… [3] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change… Happy week! Dafna ------------------------------------------------------------------------------------------------------------------- COLOUR MAP Green = job has been passing successfully ** green for more than 3 days may suggest we need a review of our test coverage 1. 1-3 days GREEN (#1) 2. 4-7 days GREEN (#2) 3. Over 7 days GREEN (#3) Yellow = intermittent failures for different projects but no lasting or current regressions ** intermittent would be a healthy project as we expect a number of failures during the week ** I will not report any of the solved failures or regressions. 1. Solved job failures YELLOW (#1) 2. Solved regressions YELLOW (#2) Red = job has been failing ** Active Failures. The colour will change based on the amount of time the project/s has been broken. Only active regressions would be reported. 1. 1-3 days RED (#1) 2. 4-7 days RED (#2) 3. Over 7 days RED (#3)

2 1

[ OST Failure Report ] [ oVirt Master (vdsm) ] [ 10-05-2019 ] [ 004_basic_sanity.vm_run ]
by Dafna Ron 10 May '19

10 May '19

Hi, We are failing upgrade-from-release-suite.el7.x86_64 / 004_basic_sanity.vm_run The issue is an unexpected exception in vdsm. root cause based on CQ is this patch: https://gerrit.ovirt.org/#/c/99854/ - yum: Allow downloading only 'vdsm' package Logs can be found here: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/14079/artifac… Marcin, can you please take a look? error: vdsm: 2019-05-10 05:06:38,329-0400 ERROR (jsonrpc/0) [api] FINISH create error=Unexpected exception (api:131) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 124, in method ret = func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/API.py", line 245, in create raise exception.UnexpectedError() UnexpectedError: Unexpected exception 2019-05-10 05:06:38,330-0400 INFO (jsonrpc/0) [api.virt] FINISH create return={'status': {'message': 'Unexpected exception', 'code': 16}} from=::ffff:192.168.201.2,39486, flow_id=83e4f0c4-a39a-45aa-891f-4022765e1a87, vmId=397013a0-b7d4-4d38-86c3-e944cebd75a7 (api:54) 2019-05-10 05:06:38,331-0400 INFO (jsonrpc/0) [jsonrpc.JsonRpcServer] RPC call VM.create failed (error 16) in 0.00 seconds (__init__:312) 2019-05-10 05:06:38,629-0400 INFO (jsonrpc/7) [vdsm.api] FINISH getStorageDomainInfo return={'info': {'uuid': '24498263-8985-46a9-9161-f65ee776cb7f', 'vgMetadataDevice': '360014051f333158820a4cc6ab3be5b55', 'vguuid': 'rXTLNc-JwEz-0dtL-Z2EC-ASqn-gzkg-jDJa1b', 'metadataDevice': '360014051f333158820a4cc6ab3be5b55', 'state': 'OK', 'version': '4', 'role': 'Master', 'type': 'ISCSI', 'class': 'Data', 'pool': ['3e330122-c587-4078-b9a4-13dbb697c5cc'], 'name': 'iscsi'}} from=::ffff:192.168.201.2,39486, flow_id=3f76d32a, task_id=084e7ee5-3c43-4905-833f-9a522043a862 (api:54) engine: 2019-05-10 05:06:38,328-04 ERROR [org.ovirt.engine.core.vdsbroker.CreateVDSCommand] (default task-1) [83e4f0c4-a39a-45aa-891f-4022765e1a87] VDS::create Failed creating vm 'v m0' in vds = '566eda0f-3ef0-4791-a618-1e649af4b0be' error = 'org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException: VDSGenericException: VDSErrorException: Failed to C reateBrokerVDS, error = Unexpected exception, code = 16' 2019-05-10 05:06:38,328-04 INFO [org.ovirt.engine.core.vdsbroker.CreateVDSCommand] (default task-1) [83e4f0c4-a39a-45aa-891f-4022765e1a87] FINISH, CreateVDSCommand, return: Down, log id: 3cb7c62d 2019-05-10 05:06:38,328-04 WARN [org.ovirt.engine.core.bll.RunVmCommand] (default task-1) [83e4f0c4-a39a-45aa-891f-4022765e1a87] Failed to run VM 'vm0': EngineException: or g.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException: VDSGenericException: VDSErrorException: Failed to CreateBrokerVDS, error = Unexpected exception, code = 16 (Failed with error unexpected and code 16) 2019-05-10 05:06:38,328-04 INFO [org.ovirt.engine.core.bll.RunVmOnceCommand] (default task-1) [83e4f0c4-a39a-45aa-891f-4022765e1a87] Lock freed to object 'EngineLock:{exclu siveLocks='[397013a0-b7d4-4d38-86c3-e944cebd75a7=VM]', sharedLocks=''}' 2019-05-10 05:06:38,329-04 INFO [org.ovirt.engine.core.bll.RunVmCommand] (default task-1) [83e4f0c4-a39a-45aa-891f-4022765e1a87] Trying to rerun VM 'vm0' 2019-05-10 05:06:38,373-04 WARN [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-1) [83e4f0c4-a39a-45aa-891f-4022765e1a87] EVENT_ID: USE R_INITIATED_RUN_VM_FAILED(151), Failed to run VM vm0 on Host lago-upgrade-from-release-suite-master-host-0. 2019-05-10 05:06:38,381-04 INFO [org.ovirt.engine.core.bll.RunVmOnceCommand] (default task-1) [83e4f0c4-a39a-45aa-891f-4022765e1a87] Lock Acquired to object 'EngineLock:{ex clusiveLocks='[397013a0-b7d4-4d38-86c3-e944cebd75a7=VM]', sharedLocks=''}' 2019-05-10 05:06:38,393-04 INFO [org.ovirt.engine.core.vdsbroker.IsVmDuringInitiatingVDSCommand] (default task-1) [83e4f0c4-a39a-45aa-891f-4022765e1a87] START, IsVmDuringIn itiatingVDSCommand( IsVmDuringInitiatingVDSCommandParameters:{vmId='397013a0-b7d4-4d38-86c3-e944cebd75a7'}), log id: 96be328 2019-05-10 05:06:38,393-04 INFO [org.ovirt.engine.core.vdsbroker.IsVmDuringInitiatingVDSCommand] (default task-1) [83e4f0c4-a39a-45aa-891f-4022765e1a87] FINISH, IsVmDuringI nitiatingVDSCommand, return: false, log id: 96be328 2019-05-10 05:06:38,403-04 WARN [org.ovirt.engine.core.bll.RunVmOnceCommand] (default task-1) [83e4f0c4-a39a-45aa-891f-4022765e1a87] Validation of action 'RunVmOnce' failed for user admin@internal-authz. Reasons: VAR__ACTION__RUN,VAR__TYPE__VM,VAR__ACTION__RUN,VAR__TYPE__VM,SCHEDULING_NO_HOSTS 2019-05-10 05:06:38,404-04 INFO [org.ovirt.engine.core.bll.RunVmOnceCommand] (default task-1) [83e4f0c4-a39a-45aa-891f-4022765e1a87] Lock freed to object 'EngineLock:{exclu siveLocks='[397013a0-b7d4-4d38-86c3-e944cebd75a7=VM]', sharedLocks=''}' 2019-05-10 05:06:38,413-04 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-1) [83e4f0c4-a39a-45aa-891f-4022765e1a87] EVENT_ID: USE R_FAILED_RUN_VM(54), Failed to run VM vm0 (User: admin@internal-authz). 2019-05-10 05:06:38,462-04 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-1) [] Operation Failed: [There are no hosts to use. Check that the cluster contains at least one host in Up state.] 2019-05-10 05:06:38,466-04 INFO [org.ovirt.engine.core.bll.ProcessDownVmCommand] (EE-ManagedThreadFactory-engine-Thread-35) [3f40b3e8] Running command: ProcessDownVmCommand internal: true. Thanks, Dafna

3 4

Subject: [ OST Failure Report ] [ oVirt Master (ovirt-engine) ] [ 05-05-2019 ] [ upgrade_hosts ]
by Dafna Ron 10 May '19

10 May '19

Hi, We are failing test upgrade_hosts on upgrade-from-release-suite-master. From the logs I can see that we are calling migrate vm when we have only one host and the vm seem to have been shut down before the maintenance call is issued. Can you please look into this? suspected patch reported as root cause by CQ is: https://gerrit.ovirt.org/#/c/98920/ - core: Add MigrateMultipleVms command and use it for host maintenance logs are found here: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/14021/artifac… I can see the issue is vm migration when putting host in maintenance: 2019-05-07 06:02:04,170-04 INFO [org.ovirt.engine.core.bll.MaintenanceVdsCommand] (EE-ManagedThreadFactory-commandCoordinator-Thread-2) [05592db2-f859-487b-b779-4b32eec5bab 3] Running command: MaintenanceVdsCommand internal: true. Entities affected : ID: 38e1379b-c3b6-4a2e-91df-d1f346e414a9 Type: VDS 2019-05-07 06:02:04,215-04 WARN [org.ovirt.engine.core.bll.MigrateMultipleVmsCommand] (EE-ManagedThreadFactory-commandCoordinator-Thread-2) [33485140] Validation of action 'MigrateMultipleVms' failed for user admin@internal-authz. Reasons: ACTION_TYPE_FAILED_VMS_NOT_FOUND 2019-05-07 06:02:04,221-04 ERROR [org.ovirt.engine.core.bll.MaintenanceVdsCommand] (EE-ManagedThreadFactory-commandCoordinator-Thread-2) [33485140] Failed to migrate one or more VMs. 2019-05-07 06:02:04,227-04 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-commandCoordinator-Thread-2) [33485140] EVEN T_ID: VDS_MAINTENANCE_FAILED(17), Failed to switch Host lago-upgrade-from-release-suite-master-host-0 to Maintenance mode. 2019-05-07 06:02:04,239-04 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand] (EE-ManagedThreadFactory-commandCoordinator-Thread-2) [70840477] Lock Acquired to object 'Eng ineLock:{exclusiveLocks='[38e1379b-c3b6-4a2e-91df-d1f346e414a9=VDS]', sharedLocks=''}' 2019-05-07 06:02:04,242-04 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand] (EE-ManagedThreadFactory-commandCoordinator-Thread-2) [70840477] Running command: ActivateVds Command internal: true. Entities affected : ID: 38e1379b-c3b6-4a2e-91df-d1f346e414a9 Type: VDSAction group MANIPULATE_HOST with role type ADMIN 2019-05-07 06:02:04,243-04 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand] (EE-ManagedThreadFactory-commandCoordinator-Thread-2) [70840477] Before acquiring lock in ord er to prevent monitoring for host 'lago-upgrade-from-release-suite-master-host-0' from data-center 'test-dc' 2019-05-07 06:02:04,243-04 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand] (EE-ManagedThreadFactory-commandCoordinator-Thread-2) [70840477] Lock acquired, from now a mo nitoring of host will be skipped for host 'lago-upgrade-from-release-suite-master-host-0' from data-center 'test-dc' 2019-05-07 06:02:04,252-04 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] (EE-ManagedThreadFactory-commandCoordinator-Thread-2) [70840477] START, SetVdsStatu sVDSCommand(HostName = lago-upgrade-from-release-suite-master-host-0, SetVdsStatusVDSCommandParameters:{hostId='38e1379b-c3b6-4a2e-91df-d1f346e414a9', status='Unassigned', n onOperationalReason='NONE', stopSpmFailureLogged='false', maintenanceReason='null'}), log id: 2c8aa211 2019-05-07 06:02:04,256-04 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] (EE-ManagedThreadFactory-commandCoordinator-Thread-2) [70840477] FINISH, SetVdsStat usVDSCommand, return: , log id: 2c8aa211 2019-05-07 06:02:04,261-04 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand] (EE-ManagedThreadFactory-commandCoordinator-Thread-2) [70840477] Activate host finished. Lock released. Monitoring can run now for host 'lago-upgrade-from-release-suite-master-host-0' from data-center 'test-dc' 2019-05-07 06:02:04,265-04 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-commandCoordinator-Thread-2) [70840477] EVEN T_ID: VDS_ACTIVATE(16), Activation of host lago-upgrade-from-release-suite-master-host-0 initiated by admin@internal-authz. 2019-05-07 06:02:04,266-04 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand] (EE-ManagedThreadFactory-commandCoordinator-Thread-2) [70840477] Lock freed to object 'Engine Lock:{exclusiveLocks='[38e1379b-c3b6-4a2e-91df-d1f346e414a9=VDS]', sharedLocks=''}' 2019-05-07 06:02:04,484-04 ERROR [org.ovirt.engine.core.bll.hostdeploy.HostUpgradeCallback] (EE-ManagedThreadFactory-engineScheduled-Thread-96) [05592db2-f859-487b-b779-4b32 eec5bab3] Host 'lago-upgrade-from-release-suite-master-host-0' failed to move to maintenance mode. Upgrade process is terminated. I can see there was only one vm running: drwxrwxr-x. 2 dron dron 1024 May 7 11:49 qemu [dron@dron post-004_basic_sanity.py]$ ls -l lago-upgrade-from-release-suite-master-host-0/_var_log/libvirt/qemu/ total 6 -rw-rw-r--. 1 dron dron 4466 May 7 10:12 vm-with-iface.log and I can see that there was an attempt to terminate it with an error that it does not exist: stroyVmVDSCommandParameters:{hostId='38e1379b-c3b6-4a2e-91df-d1f346e414a9', vmId='dfbd75e2-a9cb-4fca-8788-a16954db4abf', secondsToWait='0', gracefully='false', reason='', ig noreNoVm='false'}), log id: 24278e9b 2019-05-07 06:01:41,082-04 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.DestroyVDSCommand] (default task-1) [105f7555-517b-4bf9-b86e-6eb42375de20] START, DestroyVDSComma nd(HostName = lago-upgrade-from-release-suite-master-host-0, DestroyVmVDSCommandParameters:{hostId='38e1379b-c3b6-4a2e-91df-d1f346e414a9', vmId='dfbd75e2-a9cb-4fca-8788-a169 54db4abf', secondsToWait='0', gracefully='false', reason='', ignoreNoVm='false'}), log id: 78bba2f8 2019-05-07 06:01:42,090-04 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.DestroyVDSCommand] (default task-1) [105f7555-517b-4bf9-b86e-6eb42375de20] FINISH, DestroyVDSComm and, return: , log id: 78bba2f8 2019-05-07 06:01:42,090-04 INFO [org.ovirt.engine.core.vdsbroker.DestroyVmVDSCommand] (default task-1) [105f7555-517b-4bf9-b86e-6eb42375de20] FINISH, DestroyVmVDSCommand, r eturn: , log id: 24278e9b 2019-05-07 06:01:42,094-04 INFO [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] (ForkJoinPool-1-worker-4) [] VM 'dfbd75e2-a9cb-4fca-8788-a16954db4abf' was reported as Down on VDS '38e1379b-c3b6-4a2e-91df-d1f346e414a9'(lago-upgrade-from-release-suite-master-host-0) 2019-05-07 06:01:42,096-04 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.DestroyVDSCommand] (ForkJoinPool-1-worker-4) [] START, DestroyVDSCommand(HostName = lago-upgrade- from-release-suite-master-host-0, DestroyVmVDSCommandParameters:{hostId='38e1379b-c3b6-4a2e-91df-d1f346e414a9', vmId='dfbd75e2-a9cb-4fca-8788-a16954db4abf', secondsToWait='0 ', gracefully='false', reason='', ignoreNoVm='true'}), log id: 1dbd31eb 2019-05-07 06:01:42,114-04 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.DestroyVDSCommand] (ForkJoinPool-1-worker-4) [] Failed to destroy VM 'dfbd75e2-a9cb-4fca-8788-a16 954db4abf' because VM does not exist, ignoring

3 10

manipulating VM configuration via Python SDK disables serial console
by Denis Karpov 10 May '19

10 May '19

Hello, I have hit what seems to be a bug in oVIrt Python SDK, when deploying OpenStack 14 (Rocky) in configuration virtualized controllers, oVirt VMs; Ironic oVirt driver is used in this case, which uses oVirt Python SDK to talk to manipulate VMs. The driver seem to work in such a way that at certain stages it retrieves a VM configuration and updates it (e.g. changes the boot device). However during such update some other changes in configuration of the VM happen: e.g. if the VM had VirtIO serial console enabled, after the update that serial console becomes disabled. Perhaps when a VMs config is updated some XML fields of its configuration are not written back as they should be? We have noticed that since the OpenStack deployment fails on controllers if it cannot output to the serial console. I would appreciate any help/workaround for this issue. Thanks, Denis

2 2

SATA interface?
by Hetz Ben Hamo 09 May '19

09 May '19

Hi, It looks like the Q35 chipset has SATA support for CDROM, but not for virtual hard disk. In many OS's/Appliances - there is no way to use virtio disks, and I can either use the extremly slow IDE with 440FX or nothing else. on Virt-Manager though, you can choose a SATA hard disk. So, is it possible to add the SATA support back for hard drives please?

3 3

manipulating VM configuration via Python SDK disables serial console
by Denis Karpov 08 May '19

08 May '19

Hello, I have hit what seems to be a bug in oVIrt Python SDK, when deploying OpenStack 14 (Rocky) in configuration virtualized controllers, oVirt VMs; Ironic oVirt driver is used in this case, which uses oVirt Python SDK to talk to manipulate VMs. The driver seem to work in such a way that at certain stages it retrieves a VM configuration and updates it (e.g. changes the boot device). However during such update some other changes in configuration of the VM happen: e.g. if the VM had VirtIO serial console enabled, after the update that serial console becomes disabled. Perhaps when a VMs config is updated some XML fields of its configuration are not written back as they should be? We have noticed that since the OpenStack deployment fails on controllers if it cannot output to the serial console. I would appreciate any help/workaround for this issue. Thanks, Denis

1 0

Fedora 29 support?
by Nir Soffer 08 May '19

08 May '19

Fedora 28 will be EOL in few month, and at this point people are migration to Fedora 29. I tried yesterday to build engine development setup on Fedora 29 VM, and found that it does not work: - some packages are missing on engine side - after hacking the ovirt.repo files, pointing to "28" instead of "$releasever", I got the packages... - but then adding a host fail with "Python is missing" on the host, which is working Fedora 28 host used with engine before. What are our plans for supporting Fedora 29 on engine and host? I hope that the work we did for Fedora 28 will make it easier to port to Fedora 29. Nir

3 5

OST broken - looks like https://gerrit.ovirt.org/c/99717 is the reason
by Nir Soffer 07 May '19

07 May '19

Investigating unrelated OST failue with: https://gerrit.ovirt.org/c/99293 I found that This patch fail in OST: https://gerrit.ovirt.org/c/99717 Failed build: https://jenkins.ovirt.org/job/ovirt-system-tests_manual/4630/ 2019-05-02 15:46:07,258::ssh.py::ssh::96::lago.ssh::DEBUG::Command 650bdf66 on lago-basic-suite-master-host-0 errors: + yum -y install ovirt-host Error: Package: vdsm-common-4.40.0-202.git9757d7c.el7.noarch (alocalsync) Requires: python2-enum34 Dan, can you take a look at this? Nir

4 5

Jenkins is very slow now - can someone restart it?
by Nir Soffer 05 May '19

05 May '19

$ time curl -s https://jenkins.ovirt.org/job/ovirt-system-tests_manual/ >/dev/null real 0m27.380s user 0m0.038s sys 0m0.028s For reference: $ time curl -s https://travis-ci.org/oVirt/vdsm/builds >/dev/null real 0m0.614s user 0m0.027s sys 0m0.015s Can someone restart jenkins?

3 4

ovirt-engine has been tagged (ovirt-engine-4.3.3.7)
by Tal Nisan 05 May '19

05 May '19

2 1

Jenkins restart
by Evgheni Dereveanchin 03 May '19

03 May '19

Hi everyone, We received reports that Jenkins is performing slowly so I'm going to restart it now to to apply some updates. During the outage no new builds will be started. I will announce once it is back up and running. -- Regards, Evgheni Dereveanchin

1 1

Thin provisioning??
by Hetz Ben Hamo 02 May '19

02 May '19

Hi, I've migrated few Linux VM's from virt-manager to oVirt. Other than the famous bug that it insist to have an ISO domain - it worked well. My problem is simple: on virt-manager, I created the virtual disks as thin provisioning. ls -l shows the full size of the QCOW2 file and du -hs shows the actual size. So far, so good. After migrating those VM's to oVirt, the disks appear both in the web UI and in the meta file as "Thin Provisioning" and "sparse" - however, digging into the directory which holds the virtual disk and running du -hs - shows it's a full size disk. Why is this happening? (the storage on the oVirt is NFS)

2 5

Taking over safelease maintainership
by Sandro Bonazzola 02 May '19

02 May '19

Not having former maintainers around and no volunteers to take over maintainership for safelease, I'm taking over its maintainership ad interim. -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig> <https://redhat.com/summit>

2 1