Re: [Users] ovirt VM custom properties
by Brown, Chris (GE Healthcare)
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!
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 ?
- Chris
> -----Original Message-----
> From: Itamar Heim [mailto:iheim@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@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@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@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.
>>>
>>
>
