I can confirm with the listed guests tablet was no longer needed. - Chris -----Original Message----- From: Itamar Heim [mailto:ih...@redhat.com] Sent: Wednesday, February 22, 2012 10:01 AM To: Brown, Chris (GE Healthcare) Cc: acath...@redhat.com; us...@ovirt.org; lp...@redhat.com; spice-devel@lists.freedesktop.org Subject: Re: [Users] ovirt VM custom properties
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:ih...@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:ih...@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:ih...@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:ih...@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. >>>> >>> >> > _______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
