- Devel - oVirt List Archives

implementing hotplugCd/hotunplugCd in vdsm
by Fedor Gavrilov 25 Aug '20

25 Aug '20

Hey, So in an attempt to fix change CD functionality we discovered a few other potential issues and what Nir suggested was to implement two [somewhat] new functions in VDSM: hotplug and hotunplug for CDs similar to how it works for normal disks now. Existing changeCD function will be left as is for backwards compatibility. As I found out, engine already calculates iface and index before invoking VDSM functions, so we will just pass these along with PDIV to the VDSM. Suggested flow is, let me quote: >So the complete change CD flow should be: > >1. get the previous drivespec from vm metadata >2. prepare new drivespec >3. add new drivespec to vm metadata >4. attach a new device to vm >5. teardown the previous drivespec >6. remove previous drivespec from vm metadata > >When the vm is stopped, it must do: > >1. get drive spec from vm metadata >2. teardown drivespec > >During attach, there are interesting races: >- what happens if vdsm crashes after step 2? who will teardown the volume? > maybe you need to add the new drivespec to the metadata first, >before preparing it. >- what happens if attach failed? who will remove the new drive from >the metadata? Now, what makes hotplugDisk/hotunplugDisk different? From what I understand, the flow is same there, so what difference is there as far as VDSM is concerned? If none, this means if I more or less copy that code, changing minor details and data accordingly for CDs, this should work, shouldn't it? Thanks! Fedor

4 11

Engine build-artifacts is broken - "ERROR: Error fetching remote repo 'origin'"
by Nir Soffer 23 Aug '20

23 Aug '20

Since Friday, engine build-artifacts job is broken. Here are latest failing builds: https://jenkins.ovirt.org/job/ovirt-engine_standard-check-patch/7425/ https://jenkins.ovirt.org/job/ovirt-engine_standard-check-patch/7426/ https://jenkins.ovirt.org/job/ovirt-engine_standard-check-patch/7427/ Error from last failing build: [2020-08-22T18:16:16.995Z] No credentials specified [2020-08-22T18:16:17.019Z] Fetching changes from the remote Git repository [2020-08-22T18:16:17.035Z] Cleaning workspace [2020-08-22T18:16:17.006Z] > git rev-parse --is-inside-work-tree # timeout=10 [2020-08-22T18:16:17.028Z] > git config remote.origin.url https://gerrit.ovirt.org/ovirt-engine # timeout=10 [2020-08-22T18:16:17.046Z] > git rev-parse --verify HEAD # timeout=10 [2020-08-22T18:16:17.136Z] Resetting working tree [2020-08-22T18:16:17.136Z] > git reset --hard # timeout=10 [2020-08-22T18:16:17.797Z] > git clean -fdx # timeout=10 [2020-08-22T18:16:18.179Z] ERROR: Error fetching remote repo 'origin' [2020-08-22T18:16:18.179Z] hudson.plugins.git.GitException: Failed to fetch from https://gerrit.ovirt.org/ovirt-engine [2020-08-22T18:16:18.179Z] at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:909) [2020-08-22T18:16:18.179Z] at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1131) [2020-08-22T18:16:18.179Z] at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1167) [2020-08-22T18:16:18.179Z] at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:125) [2020-08-22T18:16:18.179Z] at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:93) [2020-08-22T18:16:18.179Z] at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:80) [2020-08-22T18:16:18.179Z] at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47) [2020-08-22T18:16:18.179Z] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [2020-08-22T18:16:18.179Z] at java.util.concurrent.FutureTask.run(FutureTask.java:266) [2020-08-22T18:16:18.180Z] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [2020-08-22T18:16:18.180Z] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [2020-08-22T18:16:18.180Z] at java.lang.Thread.run(Thread.java:748) [2020-08-22T18:16:18.180Z] Caused by: hudson.plugins.git.GitException: Command "git clean -fdx" returned status code 1: [2020-08-22T18:16:18.180Z] stdout: [2020-08-22T18:16:18.180Z] stderr: warning: failed to remove rpmbuild/BUILD/ovirt-engine-4.4.2.3/frontend/webadmin/modules/webadmin/target/tmp/gwtc15338967752245717048.tmp/org.ovirt.engine.ui.webadmin.WebAdmin/compiler/permutation-0.js [2020-08-22T18:16:18.180Z] [2020-08-22T18:16:18.180Z] at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2430) [2020-08-22T18:16:18.180Z] at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2360) [2020-08-22T18:16:18.180Z] at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2356) [2020-08-22T18:16:18.180Z] at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1916) [2020-08-22T18:16:18.180Z] at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1928) [2020-08-22T18:16:18.180Z] at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.clean(CliGitAPIImpl.java:1010) [2020-08-22T18:16:18.180Z] at sun.reflect.GeneratedMethodAccessor1271.invoke(Unknown Source) [2020-08-22T18:16:18.180Z] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [2020-08-22T18:16:18.180Z] at java.lang.reflect.Method.invoke(Method.java:498) [2020-08-22T18:16:18.180Z] at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:931) [2020-08-22T18:16:18.180Z] at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:905) [2020-08-22T18:16:18.180Z] at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:857) [2020-08-22T18:16:18.180Z] at hudson.remoting.UserRequest.perform(UserRequest.java:211) [2020-08-22T18:16:18.180Z] at hudson.remoting.UserRequest.perform(UserRequest.java:54) [2020-08-22T18:16:18.180Z] at hudson.remoting.Request$2.run(Request.java:369) [2020-08-22T18:16:18.180Z] at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) [2020-08-22T18:16:18.180Z] ... 4 more [2020-08-22T18:16:18.182Z] Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to vm0006.workers-phx.ovirt.org [2020-08-22T18:16:18.182Z] at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1788) [2020-08-22T18:16:18.182Z] at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:356) [2020-08-22T18:16:18.182Z] at hudson.remoting.Channel.call(Channel.java:998) [2020-08-22T18:16:18.182Z] at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:285) [2020-08-22T18:16:18.182Z] at com.sun.proxy.$Proxy89.clean(Unknown Source) [2020-08-22T18:16:18.182Z] at org.jenkinsci.plugins.gitclient.RemoteGitImpl.clean(RemoteGitImpl.java:455) [2020-08-22T18:16:18.182Z] at hudson.plugins.git.extensions.impl.CleanBeforeCheckout.decorateFetchCommand(CleanBeforeCheckout.java:44) [2020-08-22T18:16:18.183Z] at hudson.plugins.git.extensions.GitSCMExtension.decorateFetchCommand(GitSCMExtension.java:288) [2020-08-22T18:16:18.183Z] at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:905) [2020-08-22T18:16:18.183Z] at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1131) [2020-08-22T18:16:18.183Z] at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1167) [2020-08-22T18:16:18.183Z] at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:125) [2020-08-22T18:16:18.183Z] at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:93) [2020-08-22T18:16:18.183Z] at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:80) [2020-08-22T18:16:18.183Z] at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47) [2020-08-22T18:16:18.183Z] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [2020-08-22T18:16:18.183Z] ... 4 more Error fetching remote repo 'origin'

1 1

Vdsm: ovirt-4.4.2 branch created
by Milan Zamazal 19 Aug '20

19 Aug '20

Hi, ovirt-4.4.2 branch has been created in Vdsm repository. Any future changes for 4.4.2 must be backported there. You can merge non-4.4.2 stuff to master now. Regards, Milan

1 0

Max running ansible-playbook
by Tommaso - Shellrent 19 Aug '20

19 Aug '20

Hi to all. on our angine we always see max 1 ansible-playbook running on the same time. We use OVA export to make some backup, but the whole task takes a lot of time because only one ansible-playbook "/usr/share/ovirt-engine/playbooks/ovirt-ova-export.yml" run at the same time. How can we ingrease this value? -- -- Shellrent - Il primo hosting italiano Security First *Tommaso De Marchi* /COO - Chief Operating Officer/ Shellrent Srl Via dell'Edilizia, 19 - 36100 Vicenza Tel. 0444321155 <tel:+390444321155> | Fax 04441492177

1 0

ovirt-engine has been tagged (ovirt-engine-4.3.11.4)
by Tal Nisan 18 Aug '20

18 Aug '20

1 0

ovirt-engine has been tagged (ovirt-engine-4.4.2.3)
by Tal Nisan 18 Aug '20

18 Aug '20

1 0

KVM with RDP using RDPMux for oVirt?
by Neal Gompa 17 Aug '20

17 Aug '20

Hello, At the urging of Sandro Bonazzola, I'm bringing up something that was being discussed on Twitter earlier today: supporting RDP with KVM directly. As it turns out, about four years ago, Datto developed support for QEMU to display to RDP in a similar fashion to what was done for SPICE years ago. The way this was done was by patching QEMU[1] to send buffers to a service called RDPMux[2], which would provide RDP connections. Additionally, libvirt was adjusted to support this[3]. Now, a couple years ago, I attempted to start rebasing this to QEMU 2.12.0 for my own use[4], but while I was able to make it compile[5], it always hung when I tried to use the functionality. This came up on Twitter earlier today when talking about how KVM lacks RDP but had SPICE (which didn't catch on, and is apparently deprecated now[6]?!?) Is anyone interested in potentially helping me get this working with the latest QEMU and libvirt? I'd be happy to package up RDPMux for Fedora and get that in the distribution for people to use in that case... Best regards, Neal [1]: https://pagure.io/virt-with-rdp/blob/master/f/qemu-2.5 [2]: https://github.com/datto/RDPMux [3]: https://pagure.io/virt-with-rdp/blob/master/f/libvirt-1.3.1 [4]: https://pagure.io/virt-with-rdp/blob/master/f/qemu-2.12.0 [5]: https://copr.fedorainfracloud.org/coprs/ngompa/virt-with-rdp/build/774882/ [6]: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8-be… -- 真実はいつも一つ！/ Always, there's only one truth!

4 7

Improving VM behavior in case of IO errors
by Shubha Kulkarni 16 Aug '20

16 Aug '20

Hello, In OVirt, we have a property propagate_error at the disk level that decides in case of an error, how this error be propagated to the VM. This value is maintained in the database table with the default value set as Off. The default setting(Off) results in a policy that ends up pausing the VM rather than propagating the errors to VM. There is no provision in the UI currently to configure this property for disk (images or luns). So there is no easy way to set this value. Further, even if the value is manually set to "On" in db, it gets overwriiten by UI everytime some other property is updated as described here - https://bugzilla.redhat.com/show_bug.cgi?id=1669367 Setting the value to "Off" is not ideal for multipath devices where a single path failure causes vm to pause. It puts serious restrictions for the DR situation and unlike VMWare * Hyper-V, oVirt is not able to support the DR functionality - https://bugzilla.redhat.com/show_bug.cgi?id=1314160 While we wait for RFE, the proposal here is to revise the out of the box behavior for LUNs. For LUNs, we should propagate the errors to VM rather than directly stopping those. This will allow us to handle short-term multipath outages and improve availability. This is a simple change in behavior but will have good positive impact. I would like to seek feedback about this to make sure that everyone is ok with the proposal. Thanks, Shubha

3 11

ovirt-engine 4.4.2 has been branched
by Tal Nisan 13 Aug '20

13 Aug '20

I've now branched oVirt 4.4.2, this will allow us to start working on 4.4.3 bugs/features and also maintain the stability of 4.4.2 before the final build. How does it affect you: If you are working on 4.4.3 content you can now submit your work to master and it will be included in 4.4.3 If you are working on 4.4.2 content you will have to push it to master first and then backport it to the ovirt-engine-4.4.2.z branch

1 0

ovirt-engine has been tagged (ovirt-engine-4.4.2.2)
by Tal Nisan 13 Aug '20

13 Aug '20

3 4