- Devel - oVirt List Archives

ovirt-engine has been tagged (ovirt-engine-4.3.0_alpha)
by Tal Nisan 20 Nov '18

20 Nov '18

1 0

vdsm has been tagged (v4.30.3)
by Milan Zamazal 20 Nov '18

20 Nov '18

1 0

[QA][Automation] Maintainer needed for basic-suite-master compatibility test suite
by Sandro Bonazzola 19 Nov '18

19 Nov '18

Hi, Milan Zamal who previously was monitoring the automated test and helping fixing issues related to it has no more capacity for continue with this task[1]. We are now looking for someone to help monitoring the test results and help handling its failures when running it with different cluster levels. [1] https://gerrit.ovirt.org/#/c/95515/ -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

1 0

CentOS Virt SIG - (at least) one volunteer needed
by Sandro Bonazzola 19 Nov '18

19 Nov '18

Hi, with Christmas holidays coming the CentOS Virt SIG will have both me and Tomasz Baranski not available in case of urgent issues. I'd like to ask for a volunteer from a region where there's no Christmas holiday (Israel comes to my mind) for covering during our absence and future similar absences. Documentation for joining the SIG is here: https://wiki.centos.org/SIGGuide You can contact me directly if you want to candidate yourself. Being a Fedora packager is a nice to have, it will ease working with the SIG build system and with the packaging tasks. Thanks, -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

2 2

Getting info about qemu guest agent into the engine
by Tomasz Barański 19 Nov '18

19 Nov '18

Hello, wise people! As a part of BZ1615830[1] I want to add information about qemu guest agent to engine's DB. I have some trouble figuring out some details. 1. VDSM seems to be using QGA, but it does not report any information about it. Am I right? I only found a mention about it in `xml` field in JSON returned by `VM.getInfo` (and `Host.getVMFullList`): a `virtio` channel as documented in libvirt. 2. How does the engine puts data into `vm_dynamic` table? I can't find any usage for `InsertVmDynamic` procedure. 3. Also, it's not clear to me how (whether?) the engine consumes output of VM.getInfo/Host.getVMFullList. Any pointers to relevant code appreciated. Tomo [1] https://bugzilla.redhat.com/show_bug.cgi?id=1615830

4 5

Re: [ovirt-users] Re: Engine ISO Uploader - SSL Peer Not Trusted
by Sandro Bonazzola 19 Nov '18

19 Nov '18

Moving to devel mailing list. Il giorno dom 18 nov 2018 alle ore 11:17 Yedidyah Bar David <didi(a)redhat.com> ha scritto: > On Sat, Nov 17, 2018 at 6:32 PM, Shawn Weeks <sweeks(a)weeksconsulting.us> > wrote: > > The only issue with the UI is I’m on VPN so uploading from my local > machine > > would be extremely slow. I discovered the –insecure flag for the cli and > > that seems to have worked. > > Please note that we intend to deprecate this tool. Please try the api/sdk > as suggested by Nir and tell us if you have any comments/issues etc. > Thanks. > > Actually I thought we already deprecated it in 4.2, but I now searched and > can't find anything like [1][2] (which was for the image uploader) or a > note > in the release notes [3]. Adding Sandro. Is it too late now to deprecate > in 4.2 (so that we can remove in 4.3)? > Tal, are we removing ISO domains in 4.3? If yes we need to deprecate the iso uploader in 4.2 so we can remove it in 4.3, if not we need to keep it in 4.3 since the web ui doesn't upload to iso domain (AFAIK). > > See also [4][5], which are for RHV. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1306637 > [2] https://www.ovirt.org/release/4.0.0/#ovirt-image-uploader > [3] https://ovirt.org/release/4.2.0/ > [4] https://bugzilla.redhat.com/show_bug.cgi?id=1579119 > [5] > https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2/ht… > > Thanks and best regards, > > > > > > > > > Thanks > > > > Shawnk > > > > > > > > From: Nir Soffer <nsoffer(a)redhat.com> > > Sent: Saturday, November 17, 2018 8:43 AM > > To: Shawn Weeks <sweeks(a)weeksconsulting.us> > > Cc: users <users(a)ovirt.org>; Daniel Erez <derez(a)redhat.com> > > Subject: Re: [ovirt-users] Engine ISO Uploader - SSL Peer Not Trusted > > > > > > > > On Sat, Nov 17, 2018, 02:45 Shawn Weeks <sweeks(a)weeksconsulting.us > wrote: > > > > Trying to upload an iso using engine-iso-uploader on a hosted-engine > > instance and I’m getting an SSL Error. I followed the directions at > > https://www.ovirt.org/documentation/admin-guide/appe-oVirt_and_SSL/ to > setup > > SSL and am able to login to the Admin console without an issue. Also > checked > > that things like curl recognize the CA correctly. Not sure where > > engine-iso-uploader is getting it’s trust store. > > > > > > > > [root@cloud ~]# engine-iso-uploader list > > > > Please provide the REST API password for the admin@internal oVirt Engine > > user (CTRL+D to abort): > > > > ERROR: Unable to connect to REST API at > > https://cloud.dev.example.com:443/ovirt-engine/api due to SDK error > > > > Message: Error while sending HTTP request: (60, "Peer's certificate > issuer > > has been marked as not trusted by the user.") > > > > > > > > What am I missing? > > > > > > > > If you ate using 4.2, you can upload iso files to data domains. You can > > upload directly from the UI: > > > > > > > > 1. Open storage > disks > > > > 2. Click Upload > Start > > > > 3. Select file and fill in the form > > > > > > > > For faster upload or automation, you can use the SDK. See this example > code: > > > > > > > > > https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/upload_d… > > > > > > > > With some configuration changes you can use this as command line tool for > > uploading iso or other images. > > > > > > > > Nir > > > > > > > > > > _______________________________________________ > > 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/MHEE6MQR2PFKP… > > > > > > -- > Didi > -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

1 0

[ OST Failure Report ] [ oVirt 4.2 (ovirt-engine) ] [ 15-11-2018 ] [ check_snapshot_with_memory ]
by Dafna Ron 18 Nov '18

18 Nov '18

Hi, we have a failure on basic suite for test check_snapshot_with. _memory. I am actually not seeing any reason the patch would cause that specific issue but its consistently failing on this change. I am seeing a vm memory saved to the iscsi domain but aside from that nothing is failing before tto cause a cleanup issue or create low space on the storage). can some one please take a look to see if anything in the patch is causing this? Link and headline of suspected patches: https://gerrit.ovirt.org/#/c/95436/1 - webadmin: network operation in progress - sync host interfaces Link to Job: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/3487/ Link to all logs: https://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/3487/artifact/b… (Relevant) error snippet from the log: <error> 2018-11-15 08:19:33,409-05 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (default task-5) [dce28fd0-bebc-4aba-80d5-ffc081b1f591] method: runVdsCommand, params: [IsVmDuringInitiating , IsVmDuringInitiatingVDSCommandParameters:{vmId='9144eb88-8f0a-4e77-9d70-3b761e48ecb4'}], timeElapsed: 1ms 2018-11-15 08:19:33,430-05 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-5) [dce28fd0-bebc-4aba-80d5-ffc081b1f591] EVENT_ID: USER_FAILED_RUN_VM(54), Failed to run VM vm0 due to a failed validation: [Cannot run VM. Low disk space on Storage Domain iscsi.] (User: admin@internal-authz). 2018-11-15 08:19:33,430-05 WARN [org.ovirt.engine.core.bll.RunVmCommand] (default task-5) [dce28fd0-bebc-4aba-80d5-ffc081b1f591] Validation of action 'RunVm' failed for user admin@internal-authz. Reasons: VAR__ ACTION__RUN,VAR__TYPE__VM,ACTION_TYPE_FAILED_DISK_SPACE_LOW_ON_STORAGE_DOMAIN,$storageName iscsi 2018-11-15 08:19:33,431-05 INFO [org.ovirt.engine.core.bll.RunVmCommand] (default task-5) [dce28fd0-bebc-4aba-80d5-ffc081b1f591] Lock freed to object 'EngineLock:{exclusiveLocks='[9144eb88-8f0a-4e77-9d70-3b761e 48ecb4=VM]', sharedLocks=''}' 2018-11-15 08:19:33,438-05 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (default task-5) [dce28fd0-bebc-4aba-80d5-ffc081b1f591] method: runAction, params: [RunVm, RunVmParams:{comm andId='69628467-56d3-4d93-aed1-a2807b7dbc45', user='null', commandType='Unknown', vmId='9144eb88-8f0a-4e77-9d70-3b761e48ecb4'}], timeElapsed: 115ms 2018-11-15 08:19:33,441-05 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-5) [] Operation Failed: [Cannot run VM. Low disk space on Storage Domain iscsi.] 2018-11-15 08:19:34,044-05 DEBUG [org.ovirt.engine.core.vdsbroker.vdsbroker.GetAllVmStatsVDSCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-25) [] START, GetAllVmStatsVDSCommand(HostName = lago-basic-su ite-4-2-host-0, VdsIdVDSCommandParametersBase:{hostId='063dfef9-bc9d-44c3-8ba3-8142e3eb129c'}), log id: 65651e2b 2018-11-15 08:19:34,045-05 DEBUG [org.ovirt.vdsm.jsonrpc.client.reactors.stomp.impl.Message] (EE-ManagedThreadFactory-engineScheduled-Thread-25) [] SEND destination:jms.topic.vdsm_requests reply-to:jms.topic.vdsm_responses content-length:103 </error>

4 5

Proposing Fred Rolland as a Storage backend maintainer
by Tal Nisan 18 Nov '18

18 Nov '18

Hi everyone, I'd like to propose Fred as a backend maintainer in Engine for the storage area. Fred has been contributing to ovirt-engine for the last 3.5 years and have done tremendous job in adding new features, bug fixes and code review. Thanks, Tal.

6 5

[vdsm] illegible check-patch failure
by Dan Kenigsberg 18 Nov '18

18 Nov '18

This job https://jenkins.ovirt.org/job/vdsm_master_check-patch-fc28-x86_64/1965/cons… fails on 06:46:24 journal/b087148aba6d49b9bbef488e52a48752/system.journal 06:46:27 tar: journal/b087148aba6d49b9bbef488e52a48752/system.journal: file changed as we read it (I think). Is that true? How can this be avoided?

2 1

[BACKUP] Estimating qcow2 disk image size before upload
by Nir Soffer 17 Nov '18

17 Nov '18

When uploading to qcow2 disks on block storage you must set the disk initial_size correctly so the system allocates big enough disk. If the initial size is too small, the upload will fail when trying to write after the end of the device. This info can be useful for people working on a backup solution for oVirt. The easiest case is upload of existing qcow2 image using the SDK. In this case we create a new disk with: initial_size=image_size, provisioned_size=virtual_size, image_size is the size of the file: os.stat('image').st_size Note that "qemu-img info" return "actual-size" - this is the allocated size on storage which is not helpful for uploading images. Example: https://github.com/oVirt/ovirt-engine-sdk/blob/78c3d5bd14eeb93ef72ec31d775f… A more tricky case is when a backup system keeps raw guest data, but know how to generate qcow2 image stream, without creating a temporary image. In this case the required size can be calculated by counting the number of clusters that need to be allocated in the final image. This depends on the location of the data in the image. For example this creates 1G image with only one cluster: $ python -c 'with open("one-cluster.raw", "wb") as f: f.truncate(1024**3) f.write("x")' $ ls -lhs one-cluster.raw 4.0K -rw-rw-r--. 1 nsoffer nsoffer 1.0G Nov 15 18:24 one-cluster.raw $ qemu-img measure -f raw -O qcow2 one-cluster.raw required size: 458752 fully allocated size: 1074135040 $ qemu-img convert -f raw -O qcow2 one-cluster.raw one-cluster.qcow2 $ ls -lhs one-cluster.qcow2 324K -rw-r--r--. 1 nsoffer nsoffer 384K Nov 15 18:25 one-cluster.qcow2 But this creates a fully allocated 1G image: $ python -c 'with open("fully-allocated.raw", "wb") as f: f.truncate(1024**3) for i in range(0, 1024**3, 64 * 1024): f.seek(i) f.write("x")' $ ls -lhs fully-allocated.raw 64M -rw-rw-r--. 1 nsoffer nsoffer 1.0G Nov 15 18:30 fully-allocated.raw $ qemu-img measure -f raw -O qcow2 fully-allocated.raw required size: 1074135040 fully allocated size: 1074135040 $ qemu-img convert -f raw -O qcow2 fully-allocated.raw fully-allocated.qcow2 $ ls -lhs fully-allocated.qcow2 1.1G -rw-r--r--. 1 nsoffer nsoffer 1.1G Nov 15 18:31 fully-allocated.qcow2 We had code in vdsm that does exactly this, and it was removed since qemu-img support a new "measure" command in RHEL 7.5 providing this info. But this works only for existing images. You can find the code in this vdsm commit: https://github.com/oVirt/vdsm/tree/4eee97d6aa532b6f3ecdfde0333d17c27c412f86 The module implementing estimation: https://github.com/oVirt/vdsm/blob/4eee97d6aa532b6f3ecdfde0333d17c27c412f86… The tests for this module: https://github.com/oVirt/vdsm/blob/4eee97d6aa532b6f3ecdfde0333d17c27c412f86… If you know the data ranges that will be written to the qcow2 image, you can count the clusters like this: https://github.com/oVirt/vdsm/blob/4eee97d6aa532b6f3ecdfde0333d17c27c412f86… Then you can use the cluster count to estimate qcow2 file size: https://github.com/oVirt/vdsm/blob/4eee97d6aa532b6f3ecdfde0333d17c27c412f86… Nir

2 3