[Spice-devel] [Users] ovirt VM custom properties

Wed Feb 22 08:00:46 PST 2012

On 02/22/2012 05:47 PM, Brown, Chris (GE Healthcare) wrote:
> Itamar/oVirt team,
> Just wanted to let you know the latest nightly build and latest
> RHEV/RHEL spice client/plugin has completely resolved mouse interaction
> issues with the following tested guests:
>
> Red Hat 7.3
> Red Hat 9
> Fedora core 1 - 14
> Fedora core 15
> Fedora core 16
> Red Hat Enterprise 3.x
> Red Hat Enterprise 4.x
> Red Hat Enterprise 5.x
> Red Hat Enterpise 6.x
> SLES 10
> SLES 11
> SLES 11 SP1
> OpenSUSE 11.1
> OpenSUSE 11.2
> OpenSUSE 11.3
> OpenSUSE 11.4
> Windows 2000 SP4
> Windows XP
> Windows Vista
> Windows Server 2003
> Windows Server 2003 R2
> Windows Server 2008
> Windows Server 2008 R2
> Solaris 10 Update9
> Solaris 11 Express
> Solaris 11
>
> I ran through the usual above suspect list of guests and am happy to
> report all is now well.
> A side note provided the appropriate NIC model is used with the
> respective guest type networking works fine in all of the above.
> Most importantly mouse interactivity works OOB now. Hats off to you guys
> awesome work!

so no need for the usb tablet hack/hook any more?

>
>
> A related question. It seems at the moment spice browser support is
> limited atm.
> Under windows only Internet Explorer can be used.
> Under linux only Firefox with the spice-xpi plugin can be used.
>
> When/or if can we expect to see spice interaction with ovirt/rhev guests
> supported under:
> Firefox + Windows
> Google Chrome + Windows
> Google Chrome + Linux
>
> These below are probably a real stretch but just for fun any thoughts on
> them?
> Mac OSX ?
> Solaris ?
> iPhone/iPad ?
> Android devices ?

ovirt shouldn't have an issue supporting any of the above.
cc-ing spice-devel for inputs on any of these being on the map.
for full ovirt integration, we'd need a browser wrapper (xpi/activex/etc.)
for launching from command line and setting the vm ticket via 
api/sdk/cli (or from any other spice wrapper) - just having spice client 
for them would be enough.

>
> - Chris
>
>> -----Original Message-----
>> From: Itamar Heim [mailto:iheim at redhat.com]
>> Sent: Wednesday, February 15, 2012 4:02 PM
>> To: Brown, Chris (GE Healthcare)
>> Subject: Re: [Users] ovirt VM custom properties
>>
>> On 02/15/2012 11:00 PM, Brown, Chris (GE Healthcare) wrote:
>>> I don't have an official env out yet for our developers to play with
>>> quite yet.
>>> What I can say is that they like what I have shown them and what this
>
>>> enables for them (This is huge for them).
>>>
>>> However I wanted to make sure I shook everything down first before
>>> tossing them even a sandbox env to play in.
>>> Thus if in the next few weeks there will be some changes to address
>> the
>>> issue I can buy some time here.
>>> I would rather have the root of the issue resolved or fixed
>>> officially upstream rather than maintaining something.
>>> I am assuming I should watch here: http://gerrit.ovirt.org for
>>> changes in that regard?
>>
>> ping me for status in a few weeks may be easier, but feel free to
>> monitor - i find it interesting to see all the changes going in
>>
>>>
>>> BTW many thanks for all your help Itamar!
>>>
>>> - Chris
>>>
>>> -----Original Message-----
>>> From: Itamar Heim [mailto:iheim at redhat.com]
>>> Sent: Wednesday, February 15, 2012 2:42 PM
>>> To: Brown, Chris (GE Healthcare)
>>> Subject: Re: [Users] ovirt VM custom properties
>>>
>>> On 02/15/2012 10:39 PM, Brown, Chris (GE Healthcare) wrote:
>>>> On the server that is running the engine I am using the packages
>> from:
>>>> http://www.ovirt.org/releases/nightly/fedora/16/
>>>> On the VM where I have the devel-env setup I checked out the engine
>>>> code
>>>> via: git clone http://gerrit.ovirt.org/p/ovirt-engine
>>>
>>> the code around user portal is changing on a daily basis, and custom
>>> properties should change as well in near future.
>>> i expect the changes will solve your problem.
>>> I suggest as an interim you consider the hook or admin alternatives?
>>>
>>>> - Chris
>>>>
>>>> -----Original Message-----
>>>> From: Itamar Heim [mailto:iheim at redhat.com]
>>>> Sent: Wednesday, February 15, 2012 2:35 PM
>>>> To: Brown, Chris (GE Healthcare)
>>>> Subject: Re: [Users] ovirt VM custom properties
>>>>
>>>> are you using the released version or the master?
>>>>
>>>> On 02/15/2012 10:29 PM, Brown, Chris (GE Healthcare) wrote:
>>>>> I was thinking about the vdsm hook scenario myself but I was stuck
>> in
>>>
>>>>> the thinking that hooks could only be invoked via custom properties
>
>>>>> or
>>>>
>>>>> before/after vdsm invocation.
>>>>> Thank you for the heads up on that as that could definitely work.
>>>>> That
>>>>
>>>>> gives me an option down that route for now as well.
>>>>>
>>>>> The other thought I had was to modify the existing GWT code for the
>
>>>>> user portal.
>>>>> I would just want to recompile/build an rpm for just the user
>>>>> portal which seems to come from
>>>>> ovirt-engine-userportal-<version>.fc16.x86_64
>>>>> I think I found where the code would need to be altered.
>>>>>
>>>>> *Note in advance Hardware/OS guy attempting to code* Please excuse
>>>>> poor form ;)
>>>>>
>>>>> -->
>>>>>
>> ovirt-engine/frontend/webadmin/modules/userportal/src/main/java/org/o
>>>>> v ir t/engine/ui/userportal/client/modalpanels
>>>>> -->      file: NewVmModalPanel.java
>>>>> -->      lines 76 - 84
>>>>> -->      add: TabButton customPropertiesTabButton;  lines 100 - 108
>>>>> -->      add: customPropertiesTabButton = new TabButton("Custom
>>>>> -->    Properties",
>>>>> new CustomPropertiesTabPane());
>>>>> -->      lines 622 - 632
>>>>> -->      GWT code to constuct CustomPropertiesTabPane is already
>> there.
>>>>>
>>>>> This should be it unless there is something else I missed.
>>>>>      From there I think I would just need to rebuild the
>>>>> ovirt-engine-userportal RPM with just those changes.
>>>>>
>>>>> I have a FC16 build env set up per:
>>>>> http://www.ovirt.org/wiki/Building_Ovirt_Engine
>>>>> Any helpful hints to just rebuild only the userportal with just
>> those
>>>
>>>>> changes?
>>>>> Build output should ultimately be:
>>>>> ovirt-engine-userportal-<version>.fc16.x86_64.rpm
>>>>> In that manner I can rpm -U ovirt-engine-userportal on the target
>>>>> system.
>>>>>
>>>>> - Chris
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Itamar Heim [mailto:iheim at redhat.com]
>>>>> Sent: Wednesday, February 15, 2012 1:46 PM
>>>>> To: Brown, Chris (GE Healthcare)
>>>>> Cc: Andrew Cathrow; users; lpeer>>      Livnat Peer
>>>>> Subject: Re: [Users] ovirt VM custom properties
>>>>>
>>>>> On 02/15/2012 05:34 PM, Brown, Chris (GE Healthcare) wrote:
>>>>>> I assume the code for the Admin portal and PUP are shared (w/o
>>>>>> looking) in regards to editing VM settings.
>>>>>> Thus if I understand what you are saying, is that given proper
>>>>>> permissions a power user would be able to view/edit the "custom
>>>>>> properties".
>>>>>> Any thoughts on a way now short of code changes to work around
>>>>>> this (this is really a killer for our use cases)?
>>>>>> An initial thought I had was to develop something perhaps a custom
>
>>>>>> page (for now) leveraging the API to allow such changes.
>>>>>
>>>>> you may have noticed the API allows this, but is limited to
>> admins...
>>>>> you could create a role of admin with limited permissions just like
>> a
>>>
>>>>> power user role, and give it to these users.
>>>>> only different from power user portal would be look and feel and
>>>>> the fact they could see VMs of others (and the rest of the entities
>
>>>>> in the
>>>>
>>>>> system).
>>>>> my view is the solution to this is to add a feature of permissions
>> to
>>>
>>>>> custom properties, which requires making them entities, rather than
>> a
>>>
>>>>> string, etc.
>>>>>
>>>>>>
>>>>>> Ultimately I see three core solutions to this issue:
>>>>>> - The spice input/mouse interaction issues are resolved for all
>>>>>> guests
>>>>>
>>>>>> (old and new)
>>>>>> - The UI allows for changes to the type of input device
>>>>>> - Power users also have access to custom properties and can just
>> use
>>>
>>>>>> the vdsm hook instead.
>>>>>
>>>>> as a temporary solution, would it hurt your new guests if you make
>>>>> the
>>>>
>>>>> hook always enable the device? any other field in the vm you could
>>>>> base the decision on by the hook as an interim solution (it can go
>> as
>>>
>>>>> hacky as vmname has X in it - hooks don't have to be based on
>>>>> custom properties).
>>>>>
>>>>>>
>>>>>> Let me know your thoughts.
>>>>
>>>
>>
>