Re: [ovirt-devel] ovirt guest agent and local address

[Vinzenz Feenstra]

> On Mar 29, 2017, at 2:47 PM, Vinzenz Feenstra  wrote:
> 
> 
>> On Mar 29, 2017, at 2:41 PM, Marc Young <3vilpeng...@gmail.com 
>> <mailto:3vilpeng...@gmail.com>> wrote:
>> 
>> Is there a way to manually blacklist a range from being submitted via the 
>> ovirt guest agent?
>> 
>> The reason I ask, 169.x and 127.0.0.1 never display, but if you're running 
>> docker, the agent submits the docker host address (172.17.0.1)
>> 
>> RFC1918 defines local address and contains 172.16.0.0/12 
>> <http://172.16.0.0/12>, which includes 172.17.0.0/16 <http://172.17.0.0/16> 
>> (it ranges from 172.16.0.0 to 172.31.255.255), so it seems valid, but the UI 
>> displays "IP Address" (not plural) 
>> 
>> Is there anything I can do to prevent this IP from submitting?
> 
> No there’s no way at this point. 

Except you’d be patching the guest agent

> 
>> 
>> Screen shot attached.
>> 
>> 
>> Guest agent info:
>> Operating System:
>> CentOS Linux 7.3.1611 (Core)
>> 
>> Kernel Version:
>> 3.10.0-514.el7.x86_64
>> 
>> ___
>> Devel mailing list
>> Devel@ovirt.org <mailto:Devel@ovirt.org>
>> http://lists.ovirt.org/mailman/listinfo/devel
> 

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] ovirt guest agent and local address

[Vinzenz Feenstra]

> On Mar 29, 2017, at 2:41 PM, Marc Young <3vilpeng...@gmail.com> wrote:
> 
> Is there a way to manually blacklist a range from being submitted via the 
> ovirt guest agent?
> 
> The reason I ask, 169.x and 127.0.0.1 never display, but if you're running 
> docker, the agent submits the docker host address (172.17.0.1)
> 
> RFC1918 defines local address and contains 172.16.0.0/12 
> , which includes 172.17.0.0/16  
> (it ranges from 172.16.0.0 to 172.31.255.255), so it seems valid, but the UI 
> displays "IP Address" (not plural) 
> 
> Is there anything I can do to prevent this IP from submitting?

No there’s no way at this point. 

> 
> Screen shot attached.
> 
> 
> Guest agent info:
> Operating System:
> CentOS Linux 7.3.1611 (Core)
> 
> Kernel Version:
> 3.10.0-514.el7.x86_64
> 
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt Cloud-init

[Vinzenz Feenstra]

> On Feb 15, 2017, at 11:51 PM, Marc Young <3vilpeng...@gmail.com> wrote:
> 
> Are there limitations to cloud-init and oVirt? I wouldn't think so,
> but i"m having a weird issue.


What’s the guest OS?

> 
> If i use the cloud-init yaml from the ovirt4 ruby sdk examples (ignore
> formatting, gmail is messing with it):
> 
> write_files:
> - content: |
> Hello, world!
> path: /tmp/greeting.txt
> permissions: '0644'
> 
> it works, that file exists, and it shows in the /var/lib/cloud where i'd 
> expect
> 
> $ sudo cat /var/lib/cloud/instance/user-data.txt
> #cloud-config
> output:
>  all: '>> /var/log/cloud-init-output.log'
> disable_root: 0
> runcmd:
> - 'sed -i ''/^datasource_list: /d'' /etc/cloud/cloud.cfg; echo
> ''datasource_list:
>  ["NoCloud", "ConfigDrive"]'' >> /etc/cloud/cloud.cfg'
> ssh_pwauth: true
> chpasswd:
>  expire: false
> user: root
> write_files:
>  - content: |
>  Hello, world!
>path: /tmp/greeting.txt
>permissions: '0644'
> 
> 
> If i use this:
> 
> manage-resolv-conf: true
> resolv_conf:
>  nameservers: ['192.168.2.113']
>  searchdomains:
>- blindrage.local
>- bar.example.com
> 
> resolv_conf does not get modified. It looks as expected in /var/lib/cloud:
> 
> $ sudo cat /var/lib/cloud/instance/user-data.txt
> #cloud-config
> output:
>  all: '>> /var/log/cloud-init-output.log'
> disable_root: 0
> runcmd:
> - 'sed -i ''/^datasource_list: /d'' /etc/cloud/cloud.cfg; echo
> ''datasource_list:
>  ["NoCloud", "ConfigDrive"]'' >> /etc/cloud/cloud.cfg'
> ssh_pwauth: true
> chpasswd:
>  expire: false
> user: root
> manage-resolv-conf: true
> resolv_conf:
>  nameservers: ['192.168.2.113']
>  searchdomains:
>- foo.local
>- bar.example.com
> 
> I also don't see anything in /var/log/cloud-init.log or
> /var/log/cloud-init-output.log on  either run even though the
> write_files yaml worked.
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] ovirt-guest-agent-common question

[Vinzenz Feenstra]

> On Jan 17, 2017, at 7:27 PM, Yaniv Kaul  wrote:
> 
> 
> 
> On Tue, Jan 17, 2017 at 11:05 AM, Vinzenz Feenstra  <mailto:vfeen...@redhat.com>> wrote:
> 
>> On Jan 17, 2017, at 9:43 AM, Roy Golan > <mailto:rgo...@redhat.com>> wrote:
>> 
>> 
>> 
>> On 16 January 2017 at 12:35, Vinzenz Feenstra > <mailto:vfeen...@redhat.com>> wrote:
>> 
>>> On Jan 16, 2017, at 11:22 AM, Roy Golan >> <mailto:rgo...@redhat.com>> wrote:
>>> 
>>> 
>>> 
>>> On 16 January 2017 at 11:39, Guy Chen >> <mailto:guc...@redhat.com>> wrote:
>>> O.k, Thanks !
>>> 
>>> Regards,
>>> 
>>> ---------
>>> Guy Chen, RHEV-M
>>> Performance
>>> O: +972.9.7692152 M: +972.52.8545202 
>>> 
>>> guc...@redhat.com <mailto:guc...@redhat.com>
>>> 
>>> - Original Message -
>>> > From: "Vinzenz Feenstra" >> > <mailto:vfeen...@redhat.com>>
>>> > To: "Guy Chen" mailto:guc...@redhat.com>>
>>> > Cc: devel@ovirt.org <mailto:devel@ovirt.org>, "Eyal Berman" 
>>> > mailto:eber...@redhat.com>>, "Unname" 
>>> > mailto:rgo...@redhat.com>>
>>> > Sent: Monday, January 16, 2017 11:23:19 AM
>>> > Subject: Re: ovirt-guest-agent-common question
>>> >
>>> >
>>> > > On Jan 16, 2017, at 10:18 AM, Guy Chen >> > > <mailto:guc...@redhat.com>> wrote:
>>> > >
>>> > >
>>> > > Hi
>>> > >
>>> > > After i am installing ovirt-guest-agent-common shutdown of a VM takes 
>>> > > about
>>> > > 90 seconds instead of 30 seconds without the agent.
>>> > > I am running on rhvm 4.1 build 4, host, engine and VM all are rhel 7.3,
>>> > > agent version is ovirt-guest-agent-common-1.0.13-2.el7ev.noarch.
>>> > > Has anyone encounter this issue ?
>>> >
>>> > This is pretty normal as there’s a timeout letting the users logged in 
>>> > save
>>> > their work etc. So the reboot is scheduled.
>>> > This is not an issue, this is simply by design.
>>> >
>>> 
>>> @Vinzenz If there is no logged in user this should be as quick as without 
>>> the tool and I guess there isn't a user logged in @Guy?
>> 
>> Well, the definition of ‘Someone is logged in’ is quite difficult to answer 
>> on linux machine.
>> 
>> Correct but if the system is doing nothing why would adding guest agent is 
>> adding > 1 min to the shutdown?  
> 
> The agent adds that, what it gets told to, it’s not hardcoded if that is your 
> point. “If the system is doing nothing” is again very subjective and not easy 
> to answer.
> Anyway you’re welcome to change that delay if you insist. It’s sent by the 
> engine via the VM.shutdown verb on vdsm as the delay parameter in seconds.
> 
> Just I don’t support this change and I do see too many potential pitfalls in 
> trying to determine if we should skip the delay or not - As I said, it’s a 
> matter which is too subjective.
> 
> I agree it's subjective, but the resulting user experience isn't pleasant 
> either  - it is perceived as if oVirt is making the VM slow, for no good 
> reason. I do think we could do a better job. For example, not to slow down 
> server OS VMs (we do not expect users logged in, and to save their work, 
> etc.), or only do it in Windows and when X is running, etc.

Sure, that’s not a big deal the engine easily can set the value to 0 if the 
type is a server. If we really have users getting annoyed by this. I have never 
heard of it however. So this seems not to be a very big problem for most users, 
rather a developer or tester issue because they need to work on that faster.

> Y.
> 
> 
>> 
>>>  
>>> > >
>>> > > Regards,
>>> > >
>>> > > -
>>> > > Guy Chen, RHEV-M
>>> > > Performance
>>> > > O: +972.9.7692152 M: +972.52.8545202 
>>> > > 
>>> > > guc...@redhat.com <mailto:guc...@redhat.com>
>>> > >
>>> >
>>> >
> 
> 
> ___
> Devel mailing list
> Devel@ovirt.org <mailto:Devel@ovirt.org>
> http://lists.ovirt.org/mailman/listinfo/devel 
> <http://lists.ovirt.org/mailman/listinfo/devel>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] ovirt-guest-agent-common question

[Vinzenz Feenstra]

> On Jan 17, 2017, at 9:43 AM, Roy Golan  wrote:
> 
> 
> 
> On 16 January 2017 at 12:35, Vinzenz Feenstra  <mailto:vfeen...@redhat.com>> wrote:
> 
>> On Jan 16, 2017, at 11:22 AM, Roy Golan > <mailto:rgo...@redhat.com>> wrote:
>> 
>> 
>> 
>> On 16 January 2017 at 11:39, Guy Chen > <mailto:guc...@redhat.com>> wrote:
>> O.k, Thanks !
>> 
>> Regards,
>> 
>> -
>> Guy Chen, RHEV-M
>> Performance
>> O: +972.9.7692152     M: +972.52.8545202 
>> 
>> guc...@redhat.com <mailto:guc...@redhat.com>
>> 
>> - Original Message -
>> > From: "Vinzenz Feenstra" mailto:vfeen...@redhat.com>>
>> > To: "Guy Chen" mailto:guc...@redhat.com>>
>> > Cc: devel@ovirt.org <mailto:devel@ovirt.org>, "Eyal Berman" 
>> > mailto:eber...@redhat.com>>, "Unname" 
>> > mailto:rgo...@redhat.com>>
>> > Sent: Monday, January 16, 2017 11:23:19 AM
>> > Subject: Re: ovirt-guest-agent-common question
>> >
>> >
>> > > On Jan 16, 2017, at 10:18 AM, Guy Chen > > > <mailto:guc...@redhat.com>> wrote:
>> > >
>> > >
>> > > Hi
>> > >
>> > > After i am installing ovirt-guest-agent-common shutdown of a VM takes 
>> > > about
>> > > 90 seconds instead of 30 seconds without the agent.
>> > > I am running on rhvm 4.1 build 4, host, engine and VM all are rhel 7.3,
>> > > agent version is ovirt-guest-agent-common-1.0.13-2.el7ev.noarch.
>> > > Has anyone encounter this issue ?
>> >
>> > This is pretty normal as there’s a timeout letting the users logged in save
>> > their work etc. So the reboot is scheduled.
>> > This is not an issue, this is simply by design.
>> >
>> 
>> @Vinzenz If there is no logged in user this should be as quick as without 
>> the tool and I guess there isn't a user logged in @Guy?
> 
> Well, the definition of ‘Someone is logged in’ is quite difficult to answer 
> on linux machine.
> 
> Correct but if the system is doing nothing why would adding guest agent is 
> adding > 1 min to the shutdown?  

The agent adds that, what it gets told to, it’s not hardcoded if that is your 
point. “If the system is doing nothing” is again very subjective and not easy 
to answer.
Anyway you’re welcome to change that delay if you insist. It’s sent by the 
engine via the VM.shutdown verb on vdsm as the delay parameter in seconds.

Just I don’t support this change and I do see too many potential pitfalls in 
trying to determine if we should skip the delay or not - As I said, it’s a 
matter which is too subjective.

> 
>>  
>> > >
>> > > Regards,
>> > >
>> > > -
>> > > Guy Chen, RHEV-M
>> > > Performance
>> > > O: +972.9.7692152 M: +972.52.8545202 
>> > > 
>> > > guc...@redhat.com <mailto:guc...@redhat.com>
>> > >
>> >
>> >

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] ovirt-guest-agent-common question

[Vinzenz Feenstra]

> On Jan 16, 2017, at 11:22 AM, Roy Golan  wrote:
> 
> 
> 
> On 16 January 2017 at 11:39, Guy Chen  <mailto:guc...@redhat.com>> wrote:
> O.k, Thanks !
> 
> Regards,
> 
> -
> Guy Chen, RHEV-M
> Performance
> O: +972.9.7692152 M: +972.52.8545202 
> 
> guc...@redhat.com <mailto:guc...@redhat.com>
> 
> - Original Message -
> > From: "Vinzenz Feenstra" mailto:vfeen...@redhat.com>>
> > To: "Guy Chen" mailto:guc...@redhat.com>>
> > Cc: devel@ovirt.org <mailto:devel@ovirt.org>, "Eyal Berman" 
> > mailto:eber...@redhat.com>>, "Unname" 
> > mailto:rgo...@redhat.com>>
> > Sent: Monday, January 16, 2017 11:23:19 AM
> > Subject: Re: ovirt-guest-agent-common question
> >
> >
> > > On Jan 16, 2017, at 10:18 AM, Guy Chen  > > <mailto:guc...@redhat.com>> wrote:
> > >
> > >
> > > Hi
> > >
> > > After i am installing ovirt-guest-agent-common shutdown of a VM takes 
> > > about
> > > 90 seconds instead of 30 seconds without the agent.
> > > I am running on rhvm 4.1 build 4, host, engine and VM all are rhel 7.3,
> > > agent version is ovirt-guest-agent-common-1.0.13-2.el7ev.noarch.
> > > Has anyone encounter this issue ?
> >
> > This is pretty normal as there’s a timeout letting the users logged in save
> > their work etc. So the reboot is scheduled.
> > This is not an issue, this is simply by design.
> >
> 
> @Vinzenz If there is no logged in user this should be as quick as without the 
> tool and I guess there isn't a user logged in @Guy?

Well, the definition of ‘Someone is logged in’ is quite difficult to answer on 
linux machine.

>  
> > >
> > > Regards,
> > >
> > > -
> > > Guy Chen, RHEV-M
> > > Performance
> > > O: +972.9.7692152M: +972.52.8545202
> > > guc...@redhat.com <mailto:guc...@redhat.com>
> > >
> >
> >

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] ovirt-guest-agent-common question

[Vinzenz Feenstra]

> On Jan 16, 2017, at 10:18 AM, Guy Chen  wrote:
> 
> 
> Hi
> 
> After i am installing ovirt-guest-agent-common shutdown of a VM takes about 
> 90 seconds instead of 30 seconds without the agent.
> I am running on rhvm 4.1 build 4, host, engine and VM all are rhel 7.3, agent 
> version is ovirt-guest-agent-common-1.0.13-2.el7ev.noarch.
> Has anyone encounter this issue ?

This is pretty normal as there’s a timeout letting the users logged in save 
their work etc. So the reboot is scheduled.
This is not an issue, this is simply by design.

> 
> Regards,
> 
> -
> Guy Chen, RHEV-M
> Performance
> O: +972.9.7692152M: +972.52.8545202
> guc...@redhat.com
> 

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] BZ#1375139 VM lost its disk after snapshot preview/commit

[Vinzenz Feenstra]

> On Jan 9, 2017, at 12:23 PM, Pavel Gashev  wrote:
> 
> Hello,
>  
> https://bugzilla.redhat.com/show_bug.cgi?id=1375139 
> 
>  
> Could somebody confirm, that the issue is not going to be fixed in 4.0?

It has not been merged to 4.0 branch, so I don’t assume so, the backport for 
4.0 has been abandoned 

>  
> Thanks
>  
> ___
> Devel mailing list
> Devel@ovirt.org 
> http://lists.ovirt.org/mailman/listinfo/devel 
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] System tests for 4.1 currently failing to run VMs!

[Vinzenz Feenstra]

> On Dec 21, 2016, at 11:17 AM, Barak Korren  wrote:
> 
> The test for running VMs had been failing since yesterday.
> 
> The patch merged before the failures started was:
> https://gerrit.ovirt.org/#/c/68826/ 



> 
> The error we`re seeing is a time-out (after two minutes) while running
> this API call:
> 
> api.vms.get(VM0_NAME).status.state == ‘up'

This is a REST API call, the patch above is Frontend. So this is unrelated.

However on Host 0 I can see this:

2016-12-20 16:54:43,544 ERROR (vm/d299ab29) [virt.vm] 
(vmId='d299ab29-284a-435c-a50f-183a6e54def2') The vm start process failed 
(vm:615)
Traceback (most recent call last):
  File "/usr/share/vdsm/virt/vm.py", line 551, in _startUnderlyingVm
self._run()
  File "/usr/share/vdsm/virt/vm.py", line 1991, in _run
self._connection.createXML(domxml, flags),
  File "/usr/lib/python2.7/site-packages/vdsm/libvirtconnection.py", line 123, 
in wrapper
ret = f(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 941, in wrapper
return func(inst, *args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3782, in createXML
if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self)
libvirtError: internal error: process exited while connecting to monitor: 
2016-12-20T21:54:43.044971Z qemu-kvm: warning: CPU(s) not present in any NUMA 
nodes: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
2016-12-20T21:54:43.045164Z qemu-kvm: warning: All CPU(s) up to maxcpus should 
be described in NUMA config
2016-12-20T21:54:43.101886Z qemu-kvm: -device 
usb-ccid,id=ccid0,bus=usb.0,port=1: Warning: speed mismatch trying to attach 
usb device "QEMU USB CCID" (full speed) to bus "usb.0", port "1" (high speed)
2016-12-20 16:54:43,550 INFO  (vm/d299ab29) [virt.vm] 
(vmId='d299ab29-284a-435c-a50f-183a6e54def2') Changed state to Down: internal 
error: process exited while connecting to monitor: 2016-12-20T21:54:43.044971Z 
qemu-kvm: warning: CPU(s) not present in any NUMA nodes: 1 2 3 4 5 6 7 8 9 10 
11 12 13 14 15
2016-12-20T21:54:43.045164Z qemu-kvm: warning: All CPU(s) up to maxcpus should 
be described in NUMA config
2016-12-20T21:54:43.101886Z qemu-kvm: -device 
usb-ccid,id=ccid0,bus=usb.0,port=1: Warning: speed mismatch trying to attach 
usb device "QEMU USB CCID" (full speed) to bus "usb.0", port "1" (high speed) 
(code=1) (vm:1197)
2016-12-20 16:54:43,550 INFO  (vm/d299ab29) [virt.vm] 
(vmId='d299ab29-284a-435c-a50f-183a6e54def2') Stopping connection 
(guestagent:430)


And on The engine loads of these:

2016-12-20 16:53:57,844-05 ERROR 
[org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (default task-17) 
[5ecd5a55-2b7a-4dd6-b42b-cc49bbfb3962] Command 'PollVDSCommand(HostName = 
lago-basic-suite-4-1-host0, VdsIdVDSCommandParametersBase:{runAsync='true', 
hostId='994b5d79-605f-4415-94f2-02c79cfa246e'})' execution failed: 
VDSGenericException: VDSNetworkException: Timeout during rpc call
2016-12-20 16:53:57,849-05 DEBUG 
[org.ovirt.vdsm.jsonrpc.client.reactors.stomp.impl.Message] (SSL Stomp Reactor) 
[7971dfb4] MESSAGE
content-length:80
destination:jms.topic.vdsm_responses
content-type:application/json
subscription:5b6494d5-d5a0-4771-941c-a8be70f72450

{"jsonrpc": "2.0", "id": "3c95fdb0-5b77-4927-9f6e-adc7395c122d", "result": 
true}�
2016-12-20 16:53:57,850-05 DEBUG 
[org.ovirt.vdsm.jsonrpc.client.internal.ResponseWorker] (ResponseWorker) [] 
Message received: {"jsonrpc": "2.0", "id": 
"3c95fdb0-5b77-4927-9f6e-adc7395c122d", "result": true}
2016-12-20 16:53:57,850-05 ERROR [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] 
(ResponseWorker) [] Not able to update response for 
"3c95fdb0-5b77-4927-9f6e-adc7395c122d"
2016-12-20 16:53:57,844-05 DEBUG 
[org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (default task-17) 
[5ecd5a55-2b7a-4dd6-b42b-cc49bbfb3962] Exception: 
org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException: 
VDSGenericException: VDSNetworkException: Timeout during rpc call
at 
org.ovirt.engine.core.vdsbroker.vdsbroker.FutureVDSCommand.get(FutureVDSCommand.java:73)
 [vdsbroker.jar:]
at 
org.ovirt.engine.core.bll.network.host.HostSetupNetworkPoller.getValue(HostSetupNetworkPoller.java:56)
 [bll.jar:]
at 
org.ovirt.engine.core.bll.network.host.HostSetupNetworkPoller.poll(HostSetupNetworkPoller.java:41)
 [bll.jar:]
at 
org.ovirt.engine.core.bll.network.host.HostSetupNetworksCommand.invokeSetupNetworksCommand(HostSetupNetworksCommand.java:426)
 [bll.jar:]
at 
org.ovirt.engine.core.bll.network.host.HostSetupNetworksCommand.executeCommand(HostSetupNetworksCommand.java:287)
 [bll.jar:]
at 
org.ovirt.engine.core.bll.CommandBase.executeWithoutTransaction(CommandBase.java:1249)
 [bll.jar:]
at 
org.ovirt.engine.core.bll.CommandBase.executeActionInTransactionScope(CommandBase.java:1389)
 [bll.jar:]
at 
org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:2053) 
[bll.jar

Re: [ovirt-devel] snapshot merge failing on Experimental

[Vinzenz Feenstra]

And to me this looks actually like the rest api returned a 500 Status not VDSM 

> On Nov 24, 2016, at 10:37 AM, Michal Skrivanek  
> wrote:
> 
>> 
>> On 24 Nov 2016, at 10:32, Evgheni Dereveanchin  wrote:
>> 
>> Hi everyone,
>> 
>> CI is failing on snapshot merge tests:
>> http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3618/testReport/junit/(root)/004_basic_sanity/snapshot_merge/
>> 
>> Not sure what is causing this but I see several patches 
>> that may be related that were recently merged:
>> https://gerrit.ovirt.org/#/c/67064
>> https://gerrit.ovirt.org/#/c/67184
>> 
>> Could someone please check why it's happening as we
>> need to fix/revert the problematic patch to make tests
>> work again.
> 
> I have to say I’m completely lost in what is being run, why, and with what 
> data
> for both patches in gerrit all check-patch/check-merged are green and working…
> 
>> 
>> Regards, 
>> Evgheni Dereveanchin 
>> ___
>> Devel mailing list
>> Devel@ovirt.org 
>> http://lists.ovirt.org/mailman/listinfo/devel 
>> 
>> 
>> 
> 
> ___
> Devel mailing list
> Devel@ovirt.org 
> http://lists.ovirt.org/mailman/listinfo/devel 
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [Call for Vote] Proposal for new Incubator Project

[Vinzenz Feenstra]

+1

> On Nov 22, 2016, at 9:26 AM, Roman Mohr  wrote:
> 
> +1
> 
> On Mon, Nov 21, 2016 at 5:55 PM, Brian Proffitt  > wrote:
> All:
> 
> This project was initially proposed for review on Oct. 9. It has been 
> reviewed for major issues and having heard no objections, it's now time to 
> formally vote on accepting this as an official oVirt incubator subproject. 
> 
> The last time we voted on one of these was during an IRC weekly meeting, so I 
> believe it is appropriate to post a Call for Vote on the Devel and Board 
> lists. 
> 
> Voting will be open until 1200 UTC Nov. 28, 2016. A net total of +5 votes 
> should be received to formalize this project as an incubator subproject. 
> Please use the following vote process:
> 
> +1
> Yes, agree, or the action should be performed. On some issues, this vote must 
> only be given after the voter has tested the action on their own system(s).
> 
> ±0
> Abstain, no opinion, or I am happy to let the other group members decide this 
> issue. An abstention may have detrimental affects if too many people abstain.
> 
> -1
> No, I veto this action. All vetos must include an explanation of why the veto 
> is appropriate. A veto with no explanation is void.
> 
> Thank you!
> Brian Proffitt
> 
> 
> ---
> 
> Project Proposal - Vagrant Provider
> 
> A vagrant provider for oVirt v4
> 
> Abstract
> 
> This will be a provider plugin for the Vagrant suite that allows
> command-line ease of virtual machine provisioning and lifecycle
> management.
> 
> Proposal
> 
> This Vagrant provider plugin will interface with the oVirt REST API
> (version 4 and higher) using the oVirt provided ruby SDK
> 'ovirt-engine-sdk-ruby'. This allows users to abstract the user
> interface and experience into a set of command line abilities to
> create, provision, destroy and manage the complete lifecycle of
> virtual machines. It also allows the use of external configuration
> management and configuration files themselves to be committed into
> code.
> 
> Background
> 
> I have previously forked and maintained the 'vagrant-ovirt' gem as
> 'vagrant-ovirt3' due to Gems requiring unique names. The original
> author has officially abandoned the project. For the last few years
> all code to maintain this project has been maintained by myself and a
> few ad-hoc github contributors. This provider interfaced directly with
> oVirt v3 using fog and rbovirt. The new project would be a fresh start
> using the oVirt provided ruby SDK to work directly with version 4.
> 
> Rationale
> 
> The trend in configuration management, operations, and devops has been
> to maintain as much of the development process as possible in terms of
> the virtual machines and hosts that they run on. With software like
> Terraform the tasks of creating the underlying infrastructure such as
> network rules, etc have had great success moving into 'Infrastructure
> as code'. The same company behind Terraform got their reputation from
> Vagrant which aims to utilize the same process for virtual machines
> themselves. The core software allows for standard commands such as
> 'up', 'provision', 'destroy' to be used across a provider framework. A
> provider for oVirt makes the process for managing VMs easier and able
> to be controlled through code and source control.
> 
> Initial Goals
> 
> The initial goal is to get the base steps of 'up', 'down' (halt), and
> 'destroy' to succeed using the oVirt provided ruby SDK for v4.
> Stretch/followup goals would be to ensure testability and alternate
> commands such as 'provision' and allow configuration management suites
> like puppet to work via 'userdata' (cloud-init).
> 
> Current Status
> 
> The version 3 of this software has been heavily utilized. The original
> fork known as 'vagrant-ovirt' has been abandoned with no plans to
> communicate or move forward. My upstream fork has had great success
> with nearly 4x the downloads from rubygems.org  . Until 
> my github fork
> has more 'stars' I cannot take over it completely so the gem was
> renamed 'vagrant-ovirt3'. This is also true for rubygems.org 
>  since
> gems are not namespaced, therefore could not be published without a
> unique name. The v4 provider is still pending my initial POC commit
> but there are no current barriers except initial oVirt hosting. The
> hosting of oVirt v3 for testing is a laptop on a UPS at my home, and
> v4 is also a different pc attached to a UPS.
> 
> External Dependencies
> 
> RHEVM/oVirt REST API - This provider must interact with the API itself
> to manage virtual machines.
> 
> Initial Committers
> 
> Marcus Young ( 3vilpenguin at gmail dot com )
> 
> -- 
> Brian Proffitt
> Principal Community Analyst
> Open Source and Standards
> @TheTechScribe
> 574.383.9BKP
> 
> ___
> Devel mailing list
> Devel@ovirt.org 
> http://lists.ovirt.org/mailman/listinfo/devel 
> 

Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project

[Vinzenz Feenstra]

> On Nov 22, 2016, at 9:12 AM, Tomas Jelinek  wrote:
> 
> 
> 
> - Original Message -
>> From: "Nir Soffer" 
>> To: "Michal Skrivanek" 
>> Cc: "devel" , "board" 
>> Sent: Monday, November 21, 2016 10:00:05 PM
>> Subject: Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project
>> 
>> On Mon, Nov 21, 2016 at 9:52 PM, Michal Skrivanek 
>> wrote:
>>> 
>>> 
 On 21 Nov 2016, at 19:48, Vojtech Szocs  wrote:
 
 
 
 - Original Message -
> From: "Eyal Edri" 
> To: "Vojtech Szocs" 
> Cc: "Barak Korren" , "devel" ,
> "board" , "Michal Skrivanek"
> 
> Sent: Monday, November 21, 2016 7:23:44 PM
> Subject: Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project
> 
>> On Mon, Nov 21, 2016 at 8:17 PM, Vojtech Szocs 
>> wrote:
>> 
>> 
>> 
>> - Original Message -
>>> From: "Barak Korren" 
>>> To: "Brian Proffitt" 
>>> Cc: "Michal Skrivanek" , bo...@ovirt.org, "devel"
>>> <
>> devel@ovirt.org>
>>> Sent: Monday, November 21, 2016 7:01:08 PM
>>> Subject: Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt
>>> Project
>>> 
>>> -1
>>> 
>>> I wonder if 8x +1 beats one -1 :)
>> 
>> 9X :-)
> 
> adding my obviously biased +1, so not sure if it counts...
> 
>> 
>> +1 for including the project as is.
>> 
>> If someone wants to run the project test or build it, the right way
>> to vote is by sending patches and making it happen.
>> 
>> I think we should get out of our gerrit silo and move all ovirt
>> projects to github. This will give ovirt much better visibility.
>> 
>> Here are some projects developed on github:
>> https://github.com/systemd/systemd 
>> https://github.com/rust-lang/rust/ 
>> https://github.com/kubernetes/kubernetes 
>> 
> 
> I would add also https://github.com/ManageIQ/  
> which we as oVirt devels are contributing to regularly.

https://github.com/cockpit-project/cockpit 

https://github.com/OpenShift 


> 
>> 
>> Nir
>> 
>>> 
>>> Not because of anything with the project itself - I think it is
>>> genuinely awesome, but because I expect a project that emerges out of
>>> the incubation process to "look" like an oVirt project, by which I
>>> mean:
>>> 1. Have the code in the oVirt Gerrit
>>> 
>>> I wonder why that would be required. We experimented with other projects
>>> being off gerrit as well(e.g. cockpit-ovirt) and bug tracking out of
>>> redhat bugzilla and for certain projcts it makes sense. With more
>>> integration with other upstream projects I see us moving to github even
>>> more...
>>> 
>>> 2. Have tests and builds running on oVirt's CI system.
>>> 
>>> Can we run mobile testing on current infra?
> 
> We are using travis for this. Our complete config file is:
> language: android
> script: "./gradlew build"
> android:
>  components:
>- platforms-tools
>- tools
>- build-tools-21.1.2
>- android-21
> 
> We don't have any additional tooling developed or anything like that.
> If we will start thinking about doing some custom/complicated stuff, we
> may consider moving to ovirt's CI. Currently, I don't see a reason.
> 
>>> 
>>> 3. Have artefacts served from oVirt's mirrors.
>>> 
>>> What artifacts? The final APK? Why? It's not a yum repo.
> 
> We need to serve them using google play store so it will reach the users 
> easily. 
> We could serve also RPM packaged APKs 
> or even create our alternative "something like play store" but Im not sure 
> what benefits 
> it would bring us.
> 
>>> 
>>> 4. Have bugs tracked in oVirt's bugzilla.
>>> 
>>> No
>>> That should never be imposed on any new project. If someone loves slow
>>> outdated tools, so be it, but for new projects I again do not see us
>>> promoting it in future
> 
> +1
> 
> Well, long story short, moVirt is a simple small tool developed by a very 
> small team
> and occasionally contributed by community (mostly as outreachy interns or 
> intern candidates). 
> It needs a swift, stable, minimal and well known tooling around which does 
> exactly what we need.
> The current combination of github for code and issue tracking + travis for 
> simple CI 
> served us fantastically. I'm quite against moving to other place just because 
> it may bring 
> some benefits in the future.
> 
>>> 
>> 
>> For 1 and 4, I feel that the benefit of allowing some projects to be
>> hosted
>> on GitHub (attract & involve community through GitHub's public service)
>> does
>> out-weigh the rule of strict consistency (have everything in oVirt
>> Gerrit).
>> 
>> 
> Any project in oVirt gerrit can be mirrored to GitHub, and most of them
> are
> ( see github.com/oVirt )
>>> 
>>> We do mirror it IIRC (or it may have bee

Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project

[Vinzenz Feenstra]

+1

> On Nov 21, 2016, at 6:07 PM, Brian Proffitt  wrote:
> 
> All:
> 
> The moVirt Project was initially accepted as an oVirt incubator project in 
> February 2015. It has been a successful subproject for quite some time and it 
> is well due for being accepted as a full oVirt project. I believe it is 
> appropriate to post a Call for Vote on the Devel and Board lists. 
> 
> http://www.ovirt.org/develop/projects/project-movirt/ 
> 
> 
> A “healthy” project, as determined by the oVirt Board, can be found at 
> http://www.ovirt.org/develop/projects/adding-a-new-project/ 
> 
> 
> Voting will be open until 1200 UTC Nov. 30, 2016. A net total of +7 votes 
> should be received to formalize this project as an full oVirt project. Please 
> use the following vote process:
> 
> +1
> Yes, agree, or the action should be performed. On some issues, this vote must 
> only be given after the voter has tested the action on their own system(s).
> 
> ±0
> Abstain, no opinion, or I am happy to let the other group members decide this 
> issue. An abstention may have detrimental affects if too many people abstain.
> 
> -1
> No, I veto this action. All vetos must include an explanation of why the veto 
> is appropriate. A veto with no explanation is void.
> 
> Thank you!
> 
> Brian Proffitt
> Principal Community Analyst
> Open Source and Standards
> @TheTechScribe
> 574.383.9BKP
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Fwd: F26 System Wide Change: DNF 2.0

[Vinzenz Feenstra]

> On Sep 9, 2016, at 5:04 PM, Sandro Bonazzola  wrote:
> 
> FYI
> This affects engine-setup, ovirt-hosted-engine-setup, ovirt-host-deploy and 
> any other tool based on OTOPI in 4.2 time frame.

TLDR: 
- Reintroduction of YUM’s configuration options includepkgs and excludepkgs
- DNF group install --with-optional option

So this shouldn’t be too big of an impact, if at all

> 
> -- Forwarded message --
> From: Jan Kurik mailto:jku...@redhat.com>>
> Date: Fri, Sep 9, 2016 at 4:49 PM
> Subject: F26 System Wide Change: DNF 2.0
> To: Development discussions related to Fedora  >, 
> devel-annou...@lists.fedoraproject.org 
> 
> 
> 
> = Proposed System Wide Change: DNF 2.0 =
> https://fedoraproject.org/wiki/Changes/DNF-2.0 
> 
> 
> 
> Change owner(s):
> * Jan Silhan 
> * Michal Luscon 
> * Igor Gnatenko 
> 
> 
> DNF rebase to version 2.0.
> 
> 
> == Detailed Description ==
> DNF-2.0 is the next upcoming major version of DNF package manager.
> Unfortunately, it brings some incompatibilities with previous version
> of DNF (DNF-1) which were either needed to preserve compatibility with
> YUM CLI or where bigger redesigns were needed. A list of identified
> incompatible changes can be found here
> http://dnf.readthedocs.io/en/latest/dnf-1_vs_dnf-2.html 
> 
> 
> 
> == Scope ==
> Proposal owners:
> * complete release notes
> * deliver DNF-2.0 stack to Rawhide
> 
> Other developers:
> * Owners of 3rd party DNF plugins or components depending on DNF
> should check and adjust their packages otherwise they may not work
> with DNF-2.0.
> 
> Release engineering:
> * All release engineering tools that depends on DNF should be tested
> against DNF-2.0.
> --
> Jan Kuřík
> Platform & Fedora Program Manager
> Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
> --
> devel mailing list
> de...@lists.fedoraproject.org 
> https://lists.fedoraproject.org/admin/lists/de...@lists.fedoraproject.org 
> 
> 
> 
> 
> -- 
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com 
>  
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt 4.0 Nightly repo

[Vinzenz Feenstra]

> On Jun 16, 2016, at 11:06 AM, Sven Kieske  wrote:
> 
> On 14/06/16 17:34, Vojtech Szocs wrote:
>> Hi,
>> 
>> ovirt-engine-dashboard is currently built from master as well.
>> 
>> We should probably create a stable branch, e.g. ovirt-engine-dashboard-1.0.
> 
> Hi,
> 
> speaking as an end user (mostly):
> 
> please not yet-another-versioning in the great ovirt project.
> 
> I'm already having severe issues tracking which engine versions works
> with which vdsm version, let alone track which datacenter and cluster
> version within each engine version works with which vdsm version and
> which features are (un)supported.
> 
> Please don't add another different version to the already far to complex
> equation.
+1  :-)
> 
> I'd suggest you take the same version number as the supported
> ovirt-engine, you also should adjust release cycles of all the
> subprojects where possible (I know that doesn't work always).
> 
> this would make every users life make so much less painful.
> 
> keep up the great work!
> 
> -- 
> Mit freundlichen Grüßen / Regards
> 
> Sven Kieske
> 
> Systemadministrator
> Mittwald CM Service GmbH & Co. KG
> Königsberger Straße 6
> 32339 Espelkamp
> T: +495772 293100
> F: +495772 29
> https://www.mittwald.de
> Geschäftsführer: Robert Meyer
> St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
> Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
> 
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] GWT developer mode not working on fc23?

[Vinzenz Feenstra]

firefox 23.esr
works for me there

> On Jun 7, 2016, at 2:28 PM, Alexander Wels  wrote:
> 
> On Tuesday, June 07, 2016 02:15:07 PM Roman Mohr wrote:
>> On Tue, Jun 7, 2016 at 2:00 PM, Roman Mohr  wrote:
>>> Hi,
>>> 
>>> I wanted to debug some GWT code the first time on fc23. No matter if I
>>> try to debug 4.0 or 3.6 I always see in my browser and in the gwt
>>> 
>>> developer console:
>>>00:01:36.758 [ERROR] Unable to load module entry point class
>>> 
>>> com.gwtplatform.mvp.client.ApplicationControllerImpl (see associated
>>> exception for details)
>>> 
>>> com.google.gwt.core.client.JavaScriptException: (NS_ERROR_FAILURE)
>>> @com.google.gwt.storage.client.StorageImpl::getItem(Ljava/lang/String;Ljav
>>> a/lang/String;)([string: 'localStorage', string:
>>> 'ENGINE_WebAdmin_LogHead']): Component
>>> returned failure code: 0x80004005 (NS_ERROR_FAILURE)
>>> [nsIDOMStorage.getItem]
>>> at
>>> com.google.gwt.dev.shell.BrowserChannelServer.invokeJavascript(BrowserCha
>>> nnelServer.java:249) at
>>> com.google.gwt.dev.shell.ModuleSpaceOOPHM.doInvoke(ModuleSpaceOOPHM.java:
>>> 136) at
>>> com.google.gwt.dev.shell.ModuleSpace.invokeNative(ModuleSpace.java:576)
>>> at
>>> com.google.gwt.dev.shell.ModuleSpace.invokeNativeObject(ModuleSpace.java:
>>> 284) at
>>> com.google.gwt.dev.shell.JavaScriptHost.invokeNativeObject(JavaScriptHost
>>> .java:91) at
>>> com.google.gwt.storage.client.StorageImpl.getItem(StorageImpl.java) at
>>> com.google.gwt.storage.client.Storage.getItem(Storage.java:257) at
>>> org.ovirt.engine.ui.common.system.ClientStorageImpl.getLocalItemImpl(Clie
>>> ntStorageImpl.java:53) at
>>> org.ovirt.engine.ui.common.system.ClientStorageImpl.getLocalItem(ClientSt
>>> orageImpl.java:46) at
>>> org.ovirt.engine.ui.common.logging.LocalStorageLogHandler.readInt(LocalSt
>>> orageLogHandler.java:56) at
>>> org.ovirt.engine.ui.common.logging.LocalStorageLogHandler.setActive(Local
>>> StorageLogHandler.java:48) at
>>> org.ovirt.engine.ui.common.logging.LocalStorageLogHandler.init(LocalStora
>>> geLogHandler.java:40) at
>>> org.ovirt.engine.ui.common.system.BaseApplicationInit.initLocalStorageLog
>>> Handler(BaseApplicationInit.java:120) at
>>> org.ovirt.engine.ui.common.system.BaseApplicationInit.onBootstrap(BaseApp
>>> licationInit.java:102) at
>>> com.gwtplatform.mvp.client.ApplicationControllerImpl.init(ApplicationCont
>>> rollerImpl.java:11) at
>>> com.gwtplatform.mvp.client.ApplicationControllerImpl.onModuleLoad(Applica
>>> tionControllerImpl.java:15) at
>>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java
>>> :62) at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI
>>> mpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498)
>>> at com.google.gwt.dev.shell.ModuleSpace.onLoad(ModuleSpace.java:411)
>>> at
>>> com.google.gwt.dev.shell.OophmSessionHandler.loadModule(OophmSessionHandl
>>> er.java:200) at
>>> com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserCh
>>> annelServer.java:526) at
>>> com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.ja
>>> va:364) at java.lang.Thread.run(Thread.java:745)
>> 
>> And I am using Firefox 17 for it.
>> 
> 
> Does FF17 have local storage? The exception appears to indicate it can't load 
> stuff from local storage. In particular it can't write/read some logging 
> stuff. 
> The problem with GWT debugger is you can't have too new of a FF/Chrome or the 
> plugin won't run. I am actually running FF25 here and it is working fine. 
> Anything newer and the plugin is no longer supported.
> 
>>> Thanks,
>>> Roman
> 
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [VDSM] Excessive warnings in vdsm log

[Vinzenz Feenstra]

> On May 18, 2016, at 1:31 PM, Piotr Kliczewski  wrote:
> 
> Please see [1][2]. We are seeing build issues for f23 so the build failures 
> are not related.
> I asked Gil from infra to take a look.
+1 :-) 

> 
> Thanks,
> Piotr
> 
> [1] https://gerrit.ovirt.org/#/c/57618/ <https://gerrit.ovirt.org/#/c/57618/>
> [2] https://gerrit.ovirt.org/#/c/57623 <https://gerrit.ovirt.org/#/c/57623>
> 
> On Wed, May 18, 2016 at 1:29 PM, Vinzenz Feenstra  <mailto:vfeen...@redhat.com>> wrote:
> 
>> On May 18, 2016, at 1:23 PM, Dan Kenigsberg > <mailto:dan...@redhat.com>> wrote:
>> 
>> On Tue, May 17, 2016 at 08:44:11AM +0200, Piotr Kliczewski wrote:
>>> Nir,
>>> 
>>> The warnings were added to annoy people so we could keep the schema align
>>> with the code.
>>> I think that we should use this opportunity to push fixes instead of
>>> disabling it.
>>> 
>>> Thanks,
>>> Piotr
>>> 
>>> On Mon, May 16, 2016 at 10:09 PM, Nir Soffer >> <mailto:nsof...@redhat.com>> wrote:
>>> 
>>>> Hi all,
>>>> 
>>>> Since data verification patches were merged, vdsm logs is spammed with
>>>> useless warnings (see bellow).
>>>> 
>>>> This spam make it harder to debug vdsm.
>>>> 
>>>> Please add configuration variable to enable this warnings, and make
>>>> them disabled by default.
>>>> 
>>>> Thanks,
>>>> Nir
>>>> 
>>>> 
>>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>>> 23:05:21,719::schemaapi::140::SchemaCache::(_report_inconsistency)
>>>> Following parameters ['ksmMergeAcrossNodes', 'haStats'] were not
>>>> recognized
>>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>>> 23:05:21,720::schemaapi::140::SchemaCache::(_report_inconsistency)
>>>> Parameter cpuUserVdsmd is not float type
>>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>>> 23:05:21,720::schemaapi::140::SchemaCache::(_report_inconsistency)
>>>> Parameter rxRate is not float type
>> 
>> I'm officially annoyed ;-)
>> we can stop report rxRate and txRate now, as engine-3.6 computes them on
>> its own.
>> 
>> Marcin, can you drop them from the code and schema?
>> 
>>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>>> 23:05:21,720::schemaapi::140::SchemaCache::(_report_inconsistency)
>>>> Parameter cpuLoad is not float type
>>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>>> 23:05:21,720::schemaapi::140::SchemaCache::(_report_inconsistency)
>>>> Parameter memUsed is not uint type
>>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>>> 23:05:21,720::schemaapi::140::SchemaCache::(_report_inconsistency)
>>>> Parameter cpuIdle is not float type
>>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>>> 23:05:21,721::schemaapi::140::SchemaCache::(_report_inconsistency)
>>>> Parameter txRate is not float type
>>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>>> 23:05:21,721::schemaapi::140::SchemaCache::(_report_inconsistency)
>>>> Parameter txDropped is not uint type
>>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>>> 23:05:21,721::schemaapi::140::SchemaCache::(_report_inconsistency)
>>>> Parameter elapsedTime is not uint type
>>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>>> 23:05:21,721::schemaapi::140::SchemaCache::(_report_inconsistency)
>>>> Parameter netConfigDirty is not boolean type
>>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>>> 23:05:21,721::schemaapi::140::SchemaCache::(_report_inconsistency)
>>>> Parameter rxErrors is not uint type
>> 
>> Piotr, how can we specify in the schema the very common type of "string
>> that happens to include only unsigned decimal number”?
> 
> I remember that we talked about that with Piotr and that the best solution 
> would be a custom type for that, so that it can be checked
> e.g. struint and strint as types, that means that those are integers 
> (signed/unsigned however passed as string) (Due to historical XMLRPC reasons)
> 
>> 
>> ___
>> Devel mailing list
>> Devel@ovirt.org <mailto:Devel@ovirt.org>
>> http://lists.ovirt.org/mailman/listinfo/devel 
>> <http://lists.ovirt.org/mailman/listinfo/devel>
> 

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [VDSM] Excessive warnings in vdsm log

[Vinzenz Feenstra]

> On May 18, 2016, at 1:23 PM, Dan Kenigsberg  wrote:
> 
> On Tue, May 17, 2016 at 08:44:11AM +0200, Piotr Kliczewski wrote:
>> Nir,
>> 
>> The warnings were added to annoy people so we could keep the schema align
>> with the code.
>> I think that we should use this opportunity to push fixes instead of
>> disabling it.
>> 
>> Thanks,
>> Piotr
>> 
>> On Mon, May 16, 2016 at 10:09 PM, Nir Soffer  wrote:
>> 
>>> Hi all,
>>> 
>>> Since data verification patches were merged, vdsm logs is spammed with
>>> useless warnings (see bellow).
>>> 
>>> This spam make it harder to debug vdsm.
>>> 
>>> Please add configuration variable to enable this warnings, and make
>>> them disabled by default.
>>> 
>>> Thanks,
>>> Nir
>>> 
>>> 
>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>> 23:05:21,719::schemaapi::140::SchemaCache::(_report_inconsistency)
>>> Following parameters ['ksmMergeAcrossNodes', 'haStats'] were not
>>> recognized
>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>> 23:05:21,720::schemaapi::140::SchemaCache::(_report_inconsistency)
>>> Parameter cpuUserVdsmd is not float type
>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>> 23:05:21,720::schemaapi::140::SchemaCache::(_report_inconsistency)
>>> Parameter rxRate is not float type
> 
> I'm officially annoyed ;-)
> we can stop report rxRate and txRate now, as engine-3.6 computes them on
> its own.
> 
> Marcin, can you drop them from the code and schema?
> 
>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>> 23:05:21,720::schemaapi::140::SchemaCache::(_report_inconsistency)
>>> Parameter cpuLoad is not float type
>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>> 23:05:21,720::schemaapi::140::SchemaCache::(_report_inconsistency)
>>> Parameter memUsed is not uint type
>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>> 23:05:21,720::schemaapi::140::SchemaCache::(_report_inconsistency)
>>> Parameter cpuIdle is not float type
>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>> 23:05:21,721::schemaapi::140::SchemaCache::(_report_inconsistency)
>>> Parameter txRate is not float type
>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>> 23:05:21,721::schemaapi::140::SchemaCache::(_report_inconsistency)
>>> Parameter txDropped is not uint type
>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>> 23:05:21,721::schemaapi::140::SchemaCache::(_report_inconsistency)
>>> Parameter elapsedTime is not uint type
>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>> 23:05:21,721::schemaapi::140::SchemaCache::(_report_inconsistency)
>>> Parameter netConfigDirty is not boolean type
>>> jsonrpc.Executor/0::WARNING::2016-05-16
>>> 23:05:21,721::schemaapi::140::SchemaCache::(_report_inconsistency)
>>> Parameter rxErrors is not uint type
> 
> Piotr, how can we specify in the schema the very common type of "string
> that happens to include only unsigned decimal number”?

I remember that we talked about that with Piotr and that the best solution 
would be a custom type for that, so that it can be checked
e.g. struint and strint as types, that means that those are integers 
(signed/unsigned however passed as string) (Due to historical XMLRPC reasons)

> 
> ___
> Devel mailing list
> Devel@ovirt.org 
> http://lists.ovirt.org/mailman/listinfo/devel 
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] A question about vdsm

[Vinzenz Feenstra]

Unfortunately there is no option for that.

However you could try to set the directory /var/run/vdsm to chmod 0770 

I can’t promise that this works however it might be worth a try


> On Apr 28, 2016, at 3:24 AM, zhukaijie  wrote:
> 
> [vm_id].recovery file is generated which /var/run/vdsm/, which contains some 
> VM config info that I want to prevent from other users. So are there any 
> configurations or ways  I can use to disable generation of the file? thank 
> you.
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ACTION REQUIRED] vdsm_master_build-artifacts-fc23-x86_64 is failing due to missing dep on fc23 .packages

[Vinzenz Feenstra]

> On Apr 14, 2016, at 11:52 AM, Nir Soffer  wrote:
> 
> On Thu, Apr 14, 2016 at 12:23 PM, David Caro  wrote:
>> On 04/14 12:06, Dan Kenigsberg wrote:
>>> On Thu, Apr 14, 2016 at 11:56:10AM +0300, Dan Kenigsberg wrote:
 
 I've added the package it check-patch.packages, but not to
 build-artifacts.packages. should be fixed in a minutes. Sorry.
>>> 
>>> Actually, it's not that, as build-artifacts.packages is a softlink
>>> 
>>>build-artifacts.packages.fc23 -> check-merged.packages.fc23
>>> 
>>> despite that,
>>> 
>>> http://jenkins.ovirt.org/job/vdsm_master_build-artifacts-fc23-x86_64/823/consoleText
>>> 
>>>mock \
>>>
>>> --configdir="/home/jenkins/workspace/vdsm_master_build-artifacts-fc23-x86_64/vdsm"
>>>  \
>>>--root="mocker-fedora-23-x86_64.fc23" \
>>>--install "autoconf automake git lago lago-ovirt libguestfs-tools-c 
>>> m2crypto make mom policycoreutils-python pyflakes python-blivet 
>>> python-coverage python-devel python-inotify python-ioprocess python-netaddr 
>>> python-nose python-pep8 python-pthreading python-rtslib python-six 
>>> python3-nose python3-six rpm-build sudo yum yum-utils grubby" \
>>>--resultdir="logs/mocker-fedora-23-x86_64.fc23.install_packages"
>>> 
>>> does not list python3-netaddr. Any idea why?
>> 
>> That package is not in the packages list of the check-merged.packages.fc23 
>> file
>> for that patch:
> 
> We have single place for build requirements - vdsm.spec. How about
> using yum builddep to
> install dependencies instead of duplicating the data?

That’s not really feasible, since we are generating vdsm.spec during the run of 
configure, then again configure requires some packages to be available….
Not really the best of ideas

> 
> Keeping multiple requirements lists is not maintainable.
> 
> Nir
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [VDSM] Vdsm build requires now python 3 on EL7

[Vinzenz Feenstra]

> On Mar 29, 2016, at 3:42 PM, Martin Perina  wrote:
> 
> 
> 
> On Tue, Mar 29, 2016 at 3:35 PM, Sandro Bonazzola  > wrote:
> 
> 
> On Tue, Mar 29, 2016 at 3:21 PM, Nir Soffer  > wrote:
> Hi all,
> 
> Since commit f247a0cff310 (el7: require newly available
> python34-nose), building vdsm
> requires Python 3 on EL7.
> 
> Unfortunately, it seems that ovirt-release-master that should add all
> the dependencies
> needed for vdsm does is not configured properly, so building vdsm will fail.
> 
> Pithon 3 is not available in CentOS 7 and as far as I can tell it's not 
> available in EPEL as well.
> Please drop Python3 on EL7.
> 
> ​Well, there is Python 3.4 on EPEL:
> 
> https://dl.fedoraproject.org/pub/epel/7/x86_64/repoview/python34.html 
> 

The appropriate way for us to do this, should be via software collections:
https://www.softwarecollections.org/en/scls/rhscl/rh-python34/ 


If it is available there then we can use it, otherwise we shouldn’t otherwise 
we’d have problems with RHEL7 users, EPEL  is not always a viable alternative.

> ​ 
> 
> 
> 
> 
>  
> 
> I heard that installing epel7 repo fixes this issue.
> 
> Cheers,
> Nir
> 
> [1] 
> https://github.com/oVirt/vdsm/commit/f247a0cff310dbbf62b07e779adbe9973734a915 
> 
> 
> 
> 
> -- 
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com 
> 
> ___
> Devel mailing list
> Devel@ovirt.org 
> http://lists.ovirt.org/mailman/listinfo/devel 
> 
> 
> ___
> Devel mailing list
> Devel@ovirt.org 
> http://lists.ovirt.org/mailman/listinfo/devel 
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.

[Vinzenz Feenstra]

> On Jan 26, 2016, at 6:00 PM, Nir Soffer  wrote:
> 
> On Tue, Jan 26, 2016 at 5:29 PM, Yaniv Dary  > wrote:
>> Hi,
>> I wanted to bring this up to get feedback on this proposed change. VDSM
>> doesn't align to other project under the oVirt umbrella like ovirt-engine,
>> ovirt-node, ovirt-guest-agent etc..
> 
> +1
> 
>> 
>> I suggest for ease of use and tracking we change the versioning to align to
>> the engine (4.0.0 in oVirt 4.0 GA) to make it easy to know which version was
>> in which release and also change the package naming to something like
>> ovirt-host-manager\ovirt-host-agent.
> 
> We cannot use the same version number, since we have different components,
> and we will not rebuild a good an tested component if another component was
> modified.
> 
> So we can share the major and probably the minor version, but the rest of the
> version will be per component.
> 
>> 
>> What do you think on this? What do you think the name should be?
> 
> ovirt-agent - symmetric with ovirt-engine - these are the biggest
> parts of the system.

Might get confused with the ovirt-guest-agent though - I can see already bugs 
being filed in the wrong components due to confusion

> 
> ovirt-host-agent is too long, we don't want to use to word "host" for 
> everything
> that run on the host.
> 
> For example, supervdsm - we cannot call it ovirt-host-superagent or
> ovirt-host-agent-helper
> or vdsm-tool - we don't want to call it ovirt-host-agent-tool - think
> about the poor
> user trying to type these names in the shell.
> 
> Nir
> 
>> 
>> Yaniv Dary
>> Technical Product Manager
>> Red Hat Israel Ltd.
>> 34 Jerusalem Road
>> Building A, 4th floor
>> Ra'anana, Israel 4350109
>> 
>> Tel : +972 (9) 7692306
>>8272306
>> Email: yd...@redhat.com
>> IRC : ydary
>> 
>> 
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
> ___
> Devel mailing list
> Devel@ovirt.org 
> http://lists.ovirt.org/mailman/listinfo/devel 
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [vdsm] New schema format proposal

[Vinzenz Feenstra]

> On Jan 19, 2016, at 10:45 AM, Piotr Kliczewski  
> wrote:
> 
> I would like to propose new format for schema that we use in vdsm. I
> started to work on a patch [1] where I explore how the new file should
> look like. I have couple of goals which I would like to achieve by
> doing this transformation:
> 1. I would like to use this file to verify engine code. Currently we
> check only vdsm which leads to compatibility issues.
> 2. I would like to base new jsonrpc based replacement for vdsClient on
> it. I want to create dynamic client which would use new format
> (description used as help when calling verbs)
> 3. Simplify Bridge.py
> 4. Extend the schema to add events
> 5. Explore ideas around api evolution and contract definition.

+1 on the general direction

YAML is much more friendly to write by hand

nitpick on the format:


values: ['status', 'on', 'off', 'reboot'] 

vs 

values:
- status
- on
- off
- reboot

The result of the latter is also a list of strings which I find personally much 
more readable
Having to put there quotes is just a pain I really disliked about the JSON 
style description of our API schema

Anyway thanks :-)

> 
> Once we agree on the format I will work on script which will translate
> one format to the other.
> 
> Thanks,
> Piotr
> 
> [1] https://gerrit.ovirt.org/#/c/52404
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] findbugs on network code

[Vinzenz Feenstra]

> On Jan 15, 2016, at 9:21 AM, Michal Skrivanek  
> wrote:
> 
> somehow findbugs started to fail[1] on network code
> any idea why?

To me this looks like that might be because of the VnicProfileModel base class 
which accesses the sourceModel parameter without checking if it is null or not 
in the cancel method.

But that is just a hunch

> 
> Thanks,
> michal
> 
> [1] 
> http://jenkins.ovirt.org/job/ovirt-engine_master_find-bugs_gerrit/43304/findbugsResult/new/
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [VDSM] health: Introduce Vdsm health monitoring

[Vinzenz Feenstra]

> On Jan 14, 2016, at 6:38 PM, Nir Soffer  wrote:
> 
> Hi all,
> 
> Continuing the leak investigation Francesco and Milan are working on,
> I posted this patch, adding leak health monitoring to vdsm [1]. This patch
> currently monitor collectible objects, and we may add other interesting
> stuff later if needed.
> 
> To enable the monitor, you must set:
> 
> [devel]
> health_monitor_enable = true
> 
> In vdsm.conf, and restart vdsm.
> 
> Here is an example logs - this was logged 60 seconds after starting vdsm,
> when running as spm:
> 
> Thread-13::DEBUG::2016-01-14
> 18:53:43,239::health::84::health::(_check) Checking health
> Thread-13::DEBUG::2016-01-14
> 18:53:43,272::health::86::health::(_check) Collected 460 objects
> Thread-13::WARNING::2016-01-14
> 18:53:43,277::health::100::health::(_check) Found 5873 uncollectible
> objects, 10 suspects implementing __del__: [' at 0x7f012c115320>', '',
> '', ' at 0x7f012c1154d0>', '',
> '', ' 0x7f012c111250>', '',
> '', ' 0x7f012c111750>']
> 
> We found 460 uncollectible objects, 10 of them are objects implementing 
> __del__.
> Having such object in a reference cycle make the entire cycle uncollectible.
> 
> The pthreading objects in this log grow as vdsm continue to run, even without
> any interaction with engine. The pthreading objects leak is caused by a cycle
> in storage.misc.RWLock, fixed in patch [2].
> 
> After solving the pthreading leak, we still have many uncollectible
> objects in the logs,
> listing them, it seems that the suspect is hiding inside a collection
> (dict, list, tuple)
> and does not appear in the gc.garbage list. I will address this in later 
> patch,
> searching in the entire object graph instead of the top level of gc.garbage.
> 
> See end of this mail for list of these objects. I printed them like this:
> 
> Enable manhole debugging shell:
> 
> [devel]
> manhole_enable = true
> 
> Connect to vdsm using manhole:
> 
> nc -U /run/vdsm/vdsmd.manhole
> 
> Print garbage:
> 
 import pprint
 import gc
 with open('/tmp/garbage.txt', 'w') as f:
>   pprint.pprint(gc.garbage, stream=f, indent=4)
> 
> These objects looks related to libvirt - Francesco, can you take a look?
Since you’re addressing Francesco directly, I am adding him explicitly - To 
point that out - Someone might skip that little part here ;)
> 
> [1] https://gerrit.ovirt.org/51708
> [2] https://gerrit.ovirt.org/51868
> 
> Nir
> 
> --- garbage after patch [2] ---
> 
> [   (,),
>{   '__dict__': ,
>'__doc__': None,
>'__module__': 'vdsm.netlink',
>'__weakref__': ,
>'_length_': 60,
>'_type_': ,
>'raw': ,
>'value': },
>,
>,
>,
>(   ,
>,
>,
>),
>,
>,
>,
>,
>,
>(   ,
>,
>),
>,
>[   [   ,
>,
>'class'],
>[   ,
>,
>'class'],
>None],
>[   [   ,
>,
>None],
>[   ,
>,
>None],
>'class'],
>[   [   ,
>,
>'class'],
>[   ,
>,
>'class'],
>None],
>[   [   ,
>,
>None],
>[   ,
>,
>None],
>'class'],
>[   [   ,
>,
>'class'],
>[   ,
>,
>'class'],
>None],
>[   [   ,
>,
>None],
>[   ,
>,
>None],
>'class'],
>[   [   ,
>,
>'class'],
>[   ,
>,
>'class'],
>None],
>[   [   ,
>,
>None],
>[   ,
>,
>None],
>'class'],
>[   [   ,
>,
>'class'],
>[   ,
>,
>'class'],
>None],
>[   [   ,
>,
>None],
>[   ,
>,
>None],
>'class'],
>[   [   ,
>,
>'class'],
>[   ,
>,
>'class'],
>None],
>[   [   ,
>,
>None],
>[   ,
>,
>None],
>'class'],
>[   [   ,
>,
>'class'],
>[   ,
>,
>'class'],
>None],
>[   [   ,
>,
>None],
>[   ,
>,
>None],
>'class'],
>[   [   ,
>,
>'class'],
>[   ,
>,
>'class'],
>None],
>[   [   ,
>,
>None],
>[   ,
>,
>None],
>'class'],
>[   [   ,
>,
>'class'],
>[   ,
>,
>'class'],
>None],
>[   [   ,
>,
>None],
>[   ,
>,
>None],
>'class'],
>[   [   ,
> 

Re: [ovirt-devel] [vdsm] merge rights on master branch

[Vinzenz Feenstra]

On 11/17/2015 11:47 AM, Dan Kenigsberg wrote:

Nir Soffer has been contributing to Vdsm for more than two years now.
Beyond his storage-related expertise, he is well-known for his thorough
code reviews and his pains when the master branch is broken. It's time
for him to take even bigger responsibility.

David, please grant Nir Soffer with merge rights on the master branch of
Vdsm.

+1
Nir: Congrats :-)


I'll keep merging network, virt, and infra patches myself, but much less
than before. Adam keeps his merge right as before (he tends to use them
on emergencies only).

Regards,
Dan.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel



--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [Spice-devel] ovirt-guest-agent behavior on disconnect

[Vinzenz Feenstra]

On 10/07/2015 02:52 PM, David Mansfield wrote:



On 10/01/2015 02:47 AM, Vinzenz Feenstra wrote:

On 09/30/2015 10:03 PM, Barak Azulay wrote:



Barak

On Sep 30, 2015, at 10:04, Michal Skrivanek
<<mailto:michal.skriva...@redhat.com>michal.skriva...@redhat.com> 
wrote:




On Sep 25, 2015, at 19:40 , David Mansfield
<<mailto:ov...@dm.cobite.com>ov...@dm.cobite.com> wrote:


[cross-posted to <mailto:devel@ovirt.org>devel@ovirt.org and
spice-de...@lists.freedesktop.org
<mailto:spice-de...@lists.freedesktop.org>]

Hi oVirt Devs,

I'm here from the spice-devel list where we were discussing some
changes to the behavior of the spice guest agent reacting to a user
disconnect (of the spice console).


Hi David,
great, any enhancement is good! Vinzenz, please add more details to
my guesses below:)



Some information about how the ovirt-guest-agent works would be
informative if you can spare a minute.

The functionality being discussed is locking the user session in the
VM when the user disconnects from spice (either intentionally or
unintentionally).


What OSs are we talking about (the behavior is significantly different
and each pose different challenges.




Also, peripherally, how does oVirt ensure secure access by
authorized users of a VM and prevent "over-the-shoulder" snooping
(spice graphics session stealing) or other forms of information leak
from a VM shared by multiple users.


We have several mechanisms to ensure that:
1 - ticketing system managed by the engine, so permissions are checked
on the ovirt-engine, if a user has permissions to connect to the vm
than the engines sends vdsm the ticket (and it sets the ticket to the
spice server ... Through libvirt), and than the client receives this
ticket to present to the spice server on connect (of course this
ticket has time expiration)
2 - every time the client disconnects we receive an event and
immediately send lock desktop command to the guest (through the
ovirt-guest-agent). This is implemented both for win and Linux but for
a Linux guest for that to work one must work on run level 5.
3 - anyway since this is racy , in order to avoid session theft we do
not allow a second user to connect to a vm when the first user
disconnected, the second user will be able to login only after the cm
was rebooted.






So here are some questions:

Can a VM be "shared" by multiple users in oVirt at all? Are there
known security issues that would make this a non-recommended or
fundamentally un-securable setup?


normally no, there is a semi-supported hook to allow that with VNC
(and even that is slightly broken IIRC at the moment), but in general
we do want so support that for specific usecases


The question is not clear enough,

In case you mean simultaneously (2 users) than the above answer is
relevant.
In case you mean sequential ... Than the answer is explained above ,
and yes we allow a vm to be shared among several users or groups.






Does the oVirt agent lock the session on disconnect? Always /
unconditionally?


IIRC It will always try to lock, but we can not guarantee that the
operation actually succeeded (long story ...)



If it's configurable, where does the configuration reside - in the
vm guest, on the vm host (/engine) or on the client?


it's oVirt management UI configuration, it changes the host's
behavior on spice disconnect per VM



Does the oVirt agent lock all sessions or the current active session?


just the active AFAIK


On windows its implemented only for desktop OSs (... Xp ...win7 ...)
we lock only the interactive session, for win server this is not
supported , in fact we do not install the SSO mechanism at all because
it works differently for those OSs (w2k3 , 2008, 2010)

On Linux it's a bit more complicated , but we find the session of the
user we know connected to the vm ... And send the lock command.

Actually not completely correct, currently we only lock the first, we
don't try to match the user, the current assumption is that we only
allow one user per VM therefore there can't be more than one active 
session.

That said, that's how it is currently implemented. Not that this is the
best way.



As explained above since there is no guarantee for that to succeed
than we do not allow other users to connect till the cm is rebooted.






How does it lock the sessions? I've looked at the code and it
appears '/usr/bin/loginctl lock-sessions' is being used on machines
it's provided on and something more complicated on older boxes.
Does the user have a way to customize this behavior? and if so, is
it VM guest, VM host or client configuration?



AFAIR this is not configurable ... But Vinzenz should be able to give
an accurate answer

The only configuration you can do as of ovirt/RHEV 3.6 is that you are
now able to say to perform one of the following actions on console
disconnect:
- Lock the screen
- Logout the curr

Re: [ovirt-devel] ovirt-guest-agent behavior on disconnect

[Vinzenz Feenstra]

s (VC1, VC2) "sessions" (e.g. with 
vlock?)


AFAIU no, Vinzenz ?
No, currently we don't however I guess we should consider that in case 
of 'Lock screen'







As I understand it, console access in ovirt is managed by setting a 
temporary graphics password and then generating an .ini file which 
is launched by remote-viewer. This password expires after a short 
period of time.  So is there a mechanism where access is denied if a 
user is already connected or is this allowed?



The  mechanism is explained above , it's the ticketing system (or 
temporary password as you referee to it above) t. The second user will 
not get a ticket from the ovirt-engine







connection is not allowed unless "strict user checking" disabled in UI
if it is disable or you use the same pwd then the previous session is 
terminated and replaced (unless using that hook I mentioned).
But we try to treat the .vv file as a one time thing, there's 
delete_this_file=1 which instructs virt-viewer to remove the file 
upon startup, so even when browser place them on a shared drive they 
shouldn't be there for too long



What kind of changes do you have in mind on the SPICE side?
It would certainly make it easier for us as currently we kind of 
guess when to lock�we receive multiple disconnecst(per channel) and 
don't really know what's going on�having a direct support for this 
inside the spice server would be better. But it needs to allow the 
flexibility of different actions except desktop lock (we have 
"nothing", "shutdown", "logoff" I think). Perhaps a way how to signal 
relevant information to vdsm is enough
This is why I have reported this issue: 
https://bugs.freedesktop.org/show_bug.cgi?id=91085
Having session based events would make it easier to avoid starting the 
handling on migrations, where in some conditions there's a race which 
can cause the screen lock mechanism to kick in just in the moment the 
transfer of the VM goes over to the destination hypervisor.




Thanks,
michal



Enough questions for now, sorry for the battering.


Feel free to ask ;-)



--
Thanks,
David Mansfield
Cobite, INC.
___
Devel mailing list
Devel@ovirt.org <mailto:Devel@ovirt.org>
http://lists.ovirt.org/mailman/listinfo/devel


___
Devel mailing list
Devel@ovirt.org <mailto:Devel@ovirt.org>
http://lists.ovirt.org/mailman/listinfo/devel





--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Vdsm: extending maintainers team

[Vinzenz Feenstra]

On 08/05/2015 01:31 PM, Vinzenz Feenstra wrote:

On 08/04/2015 10:58 AM, Dan Kenigsberg wrote:

If you follow Vdsm development, you probably have noticed that we are
short of active maintainers.

Thankfully, we have have great developers that - in my opinion - can
fill that gap. I am impressed by the quality of their reviews, their
endurance, and most importantly - their ability to unbreak whatever
code they approve.

I'd like to nominate
- Nir Soffer - for storage

+1

- Francesco Romani - for virt

+1

- Piotr Kliczewski - for infra

+1


For the mean while, I would like to keep my own single point of merger
(unless I'm away, of course).

Active and former maintainers: please approve
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel






--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Vdsm: extending maintainers team

[Vinzenz Feenstra]

On 08/04/2015 10:58 AM, Dan Kenigsberg wrote:

If you follow Vdsm development, you probably have noticed that we are
short of active maintainers.

Thankfully, we have have great developers that - in my opinion - can
fill that gap. I am impressed by the quality of their reviews, their
endurance, and most importantly - their ability to unbreak whatever
code they approve.

I'd like to nominate
- Nir Soffer - for storage

+1

- Francesco Romani - for virt

+1

- Piotr Kliczewski - for infra

For the mean while, I would like to keep my own single point of merger
(unless I'm away, of course).

Active and former maintainers: please approve
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel



--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] ovirt-guest-agent: Hardcoded uid/gid: okay to remove?

[Vinzenz Feenstra]

On 02/14/2015 02:39 AM, Cameron Norman wrote:

Hello,

Hi,

Well I think there shouldn't be anything broken if you would remove it, 
as we do reference everything by name everywhere.
The reason for hard-coding it is that we have it on fedora and RHEL in 
the setup package See: 
https://git.fedorahosted.org/cgit/setup.git/tree/uidgid

It's something like a well-known UID/GID when specified there.

Regards,


In the RPM and debian packaging for ovirt-guest-agent, the UID/GID 
numbers are hardcoded. I need to remove this to fix a policy violation 
in Debian. What are the implications of making the uid/gid's 
dynamically allocated, i.e. why were they hardcoded in the first place?


Thank you all,
--
Cameron Norman


___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel



--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Reference implementation of events

[Vinzenz Feenstra]

On 02/09/2015 04:23 PM, Piotr Kliczewski wrote:

Hi,

As you may know I currently work on event infrastructure which will
let vdsm push information to the engine. I already pushed some drafts
providing event functionality and started to think which part of
engine <-> vdsm interaction could be changed to events. The goal is to
build usable api for it as well as provide example how to migrate
other parts of code to events.

Initially we started to look at VM.getStats [1] but we still want to
have Host.getAllVmStats run by quartz job. I had a chat with Vinzenz
about the structure and frequency of data change for VM.getStats and
it seems that the data changes ~2s so this verb is not the best choice
to send events with deltas containing the change since we are polling
every 3s for the information.

Just a correction here: We're currently polling the stats every 15 seconds.
What the wiki page showed was an attempt to apply classification to the
data returned by getAllVmStats to avoid polling data that does not change
that often.

In an event based system the content of the there [2] proposed verbs:
'getVmStatus', 'getVmConfInfo' and 'getVmGuestDetails' could be potentially
changed to events.

The contents of the proposed 'getAllVmRuntimeStats' verb was under the 
consideration
of the periodic polling (~3seconds)  approach, which does not fit 
anymore in an

event based system.
One thing is clear though, this data changes quite frequently and is 
used by the engine

(ignoring the hashes which were part of the proposal)
The fields cpuSys, cpuUser, memUsage are needed for the frontend and 
must be distributed

frequently.
The value of 'elapsedTime' and 'statsAge' are changing constantly 
basically with every request,
however I am not sure about the value to the engine. This is a point to 
discuss.


The VM 'status' should, in normal/expected scenarios, change rarely, 
however when it does,
in most, but necessary not all cases (to be determined), the engine must 
know immediately.

(This is why it is polled every 3 seconds)

The 'hashes.config' value, probably gets kind of irrelevant on an event 
based system, since we would
send changed devices / configuration as the aforementioned deltas in an 
event.

But I might be wrong about that.

The 'getAllVmDeviceStats' data is something that should be periodically, 
kind of, requested.
Part of the data is used by SLA, other parts are used by the engine to 
display it, and then parts of it,
might be used by the DWH. How we are going about those things, is also 
open for discussion.


I hope I haven't left out anything so far. I just wanted to give a bit 
of an idea how the page should be considered

in relation to the new message based implementations.



We started to explore which data generated by vdsm/guest agent could
be sent as events and he pointed me to [2].

I would like to trigger discussion about how to dived data to maximize
benefits of sending events with deltas and for some parts of data keep
polling functionality as it is now.

Do you have any suggestion which verb we could safely use as reference
implementation for events?

Thanks,
Piotr

[1] http://gerrit.ovirt.org/#/c/37488/
[2] http://www.ovirt.org/Proposal_VDSM_-_Engine_Data_Statistics_Retrieval



--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [Devel] Proposing Roy Golan as VDSM Fake maintainer

[Vinzenz Feenstra]

On 11/06/2014 09:33 AM, Tomas Jelinek wrote:

Hi,

I would like to propose Roy Golan as VDSM Fake (http://www.ovirt.org/VDSM_Fake) 
co-maintainer.

+1


Your response would be appreciated.

Thanks in advance.
Tomas
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel



--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ovirt-users] ovirt-3.5 ovirt-guest-agent linux builds are now available

[Vinzenz Feenstra]

On 10/02/2014 09:49 PM, Bob Doolittle wrote:

On 10/02/2014 03:19 PM, Gianluca Cecchi wrote:
On Thu, Oct 2, 2014 at 8:34 PM, Bob Doolittle <mailto:b...@doolittle.us.com>> wrote:


I can't seem to find any spec for the "usual guest OBS
repositories" for guest-agent on Ubuntu. It's not specified on
this page:

http://www.ovirt.org/How_to_install_the_guest_agent_in_Ubuntu

Note that this page and the pages it references probably need
updating, since it's supposed to provide links to all relevant
info for all platforms:
http://www.ovirt.org/Understanding_Guest_Agents_and_Other_Tools#Linux_Guests

Pointer for Ubuntu please?

Thanks,
Bob


I think correct link is what I referred in my first answer and that I 
used:

http://www.ovirt.org/Feature/GuestAgentUbuntu

In that page we have the timestamp and tested version of
*Name*: oVirt Guest Agent on Ubuntu
*Modules*: ovirt-guest-agent
*Target version*: 3.4.1
*Status*: Done
*Last updated*: 2014-08-05 by Vfeenstr

That is valid also for 3.5rc3 and ubuntu 14.04

I edited the page
http://www.ovirt.org/Understanding_Guest_Agents_and_Other_Tools#Linux_Guests

pointing to my referred page.
Let me know if ok for all

Gianluca



This looks a little bit like an APT repository (it has Packages and 
Release) but I don't see the structure I expect (e.g. a dists directory). 
This is just the way how OBS is doing this, so I have no influence on 
the 'dists' directory in this case the dist name is just a slash ('/')
What is the appropriate APT line e.g. for sources.list? What is the 
uri, suite, and component? I'm able to fetch the .deb and install it 
manually (and then fix the missing dependencies) but a properly 
configured APT repository would make this more seamless.
How to add it to the sources.list is shown here: 
http://www.ovirt.org/Feature/GuestAgentUbuntu#Installation
The URL to use can be found here: 
http://www.ovirt.org/Feature/GuestAgentUbuntu#Repository




-Bob




--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ovirt-users] ovirt-3.5 ovirt-guest-agent linux builds are now available

[Vinzenz Feenstra]

On 10/02/2014 02:52 PM, Gianluca Cecchi wrote:
On Thu, Oct 2, 2014 at 2:51 PM, Gianluca Cecchi 
mailto:gianluca.cec...@gmail.com>> wrote:


On Thu, Oct 2, 2014 at 12:26 PM, Vinzenz Feenstra
mailto:vfeen...@redhat.com>> wrote:

Hi,

I have just released the ovirt-guest-agent ovirt-3.5 builds
with version 1.0.10.2

The usual guest agent OBS repositories on have been updated for
- Debian 7
- Ubuntu 12.04, 13.10, 14.04

Hello,
this is for Ubuntu 14.04.1, following
http://www.ovirt.org/Feature/GuestAgentUbuntu

All ok.


I forgot to mention oVirt version: Infra is with 3.5 rc2 on CentOS 6.5 
(one system for engine and one for vdsm host).

Thanks! :-)

--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] ovirt-3.5 ovirt-guest-agent linux builds are now available

[Vinzenz Feenstra]

Hi,

I have just released the ovirt-guest-agent ovirt-3.5 builds with version 
1.0.10.2


The usual guest agent OBS repositories on have been updated for
- Debian 7
- Ubuntu 12.04, 13.10, 14.04
- openSuSE 12.3, 13.1
- SuSE Linux Enterprise 11 SP3

Builds for the guest agent on the fedora environment have been posted as 
updates and are currently available in the testing repositories for:

- Fedora 19
- Fedora 20
- Fedora 21
- EPEL6 (el6)
- EPEL5 (el5)
- EPEL7 (el7)

It would be great if the users of the ovirt-guest-agent on Linux guests 
could test the guest agent.


Thanks.

--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ovirt-users] [QE][ACTION REQUIRED] oVirt 3.5.0 RC2 status

[Vinzenz Feenstra]

On 08/20/2014 03:40 PM, Vinzenz Feenstra wrote:

On 08/20/2014 09:10 AM, Sandro Bonazzola wrote:

Hi,
early this week we postponed oVirt 3.5.0 RC2 to Thu *2014-08-21 08:00 
UTC*,
we'll discuss current status in today oVirt sync meeting and 
eventually postpone RC2 by another week.


Maintainers (supposing we keep Thu *2014-08-21 08:00 UTC*):
- Please be sure that 3.5 snapshot allow to create VMs before 
*2014-08-20 15:00 UTC*
- Please be sure that no pending patches are going to block the 
release before *2014-08-20 15:00 UTC*
- If any patch must block the RC release please raise the issue as 
soon as possible.


The bug tracker [1] shows the following proposed blockers to be 
reviewed:


WhiteboardBug IDStatusSummary
infra1127877POSTvdsm-tool configure --force does not 
configure qemu.conf properly in the first run on a fresh install
sla1129261NEWprepareImage api call fails with [Errno 
2] No such file or directory
sla1130038NEWprepareImage api call fails with [Errno 
2] No such file or directory
storage1128776POSTCan't change a vm disk's storage 
domain from a file domain to a block domain when creating a template 
from a vm
storage1127294POSTLive Merge: Resolve unknown merge 
status in vdsm after host crash
storage1109920POSTLive Merge: Extend internal block 
volumes during merge
I actually think that 
https://bugzilla.redhat.com/show_bug.cgi?id=1131548 should be 
considered a blocker, however this seems to be related to live merge 
currently it is assigned to virt.
The point is that there's an exception thrown during recovery which 
will cause the state of the VM to be in a very unusable state.

Known indications so far:
- It's shown as 'Paused' in the UI while the VM effectively is 'UP'
- The guest agent communication channels are not initialized due to 
the earlier bail out caused by the exception

   - Consequence visible in UI:
   - You can't soft shutdown the vm
   - Causes most likely exceptions when trying to access methods from 
the guest agent during shutdown of the VM, live migration might fail

   - and other issues
So the fix for this issue I described above is already merged to 
ovirt-3.5 the bug had two issues and the first one is solved already by 
the merged patch. The second portion on the other hand is supposedly 
less severe so it might not be a blocker anymore.





And the following dependencies still open:
Bug 1041569 - [NFR] libvirt: Returning the watermark for all the 
images opened for writing
Bug 1102881 - virDomainBlockCommit fails with live snapshots on oVirt 
block storage



Some of above blockers may be dropped on today oVirt sync meeting if 
still open.
Some of the bugs blocking the release prevents automated testing to 
verify the release.

Please fix them as soon as possible.


Feature freeze is now effective, and branch has been created.
All new patches must be backported to 3.5 branch too.
Features completed are marked in green on Features Status Table [2]

There are still 425 bugs [3] targeted to 3.5.0.
Excluding node and documentation bugs we still have 381 bugs [4] 
targeted to 3.5.0.


More in detail [5]:

WhiteboardNEWASSIGNEDPOSTTotal
 7..7
gluster95216
i18n..11
infra282737
integration25.631
network1811534
node246636
ppc2.46
sla38.1856
storage86109105
ux222.24
virt594972
Total3183077425


Maintainers / Assignee:
- Please ensure that completed features are marked in green on 
Features Status Table [2]
- Please remember to rebuild your packages before *2014-08-20 15:00* 
(supposing we keep Thu *2014-08-21 08:00 UTC*) if needed, otherwise 
nightly

snapshot will be taken.
- If you find a blocker bug please remember to add it to the tracker [1]
- Please fill release notes, the page has been created here [6]
- Please review and add test cases to oVirt 3.5 Third Test Day [7]
- Please update the target to 3.5.1 or later for bugs that won't be 
in 3.5.0:

   it will ease gathering the blocking bugs for next releases.


Community:
- Due to the RC2 delay, the 3rd test day has been postponed to Aug 28th.
- You're welcome to join us testing next beta release and getting 
involved in oVirt Quality Assurance[8]



[1] http://bugzilla.redhat.com/1073943
[2] http://bit.ly/17qBn6F
[3] http://red.ht/1pVEk7H
[4] http://red.ht/1zT2mSq
[5] http://red.ht/1q7SqNL
[6] http://www.ovirt.org/OVirt_3.5_Release_Notes
[7] http://www.ovirt.org/OVirt_3.5_TestDay
[8] http://www.ovirt.org/OVirt_Quality_Assurance

Thanks,







--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering V

Re: [ovirt-devel] [ovirt-users] [QE][ACTION REQUIRED] oVirt 3.5.0 RC2 status

[Vinzenz Feenstra]

On 08/20/2014 09:10 AM, Sandro Bonazzola wrote:

Hi,
early this week we postponed oVirt 3.5.0 RC2 to Thu *2014-08-21 08:00 UTC*,
we'll discuss current status in today oVirt sync meeting and eventually 
postpone RC2 by another week.

Maintainers (supposing we keep Thu *2014-08-21 08:00 UTC*):
- Please be sure that 3.5 snapshot allow to create VMs before *2014-08-20 15:00 
UTC*
- Please be sure that no pending patches are going to block the release before 
*2014-08-20 15:00 UTC*
- If any patch must block the RC release please raise the issue as soon as 
possible.

The bug tracker [1] shows the following proposed blockers to be reviewed:

Whiteboard  Bug ID  Status  Summary
infra   1127877 POSTvdsm-tool configure --force does not configure 
qemu.conf properly in the first run on a fresh install
sla 1129261 NEW prepareImage api call fails with [Errno 2] No 
such file or directory
sla 1130038 NEW prepareImage api call fails with [Errno 2] No 
such file or directory
storage 1128776 POSTCan't change a vm disk's storage domain from a 
file domain to a block domain when creating a template from a vm
storage 1127294 POSTLive Merge: Resolve unknown merge status in 
vdsm after host crash
storage 1109920 POSTLive Merge: Extend internal block volumes 
during merge
I actually think that 
https://bugzilla.redhat.com/show_bug.cgi?id=1131548 should be considered 
a blocker, however this seems to be related to live merge currently it 
is assigned to virt.
The point is that there's an exception thrown during recovery which will 
cause the state of the VM to be in a very unusable state.

Known indications so far:
- It's shown as 'Paused' in the UI while the VM effectively is 'UP'
- The guest agent communication channels are not initialized due to the 
earlier bail out caused by the exception

   - Consequence visible in UI:
   - You can't soft shutdown the vm
   - Causes most likely exceptions when trying to access methods from 
the guest agent during shutdown of the VM, live migration might fail

   - and other issues




And the following dependencies still open:
Bug 1041569 - [NFR] libvirt: Returning the watermark for all the images opened 
for writing
Bug 1102881 - virDomainBlockCommit fails with live snapshots on oVirt block 
storage


Some of above blockers may be dropped on today oVirt sync meeting if still open.
Some of the bugs blocking the release prevents automated testing to verify the 
release.
Please fix them as soon as possible.


Feature freeze is now effective, and branch has been created.
All new patches must be backported to 3.5 branch too.
Features completed are marked in green on Features Status Table [2]

There are still 425 bugs [3] targeted to 3.5.0.
Excluding node and documentation bugs we still have 381 bugs [4] targeted to 
3.5.0.

More in detail [5]:

Whiteboard  NEW ASSIGNEDPOSTTotal
  7   .   .   7
gluster 9   5   2   16
i18n.   .   1   1
infra   28  2   7   37
integration 25  .   6   31
network 18  1   15  34
node24  6   6   36
ppc 2   .   4   6
sla 38  .   18  56
storage 86  10  9   105
ux  22  2   .   24
virt59  4   9   72
Total   318 30  77  425


Maintainers / Assignee:
- Please ensure that completed features are marked in green on Features Status 
Table [2]
- Please remember to rebuild your packages before *2014-08-20 15:00* (supposing 
we keep Thu *2014-08-21 08:00 UTC*) if needed, otherwise nightly
snapshot will be taken.
- If you find a blocker bug please remember to add it to the tracker [1]
- Please fill release notes, the page has been created here [6]
- Please review and add test cases to oVirt 3.5 Third Test Day [7]
- Please update the target to 3.5.1 or later for bugs that won't be in 3.5.0:
   it will ease gathering the blocking bugs for next releases.


Community:
- Due to the RC2 delay, the 3rd test day has been postponed to Aug 28th.
- You're welcome to join us testing next beta release and getting involved in 
oVirt Quality Assurance[8]


[1] http://bugzilla.redhat.com/1073943
[2] http://bit.ly/17qBn6F
[3] http://red.ht/1pVEk7H
[4] http://red.ht/1zT2mSq
[5] http://red.ht/1q7SqNL
[6] http://www.ovirt.org/OVirt_3.5_Release_Notes
[7] http://www.ovirt.org/OVirt_3.5_TestDay
[8] http://www.ovirt.org/OVirt_Quality_Assurance

Thanks,




--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Po

Re: [ovirt-devel] vdsClient desktopLogoff bug

[Vinzenz Feenstra]

On 08/19/2014 11:35 AM, Denis Kirjanov wrote:


- Исходное сообщение -
От: "Vinzenz Feenstra" 
Кому: "Dan Kenigsberg" , "Denis Kirjanov" 
Копия: devel@ovirt.org
Отправленные: Вторник, 19 Август 2014 г 10:08:48
Тема: Re: [ovirt-devel] vdsClient desktopLogoff bug

On 08/18/2014 06:17 PM, Dan Kenigsberg wrote:

On Mon, Aug 18, 2014 at 05:48:45PM +0400, Denis Kirjanov wrote:

sendkeys would work (ctrl alt backspace), but it's not implemented in my 
version(

(vdsm-cli-0:4.10.2-22.0.el6.noarch)

- Исходное сообщение -
От: "Denis Kirjanov" 
Кому: devel@ovirt.org
Отправленные: Понедельник, 18 Август 2014 г 16:07:58
Тема: [ovirt-devel] vdsClient desktopLogoff bug

Hi,

I'm using RHEV 3.1.0-53.
I can successfully invoke the desktopLock command, but the desktopLogoff command  returns 
"Virtual machine does not exist".
Command looks like the following one:
vdsClient -s --truststore   desktopLogoff true 

Could you show the relevant parts of vdsm.log for both commands?

Desktop Logoff is currently a noop in the guest agent. It'll be
implemented sometime later.


Ok, I see. Thanks.
I'm asking this question since I want to avoid the gdm lock screen window:
1) On a specific event I do the lock screen command to vm
2) I do the logout from the host system
3) I do the login on the host system .The process sets up the vm ticket, 
queries the ports from the VM manager and _performs the desktopLogin_!
4) Spice session takes place. Here I do expect to see the VM destop, not the 
lock screen window.

I've found that the SSO in the previous scenario works if I do the logout from 
the VM manually.

We basically have RFE's for both the cases. That we should allow not to 
lock the screen on disconnect and that we have a logout. Both features 
should be implemented with ovirt 3.6


HTH

--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] vdsClient desktopLogoff bug

[Vinzenz Feenstra]

On 08/18/2014 06:17 PM, Dan Kenigsberg wrote:

On Mon, Aug 18, 2014 at 05:48:45PM +0400, Denis Kirjanov wrote:

sendkeys would work (ctrl alt backspace), but it's not implemented in my 
version(

(vdsm-cli-0:4.10.2-22.0.el6.noarch)

- Исходное сообщение -
От: "Denis Kirjanov" 
Кому: devel@ovirt.org
Отправленные: Понедельник, 18 Август 2014 г 16:07:58
Тема: [ovirt-devel] vdsClient desktopLogoff bug

Hi,

I'm using RHEV 3.1.0-53.
I can successfully invoke the desktopLock command, but the desktopLogoff command  returns 
"Virtual machine does not exist".
Command looks like the following one:
vdsClient -s --truststore   desktopLogoff true 

Could you show the relevant parts of vdsm.log for both commands?
Desktop Logoff is currently a noop in the guest agent. It'll be 
implemented sometime later.



--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] SSO using remote-viewer

[Vinzenz Feenstra]

On 08/12/2014 03:01 PM, Denis Kirjanov wrote:

Ok, vdsClient with the desktopLogin works pretty well on the first step.
I found a weird behavior when closing remote-viewer window. Even a session
remains open (no logout/switch user is performed), the subsequent connect with 
the _same ticket_ spits out a gdm window
with a password...
You mean the password is shown to the user? That would be pretty bad. As 
for the disconnect that surprises me a little bit. Can you please 
perform the connection to the VM and then disconnect and pass me the 
logs of vdsm /var/log/vdsm/vdsm.log for the host the vm is running on?


Also it'd be great if you could before turn on debug logging on the VM 
for the guest agent /etc/ovirt-guest-agent.conf (replace INFO with 
DEBUG) and restart the service.


# service ovirt-guest-agent restart

and pass me the logs for it as well ( 
/var/log/ovirt-guest-agent/ovirt-guest-agent.log )


Thanks




- Исходное сообщение -
От: "Denis Kirjanov" 
Кому: "Vinzenz Feenstra" 
Копия: devel@ovirt.org
Отправленные: Понедельник, 11 Август 2014 г 18:34:24
Тема: Re: [ovirt-devel] SSO using remote-viewer



- Исходное сообщение -----
От: "Vinzenz Feenstra" 
Кому: "Denis Kirjanov" 
Копия: "Michal Skrivanek" , devel@ovirt.org
Отправленные: Понедельник, 11 Август 2014 г 17:26:30
Тема: Re: [ovirt-devel] SSO using remote-viewer

On 08/11/2014 03:12 PM, Denis Kirjanov wrote:

- Исходное сообщение -
От: "Vinzenz Feenstra" 
Кому: "Michal Skrivanek" , "Denis Kirjanov" 

Копия: devel@ovirt.org
Отправленные: Понедельник, 11 Август 2014 г 17:07:40
Тема: Re: [ovirt-devel] SSO using remote-viewer

On 08/11/2014 03:06 PM, Vinzenz Feenstra wrote:

On 08/11/2014 03:01 PM, Michal Skrivanek wrote:

On Aug 11, 2014, at 14:14 , Denis Kirjanov  wrote:


Hi guys,

I'm trying to login to a virtual machine without using the web
interface (User Portal) but through the remote-viewer and a small
python script to gather all required info such a certificate
subject, ticken and ports.
The virtual machine has the rhevm sso package installed so I can get
to the machine through the web UI,
but I can't do the same thing using remote-viewer. What I do see is
a gdm login window with
my user account and 2 icons (Login into session and RHEV-M SSO login).

Looks like I have to invoke something inside my python script to get
an access but I can't figure out what is missing…

you need to issue the "desktopLogin" command to actually perform the
sign on. The viewer itself doesn't do anything

If this is going through vdsm then it's the desktop login command. Via
the REST API it'd be just /vms/{vmid}/logon

Note: The REST API supports this from oVirt/RHEV 3.5

Thanks, but we're using oVirt/RHEV 3.1.
Does the PythonAPI (or ReST API) support something like this in 3.1?

Well only the XMLRPC api of the Host supports the desktopLogin verb, as
Michal already said.

vdsClient for example can do this, when it has the right certificates

vdsClient -s  desktopLogin

HTH

Could you please guide me on how to set a required certificates on
a client?

Thanks!




Thanks,
michal


Thanks!
_______
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel





--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] SSO using remote-viewer

[Vinzenz Feenstra]

On 08/11/2014 03:12 PM, Denis Kirjanov wrote:


- Исходное сообщение -
От: "Vinzenz Feenstra" 
Кому: "Michal Skrivanek" , "Denis Kirjanov" 

Копия: devel@ovirt.org
Отправленные: Понедельник, 11 Август 2014 г 17:07:40
Тема: Re: [ovirt-devel] SSO using remote-viewer

On 08/11/2014 03:06 PM, Vinzenz Feenstra wrote:

On 08/11/2014 03:01 PM, Michal Skrivanek wrote:

On Aug 11, 2014, at 14:14 , Denis Kirjanov  wrote:


Hi guys,

I'm trying to login to a virtual machine without using the web
interface (User Portal) but through the remote-viewer and a small
python script to gather all required info such a certificate
subject, ticken and ports.
The virtual machine has the rhevm sso package installed so I can get
to the machine through the web UI,
but I can't do the same thing using remote-viewer. What I do see is
a gdm login window with
my user account and 2 icons (Login into session and RHEV-M SSO login).

Looks like I have to invoke something inside my python script to get
an access but I can't figure out what is missing…

you need to issue the "desktopLogin" command to actually perform the
sign on. The viewer itself doesn't do anything

If this is going through vdsm then it's the desktop login command. Via
the REST API it'd be just /vms/{vmid}/logon

Note: The REST API supports this from oVirt/RHEV 3.5

Thanks, but we're using oVirt/RHEV 3.1.
Does the PythonAPI (or ReST API) support something like this in 3.1?
Well only the XMLRPC api of the Host supports the desktopLogin verb, as 
Michal already said.


vdsClient for example can do this, when it has the right certificates

vdsClient -s  desktopLogin

HTH





Thanks,
michal


Thanks!
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel







--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] SSO using remote-viewer

[Vinzenz Feenstra]

On 08/11/2014 03:06 PM, Vinzenz Feenstra wrote:

On 08/11/2014 03:01 PM, Michal Skrivanek wrote:

On Aug 11, 2014, at 14:14 , Denis Kirjanov  wrote:


Hi guys,

I'm trying to login to a virtual machine without using the web 
interface (User Portal) but through the remote-viewer and a small 
python script to gather all required info such a certificate 
subject, ticken and ports.
The virtual machine has the rhevm sso package installed so I can get 
to the machine through the web UI,
but I can't do the same thing using remote-viewer. What I do see is 
a gdm login window with

my user account and 2 icons (Login into session and RHEV-M SSO login).

Looks like I have to invoke something inside my python script to get 
an access but I can't figure out what is missing…
you need to issue the "desktopLogin" command to actually perform the 
sign on. The viewer itself doesn't do anything
If this is going through vdsm then it's the desktop login command. Via 
the REST API it'd be just /vms/{vmid}/logon

Note: The REST API supports this from oVirt/RHEV 3.5


Thanks,
michal


Thanks!
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel






--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] SSO using remote-viewer

[Vinzenz Feenstra]

On 08/11/2014 03:01 PM, Michal Skrivanek wrote:

On Aug 11, 2014, at 14:14 , Denis Kirjanov  wrote:


Hi guys,

I'm trying to login to a virtual machine without using the web interface (User 
Portal) but through the remote-viewer and a small python script to gather all 
required info such a certificate subject, ticken and ports.
The virtual machine has the rhevm sso package installed so I can get to the 
machine through the web UI,
but I can't do the same thing using remote-viewer. What I do see is a gdm login 
window with
my user account and 2 icons (Login into session and RHEV-M SSO login).

Looks like I have to invoke something inside my python script to get an access 
but I can't figure out what is missing…

you need to issue the "desktopLogin" command to actually perform the sign on. 
The viewer itself doesn't do anything
If this is going through vdsm then it's the desktop login command. Via 
the REST API it'd be just /vms/{vmid}/logon


Thanks,
michal


Thanks!
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel



--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] VDSM mom dependancy on RHEL7

[Vinzenz Feenstra]

On 07/23/2014 12:36 AM, Martin Polednik wrote:

Hi,

I've gone through installing VDSM on RHEL7 host
(Red Hat Enterprise Linux Server release 7.0 (Maipo)) and encountered
issue with mom:

Error: Package: mom-0.4.1-2.el6.noarch (ovirt-3.5-epel)

This is a EL6 package...

Requires: python(abi) = 2.6
Installed: python-2.7.5-16.el7.x86_64 (@rhel7)
python(abi) = 2.7
python(abi) = 2.7

Repositories used were master, master-snapshots and 3.5 + dependancies.
Although it is possible to get it working by getting mom source and
rebuilding it on RHEL7, I'd like to know if there is different RHEL7
repo or this is mistake in repos.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel



--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] "Host.queryVms": A proposal for new a VDSM API verb

[Vinzenz Feenstra]

On 07/22/2014 02:54 PM, Piotr Kliczewski wrote:

On Tue, Jul 22, 2014 at 2:04 PM, Vinzenz Feenstra  wrote:

On 07/22/2014 02:00 PM, Francesco Romani wrote:

- Original Message -

From: "Vinzenz Feenstra" 
To: devel@ovirt.org
Sent: Tuesday, July 22, 2014 11:29:40 AM
Subject: Re: [ovirt-devel] "Host.queryVms": A proposal for new a VDSM API
verb

On 07/14/2014 04:05 PM, Vinzenz Feenstra wrote:

Hi,

Since this mail did not receive enough attention I am bumping it again.

For this proposal exists currently a draft patch
http://gerrit.ovirt.org/#/c/28819/
The patch is not final since the query function should not require to
update all the data
on every call. (This should be done directly by data modifying code.
However that would be implemented by follow up patches)

The trackable.py implementation also can be easily extended in future
for enabling push notifications to the engine once
we switched to the new communication. This could be done by subscribing
to certain keys in the TrackableMapping instance.
(Not implemented yet)

Nice! Both nice to have now and on top of json/push notifications
tomorrow.
I just had a quick look to the changes to vm.py and to the interface
and looks nice as well.

[...]

I have executed some tests and in those tested scenarios the new Verb
can result in an improvement of 75%-90% of data transferred and average
response body size depending on the scenario and usage.

The test results can be found here:
http://www.ovirt.org/Feature/VDSM_VM_Query_API/Measurements#Results
(An explanation of the tested methods is on the top of the page and a
description of the scenario in each section)

Nice graphs :)
Silly comment: having units in 'bytes' on the X-axis makes the numbers
somehow
hard to parse (to me). I suggest you to convert them to KiB for better
readability.
The savings look really nice.

The table below shows it in MiB in a separate column


Bests,


API looks good but I have small comment to json schema. Vdsm is
currently versioned 4.16 not
4.15 so please update Since for each schema change.

I'll do with the next rebase of the patch, thanks for pointing it out. :-)



--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel



--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] "Host.queryVms": A proposal for new a VDSM API verb

[Vinzenz Feenstra]

On 07/22/2014 02:00 PM, Francesco Romani wrote:

- Original Message -

From: "Vinzenz Feenstra" 
To: devel@ovirt.org
Sent: Tuesday, July 22, 2014 11:29:40 AM
Subject: Re: [ovirt-devel] "Host.queryVms": A proposal for new a VDSM API verb

On 07/14/2014 04:05 PM, Vinzenz Feenstra wrote:

Hi,

Since this mail did not receive enough attention I am bumping it again.

For this proposal exists currently a draft patch
http://gerrit.ovirt.org/#/c/28819/
The patch is not final since the query function should not require to
update all the data
on every call. (This should be done directly by data modifying code.
However that would be implemented by follow up patches)

The trackable.py implementation also can be easily extended in future
for enabling push notifications to the engine once
we switched to the new communication. This could be done by subscribing
to certain keys in the TrackableMapping instance.
(Not implemented yet)

Nice! Both nice to have now and on top of json/push notifications tomorrow.
I just had a quick look to the changes to vm.py and to the interface
and looks nice as well.

[...]

I have executed some tests and in those tested scenarios the new Verb
can result in an improvement of 75%-90% of data transferred and average
response body size depending on the scenario and usage.

The test results can be found here:
http://www.ovirt.org/Feature/VDSM_VM_Query_API/Measurements#Results
(An explanation of the tested methods is on the top of the page and a
description of the scenario in each section)

Nice graphs :)
Silly comment: having units in 'bytes' on the X-axis makes the numbers somehow
hard to parse (to me). I suggest you to convert them to KiB for better 
readability.
The savings look really nice.

The table below shows it in MiB in a separate column


Bests,




--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] "Host.queryVms": A proposal for new a VDSM API verb

[Vinzenz Feenstra]

On 07/14/2014 04:05 PM, Vinzenz Feenstra wrote:

Hi,

Since this mail did not receive enough attention I am bumping it again.

For this proposal exists currently a draft patch 
http://gerrit.ovirt.org/#/c/28819/
The patch is not final since the query function should not require to 
update all the data
on every call. (This should be done directly by data modifying code. 
However that would be implemented by follow up patches)


The trackable.py implementation also can be easily extended in future 
for enabling push notifications to the engine once
we switched to the new communication. This could be done by subscribing 
to certain keys in the TrackableMapping instance.

(Not implemented yet)

Anyway I am asking once more for comments on the proposal.



This proposal is a follow up on a previous discussion about
optimizing the communication between VDSM and the ovirt-engine.


Currently the engine polls VDSM every 3 seconds with the `list`
verb to retrieve the status of all VMs. Every 5th time (every 15
seconds) it alternates to 'getAllVmStats' which gives more
information about the VMs.


Quite a big portion of the data, mainly the reply of getAllVmStats,
is only of interest if it actually changes so that the engine/back-end
can act on changes and update rows accordingly.

Now the problem is that there is quite a lot of data transferred
which is not really necessary and there is a 15 seconds delay on
communicating changes to certain VMs before the engine actually
can react on them and before these changes can be communicated
to the user.

As part of an improvement on this matter I'd like to propose a new API
verb for VDSM:

Host.queryVms(vmIds=[], fields=[], exclude=[], changedSince='')

This new verb is intended to eventually replace 2 currently
used verbs `list` and `getAllVmStats`. `queryVms` is supposed to
allow to request any data fields of a VM which can be requested through
the public API:

- Statistics
- Configuration
- Status information
- Guest OS Information

I have executed some tests and in those tested scenarios the new Verb
can result in an improvement of 75%-90% of data transferred and average
response body size depending on the scenario and usage.

The test results can be found here:
http://www.ovirt.org/Feature/VDSM_VM_Query_API/Measurements#Results
(An explanation of the tested methods is on the top of the page and a
description of the scenario in each section)

The benefit of introducing this verb would be a lowered volume of data
transferred over the management network which avoids congestion
on huge setups and can introduce an increased responsiveness for
communicating changes in state to the user. For example live migration
status. However even SLA related changes could be communicated faster
for things like QoS.


Preliminary Feature Proposal Wiki:
http://www.ovirt.org/Feature/VDSM_VM_Query_API




--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Info related to display port allocation

[Vinzenz Feenstra]

Hi,

I just want to give all of you an update on a recently created bug on VDSM.
Until recently we had 2 ports allocated for spice one for tls and one 
plain text.


We have now observed the behaviour on RHEL7 and I also did now on RHEL6 that
when all spice channels are marked as secure, only the tlsPort value is 
set in the

domain xml. VDSM will report the non-tls port as 'port=-1'

For us this is a good thing since we're saving one port in these cases 
and we're

encouraging users to use the ssl configuration anyway.

I just wanted to give you a heads up on this, in case anyone is assuming 
the 'port'
value reported by getAllVmStats or list full=True API calls would be 
returning any value

but -1.

--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] "Host.queryVms": A proposal for new a VDSM API verb

[Vinzenz Feenstra]

Hi,

This proposal is a follow up on a previous discussion about
optimizing the communication between VDSM and the ovirt-engine.


Currently the engine polls VDSM every 3 seconds with the `list`
verb to retrieve the status of all VMs. Every 5th time (every 15
seconds) it alternates to 'getAllVmStats' which gives more
information about the VMs.


Quite a big portion of the data, mainly the reply of getAllVmStats,
is only of interest if it actually changes so that the engine/back-end
can act on changes and update rows accordingly.

Now the problem is that there is quite a lot of data transferred
which is not really necessary and there is a 15 seconds delay on
communicating changes to certain VMs before the engine actually
can react on them and before these changes can be communicated
to the user.

As part of an improvement on this matter I'd like to propose a new API
verb for VDSM:

Host.queryVms(vmIds=[], fields=[], exclude=[], changedSince='')

This new verb is intended to eventually replace 2 currently
used verbs `list` and `getAllVmStats`. `queryVms` is supposed to
allow to request any data fields of a VM which can be requested through
the public API:

- Statistics
- Configuration
- Status information
- Guest OS Information

I have executed some tests and in those tested scenarios the new Verb
can result in an improvement of 75%-90% of data transferred and average
response body size depending on the scenario and usage.

The test results can be found here:
http://www.ovirt.org/Feature/VDSM_VM_Query_API/Measurements#Results
(An explanation of the tested methods is on the top of the page and a
description of the scenario in each section)

The benefit of introducing this verb would be a lowered volume of data
transferred over the management network which avoids congestion
on huge setups and can introduce an increased responsiveness for
communicating changes in state to the user. For example live migration
status. However even SLA related changes could be communicated faster
for things like QoS.


Preliminary Feature Proposal Wiki:
http://www.ovirt.org/Feature/VDSM_VM_Query_API

--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com



___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] ovirt-guest-agent

[Vinzenz Feenstra]

On 07/11/2014 09:02 AM, Sandro Bonazzola wrote:

Hi,
looking at http://jenkins.ovirt.org/view/All/
I see that for ovirt-guest-agent there's only the following job: 
http://jenkins.ovirt.org/view/All/job/ovirt-guest-agent_master_gerrit/
This means that ovirt-guest-agent is not built nightly neither for master nor 
for stable and it's not published neither in nightly snapshot nor in
official releases.

Yeah it never has been built nightly.

I see that ovirt-guest-agent is shipped within Fedora and EPEL: 
http://koji.fedoraproject.org/koji/packageinfo?packageID=15434
so I suppose official release are shipped there.

Yes

Do we need nightly builds?
It would be great if we would have nightly builds. Or at some trigger 
after merges, as the guest agent has not such a high volume of patches, 
nightly might be overkill, at least for now.

Also I see that http://www.ovirt.org/How_to_install_the_guest_agent_in_Fedora 
refers to obsolete layout / releases and the package is not shipped
within oVirt repo for above considerations and should be updated accordingly.
True, and now looking at it, I have to say that I am surprised that the 
guest agent builds aren't included in the ovirt releases anymore. 
Usually they were including the latest koji builds. (At least from my 
knowledge) that does not seem to be the case anymore. when looking at: 
http://resources.ovirt.org/releases/3.4/rpm/fc20/noarch/ for example.


--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Exception during VM recovery causes VMs not being properly recovered

[Vinzenz Feenstra]

Hi,

With the current master of VDSM after restarting VDSM (e.g. after 
upgrading) I noticed that the VMs were not properly initialized and in 
PAUSED state. Once checking the logs I found that the cause was here:


Thread-13::INFO::2014-07-10 
12:11:56,400::vm::2244::vm.Vm::(_startUnderlyingVm) 
vmId=`db614831-3b4b-4010-a989-f7a5ae6fa5d0`::Skipping errors on recovery

Traceback (most recent call last):
  File "/usr/share/vdsm/virt/vm.py", line 2228, in _startUnderlyingVm
self._run()
  File "/usr/share/vdsm/virt/vm.py", line 3312, in _run
self._domDependentInit()
  File "/usr/share/vdsm/virt/vm.py", line 3204, in _domDependentInit
self._syncVolumeChain(drive)
  File "/usr/share/vdsm/virt/vm.py", line 5686, in _syncVolumeChain
volumes = self._driveGetActualVolumeChain(drive)
  File "/usr/share/vdsm/virt/vm.py", line 5665, in 
_driveGetActualVolumeChain

sourceAttr = ('file', 'dev')[drive.blockDev]
TypeError: tuple indices must be integers, not NoneType

The reason here seems to be this:
Thread-13::DEBUG::2014-07-10 12:11:56,393::vm::1349::vm.Vm::(blockDev) 
vmId=`db614831-3b4b-4010-a989-f7a5ae6fa5d0`::Unable to determine if the 
path 
'/rhev/data-center/0002-0002-0002-0002-0002/41b6de4e-23da-481d-904d-9af24fc5f3ab/images/17206f99-38ab-45bc-ae9b-d36a66b00e4c/7b05de43-9d85-435f-8ae9-6ccde21548e4' 
is a block device

Traceback (most recent call last):
  File "/usr/share/vdsm/virt/vm.py", line 1346, in blockDev
self._blockDev = utils.isBlockDevice(self.path)
  File "/usr/lib64/python2.6/site-packages/vdsm/utils.py", line 99, in 
isBlockDevice

return stat.S_ISBLK(os.stat(path).st_mode)
OSError: [Errno 2] No such file or directory: 
'/rhev/data-center/0002-0002-0002-0002-0002/41b6de4e-23da-481d-904d-9af24fc5f3ab/images/17206f99-38ab-45bc-ae9b-d36a66b00e4c/7b05de43-9d85-435f-8ae9-6ccde21548e4'


I am running the host on RHEL6.5

Note: I just rebooted the host and started a few more VMs again and when 
I restart VDSM I get the same errors again.


--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Fwd: [ovirt-users] ovirt 3.5 TestDay Results

[Vinzenz Feenstra]

 Original Message 
Subject:[ovirt-users] ovirt 3.5 TestDay Results
Date:   Thu, 03 Jul 2014 12:36:07 +0200
From:   Vinzenz Feenstra 
Organization:   Red Hat
To: us...@ovirt.org List 



Hi,

I had to test *Bug 1080987* 
<https://bugzilla.redhat.com/show_bug.cgi?id=1080987> -OVIRT35 - [RFE] 
Support ethtool_opts functionality within oVirt


Installation of the engine went very smooth without a single issue, even 
adding a previously used host through the host deploy went smoothly and 
upgraded VDSM without any issues.

The feature worked as expected without any problems.

All in all I have to say that this time I had the best beta experience 
since I am working with oVirt.


Good Job guys! :-)

--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com



___
Users mailing list
us...@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] ioprocess on debian

[Vinzenz Feenstra]

On 06/25/2014 08:37 AM, Zhou Zheng Sheng wrote:

It seems Vinzenz has taken the most of work. I took a look at the
repository, it seems it contains only python-ioprocess and
ovirt-guest-agent. Would it be nice if we can host all the vdsm related
Debian packages in this repository? Then we can declare this is the more
official repository, and I can retire my luanchpad.net PPA. But if you
think my PPA is useful, I can update the packages in it.
I was struggling to figure out how to build for different Ubuntu 
versions and have modified packages for it, and since I need to use OBS 
for building openSUSE and SLE builds, I started using it also for Debian 
and Ubuntu versions.


I am not sure if we would like to retire your PPA that would be a 
question for Danken.
I think it'd be a great idea to have all those non Fedora/RHEL/CentOS 
packages in one place and OBS seems like a pretty good option for that 
because of the variety of target distributions it supports. Additionally 
it supports even signing your .deb files and having one repository key 
for all your repos.




on 2014/06/24 22:56, Vinzenz Feenstra wrote:

On 06/24/2014 02:53 PM, Dan Kenigsberg wrote:

On Tue, Jun 24, 2014 at 08:33:00AM -0400, Yeela Kaplan wrote:

Hi,
There's a new dependency for vdsm: python-ioprocess.
We also need to build ioprocess for debian.

Do you know who can be helping with that or what's the process?

ZhengSheng, maybe you can help us here?

Done already:

# echo
"debhttp://download.opensuse.org/repositories/home:/evilissimo:/deb/Debian_7.0/
./" >> /etc/apt/sources.list
# gpg -v -a
--keyserverhttp://download.opensuse.org/repositories/home:/evilissimo:/deb/Debian_7.0/Release.key
--recv-keys D5C7F7C373A1A299
# gpg --export --armor 73A1A299 | apt-key add -
# apt-get update
# apt-get install python-ioprocess

HTH,


___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel



--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] ioprocess on debian

[Vinzenz Feenstra]

On 06/24/2014 02:53 PM, Dan Kenigsberg wrote:

On Tue, Jun 24, 2014 at 08:33:00AM -0400, Yeela Kaplan wrote:

Hi,
There's a new dependency for vdsm: python-ioprocess.
We also need to build ioprocess for debian.

Do you know who can be helping with that or what's the process?

ZhengSheng, maybe you can help us here?

Done already:

# echo "debhttp://download.opensuse.org/repositories/home:/evilissimo:/deb/Debian_7.0/  
./" >> /etc/apt/sources.list
# gpg -v -a 
--keyserverhttp://download.opensuse.org/repositories/home:/evilissimo:/deb/Debian_7.0/Release.key
  --recv-keys D5C7F7C373A1A299
# gpg --export --armor 73A1A299 | apt-key add -
# apt-get update
# apt-get install python-ioprocess

HTH,


___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel



--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] ioprocess on debian

[Vinzenz Feenstra]

On 06/24/2014 03:34 PM, Sven Kieske wrote:

Is there any special reason why ovirt-infra is utilizing github.com
instead of ovirt.org just as the other ovirt devs?


Am 24.06.2014 15:20, schrieb Ewoud Kohl van Wijngaarden:

It was moved to https://github.com/ovirt-infra/ioprocess
I have started a build for debian here: 
https://build.opensuse.org/package/show/home:evilissimo:deb/python-ioprocess


--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ovirt-users] design flaw in ovirt

[Vinzenz Feenstra]

On 06/20/2014 02:52 PM, Sven Kieske wrote:


Am 20.06.2014 14:19, schrieb Dan Kenigsberg:

the host was not fenced, the vms where fenced.

here is a link to the documentation which should explain what I mean:

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.3/html/Administration_Guide/Virtual_Machine_Networks_and_Optional_Networks.html

Are you refering to the paragraph: "When a required network becomes
non-operational, the virtual machines running on the network are fenced
and migrated to another host. This is beneficial if you have machines
running mission critical workloads."?

yes

Isn't that section referring to HA VMs?



this is about a single host in a cluster - ovirt can't even fence
single hosts in a single cluster yet, see my other bug report for this:
https://bugzilla.redhat.com/show_bug.cgi?id=1054778

I could provide logs if they are really necessary, but I doubt they are.
This is documented behaviour, but it is poorly designed, as described
in the BZ.

Apparently, I am not familiar enough with Engine's fencing logic; logs
may help me understand the issue, for me they are necessary is this
case. In particular, I'd like to see with my own eyes whether the VMs
where explicitly destroyed by Engine. Migrating VMs to an operational
destination makes a lot of sense. Destroying a running VM in attempt
to recuperate of a host networking issue is extraordinary (and as such,
requires exraordinary evidence).

I might be able to attach some logs later.




--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Github Repositories

[Vinzenz Feenstra]

On 06/15/2014 03:40 PM, Eyal Edri wrote:

why not use gerrit.ovirt.org and mirror to github?

+1


- Original Message -

From: "Saggi Mizrahi" 
To: devel@ovirt.org
Sent: Sunday, June 15, 2014 1:29:34 PM
Subject: [ovirt-devel] Github Repositories

We are moving all ovirt stuff from my own user to
the newly created ovirt-infra group on github.

Update your git remotes!

https://github.com/ovirt-infra
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel


___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel



--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ioprocess] Karma please

[Vinzenz Feenstra]

On 05/05/2014 10:35 AM, Saggi Mizrahi wrote:

I'd appreciate some karma.
FYI: This update has reached the stable karma threshold and will be 
pushed to the stable updates repository


https://admin.fedoraproject.org/updates/ioprocess-0.3-1.fc20
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel



--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Fwd: Re: Mass bug: packages should not auto-enable systemd units

[Vinzenz Feenstra]

On Wed, Apr 30, 2014 at 11:32 PM, Dan Kenigsberg  wrote:

> On Wed, Apr 30, 2014 at 07:57:32PM +0200, Vinzenz Feenstra wrote:
> >
> > Due to some confusion around how alternatives worked, I screwed up the
> > list of packages here.  I've updated it below.  I'll give it a few
> > more days before filing the actual bugs.
> >
> > On Wed, Apr 23, 2014 at 4:59 PM, Andrew Lutomirski  wrote:
> > > Hi everyone-
> > >
> > > This is a notice in accordance with the mass bug filing procedure.
> > >
> > > A number of packages install systemd units and enable them
> > > automatically.  They should not.  Please update these packages to use
> the
> > > macroized scriptlet
> > > (https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd).
> > >
> > > If your package has an exception from FESCo permitting it to enable
> > > itself, please make sure that the service in question is listed in the
> > > appropriate preset file.
> > >
> > > There is a general exception described here:
> > >
> > > https://fedoraproject.org/wiki/Starting_services_by_default
> > >
> > > If your package falls under the general exception, then it is possible
> > > that no change is required.  Nevertheless, if you are relying on the
> > > exception, please make sure that your rpm scripts are sensible.  The
> > > exception is:
> > >
> > > In addition, any service which does not remain persistent on the
> > > system (aka, it "runs once then goes away"), does not listen to
> > > incoming connections during initialization, and does not require
> > > configuration to be functional may be enabled by default (but is not
> > > required to do so). An example of "runs once then goes away" service
> > > is iptables.
> > >
> > > Given that this issue can affect Fedora 20 users who install your
> > > package as a dependency, these bugs should be fixed in Fedora 20 and
> > > Rawhide.
> > >
> > > The tracker bug is here:
> > >
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1090684
> > >
> > > I created it early because three of the bugs are pre-existing.  Next
> > > week, I'll file bugs against the packages below.  If you fix your
> > > package in the mean time, please let me know.
> > >
> > > After three weeks, provenpackagers may step in and fix these issues.
> > >
>
> Vinzenz, I suppose that your main point is this part of the list
>
> > vdsm
>

Yes sorry for not being more specific, I forwarded that from on my mobile
and did think it's to important to forget about ;-)


> Douglas/Yaniv - can infra take care of this?
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Fwd: Re: Mass bug: packages should not auto-enable systemd units

[Vinzenz Feenstra]

-- Forwarded message --
From: "Andrew Lutomirski" 
Date: Apr 30, 2014 7:46 PM
Subject: Re: Mass bug: packages should not auto-enable systemd units
To: 
Cc:

Due to some confusion around how alternatives worked, I screwed up the
list of packages here.  I've updated it below.  I'll give it a few
more days before filing the actual bugs.

On Wed, Apr 23, 2014 at 4:59 PM, Andrew Lutomirski  wrote:
> Hi everyone-
>
> This is a notice in accordance with the mass bug filing procedure.
>
> A number of packages install systemd units and enable them
> automatically.  They should not.  Please update these packages to use the
> macroized scriptlet
> (https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd).
>
> If your package has an exception from FESCo permitting it to enable
> itself, please make sure that the service in question is listed in the
> appropriate preset file.
>
> There is a general exception described here:
>
> https://fedoraproject.org/wiki/Starting_services_by_default
>
> If your package falls under the general exception, then it is possible
> that no change is required.  Nevertheless, if you are relying on the
> exception, please make sure that your rpm scripts are sensible.  The
> exception is:
>
> In addition, any service which does not remain persistent on the
> system (aka, it "runs once then goes away"), does not listen to
> incoming connections during initialization, and does not require
> configuration to be functional may be enabled by default (but is not
> required to do so). An example of "runs once then goes away" service
> is iptables.
>
> Given that this issue can affect Fedora 20 users who install your
> package as a dependency, these bugs should be fixed in Fedora 20 and
> Rawhide.
>
> The tracker bug is here:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1090684
>
> I created it early because three of the bugs are pre-existing.  Next
> week, I'll file bugs against the packages below.  If you fix your
> package in the mean time, please let me know.
>
> After three weeks, provenpackagers may step in and fix these issues.
>

abrt
acpid
aeolus-audrey-agent
aeolus-configserver
audit
avahi
bluez
bootchart
cherokee
cloud-init
deltacloud-core
dmapd
dnssec-trigger
glusterfs
gnome-initial-setup
gpsd
ipmiutil
iptables
kexec-tools
libstoragemgmt
libvirt
lttng-tools
monit
NetworkManager
nfs-utils
nss-pam-ldapd
olpc-kbdshim
olpc-powerd
openct
pcsc-lite
qemu
qpid-cpp
rootfs-resize
rpcbind
sendmail
soundmodem
spacenavd
subscription-manager
supervisor
systemd
targetcli
util-linux
vdsm
xen

--Andy
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [vdsm] Missing numactl

[Vinzenz Feenstra]

Seems pretty much like it

On 04/28/2014 12:30 PM, Piotr Kliczewski wrote:

Hello,

I pulled the latest changes from master to test my code and during
getCaps I got:

Thread-14::ERROR::2014-04-28
12:11:44,394::__init__::484::jsonrpc.JsonRpcServer::(_serveRequest)
[Errno 2] No such file or directory
Traceback (most recent call last):
   File "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line
480, in _serveRequest
 res = method(**params)
   File "/usr/share/vdsm/Bridge.py", line 211, in _dynamicMethod
 result = fn(*methodArgs)
   File "/usr/share/vdsm/API.py", line 1184, in getCapabilities
 c = caps.get()
   File "/usr/share/vdsm/caps.py", line 459, in get
 caps['numaNodeDistance'] = _getNumaNodeDistance()
   File "/usr/lib64/python2.7/site-packages/vdsm/utils.py", line 1003,
in __call__
 value = self.func(*args)
   File "/usr/share/vdsm/caps.py", line 209, in _getNumaNodeDistance
 retcode, out, err = utils.execCmd(['numactl', '--hardware'])
   File "/usr/lib64/python2.7/site-packages/vdsm/utils.py", line 732, in execCmd
 deathSignal=deathSignal, childUmask=childUmask)
   File "/usr/lib64/python2.7/site-packages/cpopen/__init__.py", line
50, in __init__
 stderr=PIPE)
   File "/usr/lib64/python2.7/subprocess.py", line 711, in __init__
 errread, errwrite)
   File "/usr/lib64/python2.7/site-packages/cpopen/__init__.py", line
80, in _execute_child_v275
 self._childUmask)
OSError: [Errno 2] No such file or directory

When I installed numactl rpm getCaps work again.

Do we need to add this dependency to spec file?

Thanks,
Piotr
___
vdsm-devel mailing list
vdsm-de...@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel



--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel