May 2019 - Devel - oVirt List Archives

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