From Christopher.Brown at med.ge.com Wed Feb 1 16:16:38 2012 Content-Type: multipart/mixed; boundary="===============8426569586846961938==" MIME-Version: 1.0 From: Brown, Chris (GE Healthcare) To: users at ovirt.org Subject: [Users] ovirt VM custom properties Date: Wed, 01 Feb 2012 16:16:35 -0500 Message-ID: --===============8426569586846961938== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable This is a multi-part message in MIME format. ------_=3D_NextPart_001_01CCE126.C779DB35 Content-Type: text/plain; charset=3D"us-ascii" Content-Transfer-Encoding: quoted-printable In an effort to work around the mouse issues with spice consoles and certain guests I had an idea for the time being. My thought process is to leverage custom properties to enable usb-tablet support on said guests. --> (http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Virtualization/3.0 /html/Administration_Guide/VDSM_Hooks.html) =3D20 I perused the available documentation and it appears that these custom properties are ultimately fed into the generated libvirt domain xml. Thus sifting through --> http://libvirt.org/formatdomain.html#elementsInput we can pass in: =3D20 The issue I am hung up on is that since this contains multi-level elements can this even be specified as a custom property? If so can one of the ovirt developers provide an example on how to go about it? =3D20 - Chris ------_=3D_NextPart_001_01CCE126.C779DB35 Content-Type: text/html; charset=3D"us-ascii" Content-Transfer-Encoding: quoted-printable

In an = =3D effort to work around the mouse issues with spice consoles and certain =3D guests I had an idea for the time being.

My thought process is to leverage custom properties to = =3D enable usb-tablet support on said guests.

--> (http://docs.redhat.com/= =3D docs/en-US/Red_Hat_Enterprise_Virtualization/3.0/html/Administration_Guid= =3D e/VDSM_Hooks.html)

 

I perused = =3D the available documentation and it appears that these custom properties =3D are ultimately fed into the generated libvirt domain =3D xml.

Thus sifting through --> http://libvir= =3D t.org/formatdomain.html#elementsInput we can pass =3D in:

<devices>

    <input type=3D3D'tablet' =3D bus=3D3D'usb'/ id=3D3D'input0'>

</devices>

 

The issue I= =3D am hung up on is that since this contains multi-level elements can this =3D even be specified as a custom property?

If so can one of the ovirt developers provide an =3D example on how to go about it?

 

- =3D Chris

------_=3D_NextPart_001_01CCE126.C779DB35-- --===============8426569586846961938== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" VGhpcyBpcyBhIG11bHRpLXBhcnQgbWVzc2FnZSBpbiBNSU1FIGZvcm1hdC4KCi0tLS0tLV89X05l eHRQYXJ0XzAwMV8wMUNDRTEyNi5DNzc5REIzNQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW47Cglj aGFyc2V0PSJ1cy1hc2NpaSIKQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogcXVvdGVkLXByaW50 YWJsZQoKSW4gYW4gZWZmb3J0IHRvIHdvcmsgYXJvdW5kIHRoZSBtb3VzZSBpc3N1ZXMgd2l0aCBz cGljZSBjb25zb2xlcyBhbmQKY2VydGFpbiBndWVzdHMgSSBoYWQgYW4gaWRlYSBmb3IgdGhlIHRp bWUgYmVpbmcuCgpNeSB0aG91Z2h0IHByb2Nlc3MgaXMgdG8gbGV2ZXJhZ2UgY3VzdG9tIHByb3Bl cnRpZXMgdG8gZW5hYmxlIHVzYi10YWJsZXQKc3VwcG9ydCBvbiBzYWlkIGd1ZXN0cy4KCi0tPgoo aHR0cDovL2RvY3MucmVkaGF0LmNvbS9kb2NzL2VuLVVTL1JlZF9IYXRfRW50ZXJwcmlzZV9WaXJ0 dWFsaXphdGlvbi8zLjAKL2h0bWwvQWRtaW5pc3RyYXRpb25fR3VpZGUvVkRTTV9Ib29rcy5odG1s KQoKPTIwCgpJIHBlcnVzZWQgdGhlIGF2YWlsYWJsZSBkb2N1bWVudGF0aW9uIGFuZCBpdCBhcHBl YXJzIHRoYXQgdGhlc2UgY3VzdG9tCnByb3BlcnRpZXMgYXJlIHVsdGltYXRlbHkgZmVkIGludG8g dGhlIGdlbmVyYXRlZCBsaWJ2aXJ0IGRvbWFpbiB4bWwuCgpUaHVzIHNpZnRpbmcgdGhyb3VnaCAt LT4KaHR0cDovL2xpYnZpcnQub3JnL2Zvcm1hdGRvbWFpbi5odG1sI2VsZW1lbnRzSW5wdXQgd2Ug Y2FuIHBhc3MgaW46Cgo8ZGV2aWNlcz4KCiAgICA8aW5wdXQgdHlwZT0zRCd0YWJsZXQnIGJ1cz0z RCd1c2InLyBpZD0zRCdpbnB1dDAnPgoKPC9kZXZpY2VzPgoKPTIwCgpUaGUgaXNzdWUgSSBhbSBo dW5nIHVwIG9uIGlzIHRoYXQgc2luY2UgdGhpcyBjb250YWlucyBtdWx0aS1sZXZlbAplbGVtZW50 cyBjYW4gdGhpcyBldmVuIGJlIHNwZWNpZmllZCBhcyBhIGN1c3RvbSBwcm9wZXJ0eT8KCklmIHNv IGNhbiBvbmUgb2YgdGhlIG92aXJ0IGRldmVsb3BlcnMgcHJvdmlkZSBhbiBleGFtcGxlIG9uIGhv dyB0byBnbwphYm91dCBpdD8KCj0yMAoKLSBDaHJpcwoKCi0tLS0tLV89X05leHRQYXJ0XzAwMV8w MUNDRTEyNi5DNzc5REIzNQpDb250ZW50LVR5cGU6IHRleHQvaHRtbDsKCWNoYXJzZXQ9InVzLWFz Y2lpIgpDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiBxdW90ZWQtcHJpbnRhYmxlCgo8aHRtbCB4 bWxuczp2PTNEInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206dm1sIiA9CnhtbG5zOm89M0QidXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiA9CnhtbG5zOnc9M0QidXJuOnNj aGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgPQp4bWxuczptPTNEImh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgPQp4bWxucz0zRCJodHRwOi8v d3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj48aGVhZD48bWV0YSA9Cmh0dHAtZXF1aXY9M0RDb250 ZW50LVR5cGUgY29udGVudD0zRCJ0ZXh0L2h0bWw7ID0KY2hhcnNldD0zRHVzLWFzY2lpIj48bWV0 YSBuYW1lPTNER2VuZXJhdG9yIGNvbnRlbnQ9M0QiTWljcm9zb2Z0IFdvcmQgMTIgPQooZmlsdGVy ZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0KLyogRm9udCBEZWZpbml0aW9ucyAqLwpAZm9udC1mYWNl Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7CglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30KQGZvbnQtZmFjZQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7CglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9Ci8qIFN0eWxlIERlZmluaXRpb25zICovCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwKCXttYXJnaW46MGluOwoJbWFyZ2luLWJvdHRvbTouMDAw MXB0OwoJZm9udC1zaXplOjExLjBwdDsKCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7fQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJ Y29sb3I6Ymx1ZTsKCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQKCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7Cgljb2xvcjpwdXJw bGU7Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30Kc3Bhbi5FbWFpbFN0eWxlMTcKCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOwoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsKCWNvbG9yOndpbmRvd3RleHQ7fQouTXNvQ2hwRGVmYXVsdAoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5O30KQHBhZ2UgV29yZFNlY3Rpb24xCgl7c2l6ZTo4LjVpbiAxMS4waW47 CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQpkaXYuV29yZFNlY3Rpb24xCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPgo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PTNEImVkaXQiIHNwaWRtYXg9M0QiMTAyNiIgLz4KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PTNE ImVkaXQiPgo8bzppZG1hcCB2OmV4dD0zRCJlZGl0IiBkYXRhPTNEIjEiIC8+CjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz0zREVOLVVTIGxpbms9M0Ri bHVlID0Kdmxpbms9M0RwdXJwbGU+PGRpdiBjbGFzcz0zRFdvcmRTZWN0aW9uMT48cCBjbGFzcz0z RE1zb05vcm1hbD5JbiBhbiA9CmVmZm9ydCB0byB3b3JrIGFyb3VuZCB0aGUgbW91c2UgaXNzdWVz IHdpdGggc3BpY2UgY29uc29sZXMgYW5kIGNlcnRhaW4gPQpndWVzdHMgSSBoYWQgYW4gaWRlYSBm b3IgdGhlIHRpbWUgYmVpbmcuPG86cD48L286cD48L3A+PHAgPQpjbGFzcz0zRE1zb05vcm1hbD5N eSB0aG91Z2h0IHByb2Nlc3MgaXMgdG8gbGV2ZXJhZ2UgY3VzdG9tIHByb3BlcnRpZXMgdG8gPQpl bmFibGUgdXNiLXRhYmxldCBzdXBwb3J0IG9uIHNhaWQgZ3Vlc3RzLjxvOnA+PC9vOnA+PC9wPjxw ID0KY2xhc3M9M0RNc29Ob3JtYWw+LS0mZ3Q7ICg8YSA9CmhyZWY9M0QiaHR0cDovL2RvY3MucmVk aGF0LmNvbS9kb2NzL2VuLVVTL1JlZF9IYXRfRW50ZXJwcmlzZV9WaXJ0dWFsaXphdGk9Cm9uLzMu MC9odG1sL0FkbWluaXN0cmF0aW9uX0d1aWRlL1ZEU01fSG9va3MuaHRtbCI+aHR0cDovL2RvY3Mu cmVkaGF0LmNvbS89CmRvY3MvZW4tVVMvUmVkX0hhdF9FbnRlcnByaXNlX1ZpcnR1YWxpemF0aW9u LzMuMC9odG1sL0FkbWluaXN0cmF0aW9uX0d1aWQ9CmUvVkRTTV9Ib29rcy5odG1sPC9hPik8bzpw PjwvbzpwPjwvcD48cCA9CmNsYXNzPTNETXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxw IGNsYXNzPTNETXNvTm9ybWFsPkkgcGVydXNlZCA9CnRoZSBhdmFpbGFibGUgZG9jdW1lbnRhdGlv biBhbmQgaXQgYXBwZWFycyB0aGF0IHRoZXNlIGN1c3RvbSBwcm9wZXJ0aWVzID0KYXJlIHVsdGlt YXRlbHkgZmVkIGludG8gdGhlIGdlbmVyYXRlZCBsaWJ2aXJ0IGRvbWFpbiA9CnhtbC48bzpwPjwv bzpwPjwvcD48cCBjbGFzcz0zRE1zb05vcm1hbD5UaHVzIHNpZnRpbmcgdGhyb3VnaCAtLSZndDsg PGEgPQpocmVmPTNEImh0dHA6Ly9saWJ2aXJ0Lm9yZy9mb3JtYXRkb21haW4uaHRtbCNlbGVtZW50 c0lucHV0Ij5odHRwOi8vbGlidmlyPQp0Lm9yZy9mb3JtYXRkb21haW4uaHRtbCNlbGVtZW50c0lu cHV0PC9hPiB3ZSBjYW4gcGFzcyA9CmluOjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPTNETXNvTm9y bWFsPiZsdDtkZXZpY2VzJmd0OzxvOnA+PC9vOnA+PC9wPjxwID0KY2xhc3M9M0RNc29Ob3JtYWw+ Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtpbnB1dCB0eXBlPTNEJ3RhYmxldCcgPQpidXM9M0QndXNi Jy8gaWQ9M0QnaW5wdXQwJyZndDs8bzpwPjwvbzpwPjwvcD48cCA9CmNsYXNzPTNETXNvTm9ybWFs PiZsdDsvZGV2aWNlcyZndDs8bzpwPjwvbzpwPjwvcD48cCA9CmNsYXNzPTNETXNvTm9ybWFsPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPTNETXNvTm9ybWFsPlRoZSBpc3N1ZSBJID0KYW0g aHVuZyB1cCBvbiBpcyB0aGF0IHNpbmNlIHRoaXMgY29udGFpbnMgbXVsdGktbGV2ZWwgZWxlbWVu dHMgY2FuIHRoaXMgPQpldmVuIGJlIHNwZWNpZmllZCBhcyBhIGN1c3RvbSBwcm9wZXJ0eT88bzpw PjwvbzpwPjwvcD48cCA9CmNsYXNzPTNETXNvTm9ybWFsPklmIHNvIGNhbiBvbmUgb2YgdGhlIG92 aXJ0IGRldmVsb3BlcnMgcHJvdmlkZSBhbiA9CmV4YW1wbGUgb24gaG93IHRvIGdvIGFib3V0IGl0 PzxvOnA+PC9vOnA+PC9wPjxwID0KY2xhc3M9M0RNc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48 L3A+PHAgY2xhc3M9M0RNc29Ob3JtYWw+LSA9CkNocmlzPG86cD48L286cD48L3A+PC9kaXY+PC9i b2R5PjwvaHRtbD4KLS0tLS0tXz1fTmV4dFBhcnRfMDAxXzAxQ0NFMTI2LkM3NzlEQjM1LS0K --===============8426569586846961938==-- From acathrow at redhat.com Wed Feb 1 16:28:56 2012 Content-Type: multipart/mixed; boundary="===============2581593457238770386==" MIME-Version: 1.0 From: Andrew Cathrow To: users at ovirt.org Subject: Re: [Users] ovirt VM custom properties Date: Wed, 01 Feb 2012 16:28:54 -0500 Message-ID: <08ac52b3-192e-495d-a170-cee84e2c7b8a@zmail07.collab.prod.int.phx2.redhat.com> In-Reply-To: C63EAE2B896C144EA58784406C423B991829A4@CINMLVEM37.e2k.ad.ge.com --===============2581593457238770386== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Chris Brown (GE Healthcare)" > To: users(a)ovirt.org > Sent: Wednesday, February 1, 2012 4:16:35 PM > Subject: [Users] ovirt VM custom properties > = > = > = > = > = > In an effort to work around the mouse issues with spice consoles and > certain guests I had an idea for the time being. > = > My thought process is to leverage custom properties to enable > usb-tablet support on said guests. > = > --> ( > http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Virtualization/3.0/h= tml/Administration_Guide/VDSM_Hooks.html > ) > = > = > = > I perused the available documentation and it appears that these > custom properties are ultimately fed into the generated libvirt > domain xml. > = > Thus sifting through --> > http://libvirt.org/formatdomain.html#elementsInput we can pass in: > = > > = > > = > > = > = > = > The issue I am hung up on is that since this contains multi-level > elements can this even be specified as a custom property? The custom property wouldn't contain the XML it would contain data you want= to pass to a hook script eg. addTablet=3Dtrue, then it's down to your hook script to add the appropr= iate element to the device node in the libvirt xml. There's a number of good examples in the vdsm git repo. > = > If so can one of the ovirt developers provide an example on how to go > about it? > = > = > = > - Chris > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users >=20 --===============2581593457238770386==-- From Christopher.Brown at med.ge.com Wed Feb 1 17:20:12 2012 Content-Type: multipart/mixed; boundary="===============3881863982019553520==" MIME-Version: 1.0 From: Brown, Chris (GE Healthcare) To: users at ovirt.org Subject: Re: [Users] ovirt VM custom properties Date: Wed, 01 Feb 2012 17:20:09 -0500 Message-ID: In-Reply-To: 08ac52b3-192e-495d-a170-cee84e2c7b8a@zmail07.collab.prod.int.phx2.redhat.com --===============3881863982019553520== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Thanks Andy, I was afraid that might be case ;) I'll check out the examples and see what I can come up with. - Chris -----Original Message----- From: Andrew Cathrow [mailto:acathrow(a)redhat.com] = Sent: Wednesday, February 01, 2012 3:29 PM To: Brown, Chris (GE Healthcare) Cc: users(a)ovirt.org Subject: Re: [Users] ovirt VM custom properties ----- Original Message ----- > From: "Chris Brown (GE Healthcare)" > To: users(a)ovirt.org > Sent: Wednesday, February 1, 2012 4:16:35 PM > Subject: [Users] ovirt VM custom properties > = > = > = > = > = > In an effort to work around the mouse issues with spice consoles and = > certain guests I had an idea for the time being. > = > My thought process is to leverage custom properties to enable = > usb-tablet support on said guests. > = > --> ( > http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Virtualization/3. > 0/html/Administration_Guide/VDSM_Hooks.html > ) > = > = > = > I perused the available documentation and it appears that these custom = > properties are ultimately fed into the generated libvirt domain xml. > = > Thus sifting through --> > http://libvirt.org/formatdomain.html#elementsInput we can pass in: > = > > = > > = > > = > = > = > The issue I am hung up on is that since this contains multi-level = > elements can this even be specified as a custom property? The custom property wouldn't contain the XML it would contain data you want= to pass to a hook script eg. addTablet=3Dtrue, then it's down to your hook= script to add the appropriate element to the device node in the libvirt xm= l. There's a number of good examples in the vdsm git repo. > = > If so can one of the ovirt developers provide an example on how to go = > about it? > = > = > = > - Chris > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users >=20 --===============3881863982019553520==-- From acathrow at redhat.com Wed Feb 1 18:00:36 2012 Content-Type: multipart/mixed; boundary="===============2997730715878873401==" MIME-Version: 1.0 From: Andrew Cathrow To: users at ovirt.org Subject: Re: [Users] ovirt VM custom properties Date: Wed, 01 Feb 2012 18:00:35 -0500 Message-ID: <810784ca-dc0d-4f96-98c3-ff191fe2cf3e@zmail07.collab.prod.int.phx2.redhat.com> In-Reply-To: C63EAE2B896C144EA58784406C423B991829A5@CINMLVEM37.e2k.ad.ge.com --===============2997730715878873401== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Not tested, no error handling (eg. does the element exist already) but ... #!/usr/bin/python import os import sys import hooking import traceback if os.environ.has_key('usbtablet'): try: sys.stderr.write('tablet: adding usbtablet support\n') domxml =3D hooking.read_domxml() devices =3D domxml.getElementsByTagName('devices')[0] tablet =3D domxml.createElement('input') tablet.setAttribute('bus', 'usb') devices.appendChild(tablet) hooking.write_domxml(domxml) except: sys.stderr.write('tablet: [unexpected error]: %s\n' % traceback.for= mat_exc()) sys.exit(2) ----- Original Message ----- > From: "Chris Brown (GE Healthcare)" > To: "Andrew Cathrow" > Cc: users(a)ovirt.org > Sent: Wednesday, February 1, 2012 5:20:09 PM > Subject: RE: [Users] ovirt VM custom properties > = > Thanks Andy, > I was afraid that might be case ;) > I'll check out the examples and see what I can come up with. > - Chris > = > -----Original Message----- > From: Andrew Cathrow [mailto:acathrow(a)redhat.com] > Sent: Wednesday, February 01, 2012 3:29 PM > To: Brown, Chris (GE Healthcare) > Cc: users(a)ovirt.org > Subject: Re: [Users] ovirt VM custom properties > = > = > = > ----- Original Message ----- > > From: "Chris Brown (GE Healthcare)" > > To: users(a)ovirt.org > > Sent: Wednesday, February 1, 2012 4:16:35 PM > > Subject: [Users] ovirt VM custom properties > > = > > = > > = > > = > > = > > In an effort to work around the mouse issues with spice consoles > > and > > certain guests I had an idea for the time being. > > = > > My thought process is to leverage custom properties to enable > > usb-tablet support on said guests. > > = > > --> ( > > http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Virtualization/3. > > 0/html/Administration_Guide/VDSM_Hooks.html > > ) > > = > > = > > = > > I perused the available documentation and it appears that these > > custom > > properties are ultimately fed into the generated libvirt domain > > xml. > > = > > Thus sifting through --> > > http://libvirt.org/formatdomain.html#elementsInput we can pass in: > > = > > > > = > > > > = > > > > = > > = > > = > > The issue I am hung up on is that since this contains multi-level > > elements can this even be specified as a custom property? > = > The custom property wouldn't contain the XML it would contain data > you want to pass to a hook script eg. addTablet=3Dtrue, then it's down > to your hook script to add the appropriate element to the device > node in the libvirt xml. > There's a number of good examples in the vdsm git repo. > = > = > > = > > If so can one of the ovirt developers provide an example on how to > > go > > about it? > = > = > > = > > = > > = > > - Chris > > _______________________________________________ > > Users mailing list > > Users(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/users > > = >=20 --===============2997730715878873401==-- From Christopher.Brown at med.ge.com Thu Feb 2 15:51:55 2012 Content-Type: multipart/mixed; boundary="===============4947870929627448031==" MIME-Version: 1.0 From: Brown, Chris (GE Healthcare) To: users at ovirt.org Subject: Re: [Users] ovirt VM custom properties Date: Thu, 02 Feb 2012 15:51:52 -0500 Message-ID: In-Reply-To: 810784ca-dc0d-4f96-98c3-ff191fe2cf3e@zmail07.collab.prod.int.phx2.redhat.com --===============4947870929627448031== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Andy, Many thanks! That got me going the right direction. I did some extensive testing of with this. Here are the changes I made but = basically what I do is: - If the user specifies a custom property of usbtablet, just rewrite the in= put tag with: This will of course rewrite the existing But in this case we know we desire usbtablet so just re-write with what we = want. For non problematic guests or guests to which the agent can be installed we= simply remove the custom property after the agent is added. For legacy guests all the way back to redhat 7.3 and win98/win2k etc we can= simply use usbtablet for now. Once the issues with the mouse input issues with the aforementioned guest t= ypes are resolved we again won't need this (hopefully). - Chris = #!/usr/bin/python # VDSM Hook Script for RHEV/oVirt # Enables USB tablet support for a guest # use rhevm-config for RHEV or engine-config for oVirt to add UserDefinedVM= Properties # EX: rhevm-config -s UserDefinedVMProperties=3D'usbtablet=3D^(true|false)$= ' --cver=3D3.0 # Remember to restart jboss # Use VM custom property usbtablet=3Dtrue in vm configuration (Custom Prope= rties) import os import sys import hooking import traceback if os.environ.has_key('usbtablet'): try: sys.stderr.write('usbtablet requested\n') domxml =3D hooking.read_domxml() devices =3D domxml.getElementsByTagName('devices')[0] inputdev =3D domxml.getElementsByTagName('input')[0] inputdev.setAttribute('bus', 'usb') inputdev.setAttribute('type', 'tablet') inputdev.setAttribute('id', 'input0') hooking.write_domxml(domxml) sys.stderr.write('usbtablet support enabled\n') except: sys.stderr.write('usbtablet: [unexpected error]: %s\n' % traceback.= format_exc()) sys.exit(2) -----Original Message----- From: Andrew Cathrow [mailto:acathrow(a)redhat.com] = Sent: Wednesday, February 01, 2012 5:01 PM To: Brown, Chris (GE Healthcare) Cc: users(a)ovirt.org Subject: Re: [Users] ovirt VM custom properties Not tested, no error handling (eg. does the element exist already) but ... #!/usr/bin/python import os import sys import hooking import traceback if os.environ.has_key('usbtablet'): try: sys.stderr.write('tablet: adding usbtablet support\n') domxml =3D hooking.read_domxml() devices =3D domxml.getElementsByTagName('devices')[0] tablet =3D domxml.createElement('input') tablet.setAttribute('bus', 'usb') devices.appendChild(tablet) hooking.write_domxml(domxml) except: sys.stderr.write('tablet: [unexpected error]: %s\n' % traceback.for= mat_exc()) sys.exit(2) ----- Original Message ----- > From: "Chris Brown (GE Healthcare)" > To: "Andrew Cathrow" > Cc: users(a)ovirt.org > Sent: Wednesday, February 1, 2012 5:20:09 PM > Subject: RE: [Users] ovirt VM custom properties > = > Thanks Andy, > I was afraid that might be case ;) > I'll check out the examples and see what I can come up with. > - Chris > = > -----Original Message----- > From: Andrew Cathrow [mailto:acathrow(a)redhat.com] > Sent: Wednesday, February 01, 2012 3:29 PM > To: Brown, Chris (GE Healthcare) > Cc: users(a)ovirt.org > Subject: Re: [Users] ovirt VM custom properties > = > = > = > ----- Original Message ----- > > From: "Chris Brown (GE Healthcare)" > > To: users(a)ovirt.org > > Sent: Wednesday, February 1, 2012 4:16:35 PM > > Subject: [Users] ovirt VM custom properties > > = > > = > > = > > = > > = > > In an effort to work around the mouse issues with spice consoles and = > > certain guests I had an idea for the time being. > > = > > My thought process is to leverage custom properties to enable = > > usb-tablet support on said guests. > > = > > --> ( > > http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Virtualization/3. > > 0/html/Administration_Guide/VDSM_Hooks.html > > ) > > = > > = > > = > > I perused the available documentation and it appears that these = > > custom properties are ultimately fed into the generated libvirt = > > domain xml. > > = > > Thus sifting through --> > > http://libvirt.org/formatdomain.html#elementsInput we can pass in: > > = > > > > = > > > > = > > > > = > > = > > = > > The issue I am hung up on is that since this contains multi-level = > > elements can this even be specified as a custom property? > = > The custom property wouldn't contain the XML it would contain data you = > want to pass to a hook script eg. addTablet=3Dtrue, then it's down to = > your hook script to add the appropriate element to the device node in = > the libvirt xml. > There's a number of good examples in the vdsm git repo. > = > = > > = > > If so can one of the ovirt developers provide an example on how to = > > go about it? > = > = > > = > > = > > = > > - Chris > > _______________________________________________ > > Users mailing list > > Users(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/users > > = >=20 --===============4947870929627448031==-- From iheim at redhat.com Fri Feb 3 05:44:47 2012 Content-Type: multipart/mixed; boundary="===============0124309700967686446==" MIME-Version: 1.0 From: Itamar Heim To: users at ovirt.org Subject: Re: [Users] ovirt VM custom properties Date: Fri, 03 Feb 2012 12:44:40 +0200 Message-ID: <4F2BBA98.6030201@redhat.com> In-Reply-To: C63EAE2B896C144EA58784406C423B991829AC@CINMLVEM37.e2k.ad.ge.com --===============0124309700967686446== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 02/02/2012 10:51 PM, Brown, Chris (GE Healthcare) wrote: > Andy, > Many thanks! > That got me going the right direction. > I did some extensive testing of with this. Here are the changes I made bu= t basically what I do is: > - If the user specifies a custom property of usbtablet, just rewrite the = input tag with: > > This will of course rewrite the existing > But in this case we know we desire usbtablet so just re-write with what w= e want. > For non problematic guests or guests to which the agent can be installed = we simply remove the custom property after the agent is added. > For legacy guests all the way back to redhat 7.3 and win98/win2k etc we c= an simply use usbtablet for now. > Once the issues with the mouse input issues with the aforementioned guest= types are resolved we again won't need this (hopefully). how about formalizing this into a patch for the vdsm custom hooks library? > > - Chris > > #!/usr/bin/python > # VDSM Hook Script for RHEV/oVirt > # Enables USB tablet support for a guest > # use rhevm-config for RHEV or engine-config for oVirt to add UserDefined= VMProperties > # EX: rhevm-config -s UserDefinedVMProperties=3D'usbtablet=3D^(true|false= )$' --cver=3D3.0 > # Remember to restart jboss > # Use VM custom property usbtablet=3Dtrue in vm configuration (Custom Pro= perties) > > import os > import sys > import hooking > import traceback > > > if os.environ.has_key('usbtablet'): > try: > sys.stderr.write('usbtablet requested\n') > domxml =3D hooking.read_domxml() > > devices =3D domxml.getElementsByTagName('devices')[0] > inputdev =3D domxml.getElementsByTagName('input')[0] > > inputdev.setAttribute('bus', 'usb') > inputdev.setAttribute('type', 'tablet') > inputdev.setAttribute('id', 'input0') > hooking.write_domxml(domxml) > sys.stderr.write('usbtablet support enabled\n') > > except: > sys.stderr.write('usbtablet: [unexpected error]: %s\n' % traceba= ck.format_exc()) > sys.exit(2) > > > -----Original Message----- > From: Andrew Cathrow [mailto:acathrow(a)redhat.com] > Sent: Wednesday, February 01, 2012 5:01 PM > To: Brown, Chris (GE Healthcare) > Cc: users(a)ovirt.org > Subject: Re: [Users] ovirt VM custom properties > > > Not tested, no error handling (eg. does the element exist already) but ... > > > > #!/usr/bin/python > > import os > import sys > import hooking > import traceback > > > if os.environ.has_key('usbtablet'): > try: > sys.stderr.write('tablet: adding usbtablet support\n') > domxml =3D hooking.read_domxml() > > devices =3D domxml.getElementsByTagName('devices')[0] > tablet =3D domxml.createElement('input') > tablet.setAttribute('bus', 'usb') > > devices.appendChild(tablet) > > hooking.write_domxml(domxml) > except: > sys.stderr.write('tablet: [unexpected error]: %s\n' % traceback.= format_exc()) > sys.exit(2) > > > ----- Original Message ----- >> From: "Chris Brown (GE Healthcare)" >> To: "Andrew Cathrow" >> Cc: users(a)ovirt.org >> Sent: Wednesday, February 1, 2012 5:20:09 PM >> Subject: RE: [Users] ovirt VM custom properties >> >> Thanks Andy, >> I was afraid that might be case ;) >> I'll check out the examples and see what I can come up with. >> - Chris >> >> -----Original Message----- >> From: Andrew Cathrow [mailto:acathrow(a)redhat.com] >> Sent: Wednesday, February 01, 2012 3:29 PM >> To: Brown, Chris (GE Healthcare) >> Cc: users(a)ovirt.org >> Subject: Re: [Users] ovirt VM custom properties >> >> >> >> ----- Original Message ----- >>> From: "Chris Brown (GE Healthcare)" >>> To: users(a)ovirt.org >>> Sent: Wednesday, February 1, 2012 4:16:35 PM >>> Subject: [Users] ovirt VM custom properties >>> >>> >>> >>> >>> >>> In an effort to work around the mouse issues with spice consoles and >>> certain guests I had an idea for the time being. >>> >>> My thought process is to leverage custom properties to enable >>> usb-tablet support on said guests. >>> >>> --> ( >>> http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Virtualization/3. >>> 0/html/Administration_Guide/VDSM_Hooks.html >>> ) >>> >>> >>> >>> I perused the available documentation and it appears that these >>> custom properties are ultimately fed into the generated libvirt >>> domain xml. >>> >>> Thus sifting through --> >>> http://libvirt.org/formatdomain.html#elementsInput we can pass in: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> The issue I am hung up on is that since this contains multi-level >>> elements can this even be specified as a custom property? >> >> The custom property wouldn't contain the XML it would contain data you >> want to pass to a hook script eg. addTablet=3Dtrue, then it's down to >> your hook script to add the appropriate element to the device node in >> the libvirt xml. >> There's a number of good examples in the vdsm git repo. >> >> >>> >>> If so can one of the ovirt developers provide an example on how to >>> go about it? >> >> >>> >>> >>> >>> - Chris >>> _______________________________________________ >>> Users mailing list >>> Users(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >>> >> > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users --===============0124309700967686446==-- From Christopher.Brown at med.ge.com Mon Feb 6 13:21:05 2012 Content-Type: multipart/mixed; boundary="===============5974166976067189398==" MIME-Version: 1.0 From: Brown, Chris (GE Healthcare) To: users at ovirt.org Subject: Re: [Users] ovirt VM custom properties Date: Mon, 06 Feb 2012 13:21:02 -0500 Message-ID: In-Reply-To: 4F2BBA98.6030201@redhat.com --===============5974166976067189398== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Itamar, I will take a look through the wiki on code submission (I know I saw a write up on it in there), and figure out how to get this submitted. - Chris = -----Original Message----- From: Itamar Heim [mailto:iheim(a)redhat.com] = Sent: Friday, February 03, 2012 4:45 AM To: Brown, Chris (GE Healthcare) Cc: Andrew Cathrow; users(a)ovirt.org Subject: Re: [Users] ovirt VM custom properties On 02/02/2012 10:51 PM, Brown, Chris (GE Healthcare) wrote: > Andy, > Many thanks! > That got me going the right direction. > I did some extensive testing of with this. Here are the changes I made but basically what I do is: > - If the user specifies a custom property of usbtablet, just rewrite the input tag with: > This will of course = > rewrite the existing But in this case = > we know we desire usbtablet so just re-write with what we want. > For non problematic guests or guests to which the agent can be installed we simply remove the custom property after the agent is added. > For legacy guests all the way back to redhat 7.3 and win98/win2k etc we can simply use usbtablet for now. > Once the issues with the mouse input issues with the aforementioned guest types are resolved we again won't need this (hopefully). how about formalizing this into a patch for the vdsm custom hooks library? > > - Chris > > #!/usr/bin/python > # VDSM Hook Script for RHEV/oVirt > # Enables USB tablet support for a guest # use rhevm-config for RHEV = > or engine-config for oVirt to add UserDefinedVMProperties # EX: = > rhevm-config -s UserDefinedVMProperties=3D'usbtablet=3D^(true|false)$' = > --cver=3D3.0 # Remember to restart jboss # Use VM custom property = > usbtablet=3Dtrue in vm configuration (Custom Properties) > > import os > import sys > import hooking > import traceback > > > if os.environ.has_key('usbtablet'): > try: > sys.stderr.write('usbtablet requested\n') > domxml =3D hooking.read_domxml() > > devices =3D domxml.getElementsByTagName('devices')[0] > inputdev =3D domxml.getElementsByTagName('input')[0] > > inputdev.setAttribute('bus', 'usb') > inputdev.setAttribute('type', 'tablet') > inputdev.setAttribute('id', 'input0') > hooking.write_domxml(domxml) > sys.stderr.write('usbtablet support enabled\n') > > except: > sys.stderr.write('usbtablet: [unexpected error]: %s\n' % traceback.format_exc()) > sys.exit(2) > > > -----Original Message----- > From: Andrew Cathrow [mailto:acathrow(a)redhat.com] > Sent: Wednesday, February 01, 2012 5:01 PM > To: Brown, Chris (GE Healthcare) > Cc: users(a)ovirt.org > Subject: Re: [Users] ovirt VM custom properties > > > Not tested, no error handling (eg. does the element exist already) but ... > > > > #!/usr/bin/python > > import os > import sys > import hooking > import traceback > > > if os.environ.has_key('usbtablet'): > try: > sys.stderr.write('tablet: adding usbtablet support\n') > domxml =3D hooking.read_domxml() > > devices =3D domxml.getElementsByTagName('devices')[0] > tablet =3D domxml.createElement('input') > tablet.setAttribute('bus', 'usb') > > devices.appendChild(tablet) > > hooking.write_domxml(domxml) > except: > sys.stderr.write('tablet: [unexpected error]: %s\n' % traceback.format_exc()) > sys.exit(2) > > > ----- Original Message ----- >> From: "Chris Brown (GE Healthcare)" >> To: "Andrew Cathrow" >> Cc: users(a)ovirt.org >> Sent: Wednesday, February 1, 2012 5:20:09 PM >> Subject: RE: [Users] ovirt VM custom properties >> >> Thanks Andy, >> I was afraid that might be case ;) >> I'll check out the examples and see what I can come up with. >> - Chris >> >> -----Original Message----- >> From: Andrew Cathrow [mailto:acathrow(a)redhat.com] >> Sent: Wednesday, February 01, 2012 3:29 PM >> To: Brown, Chris (GE Healthcare) >> Cc: users(a)ovirt.org >> Subject: Re: [Users] ovirt VM custom properties >> >> >> >> ----- Original Message ----- >>> From: "Chris Brown (GE Healthcare)" >>> To: users(a)ovirt.org >>> Sent: Wednesday, February 1, 2012 4:16:35 PM >>> Subject: [Users] ovirt VM custom properties >>> >>> >>> >>> >>> >>> In an effort to work around the mouse issues with spice consoles and >>> certain guests I had an idea for the time being. >>> >>> My thought process is to leverage custom properties to enable = >>> usb-tablet support on said guests. >>> >>> --> ( >>> http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Virtualization/3. >>> 0/html/Administration_Guide/VDSM_Hooks.html >>> ) >>> >>> >>> >>> I perused the available documentation and it appears that these = >>> custom properties are ultimately fed into the generated libvirt = >>> domain xml. >>> >>> Thus sifting through --> >>> http://libvirt.org/formatdomain.html#elementsInput we can pass in: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> The issue I am hung up on is that since this contains multi-level = >>> elements can this even be specified as a custom property? >> >> The custom property wouldn't contain the XML it would contain data = >> you want to pass to a hook script eg. addTablet=3Dtrue, then it's down = >> to your hook script to add the appropriate element to the device node >> in the libvirt xml. >> There's a number of good examples in the vdsm git repo. >> >> >>> >>> If so can one of the ovirt developers provide an example on how to = >>> go about it? >> >> >>> >>> >>> >>> - Chris >>> _______________________________________________ >>> Users mailing list >>> Users(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >>> >> > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users --===============5974166976067189398==-- From Christopher.Brown at med.ge.com Tue Feb 14 16:29:09 2012 Content-Type: multipart/mixed; boundary="===============4204713487156781258==" MIME-Version: 1.0 From: Brown, Chris (GE Healthcare) To: users at ovirt.org Subject: Re: [Users] ovirt VM custom properties Date: Tue, 14 Feb 2012 16:29:06 -0500 Message-ID: In-Reply-To: C63EAE2B896C144EA58784406C423B991829AC@CINMLVEM37.e2k.ad.ge.com --===============4204713487156781258== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Something else I thought of on this. While the admin portal allows for cust= om properties and this works there for the user portal it does not. Thus a power user in the PUP cannot specify this as a custom property. This= again would inhibit their ability to interact with and install certain gue= sts. Is there a way we can allow a power user to specify a custom property on a = VM w/o admin interaction? - Chris -----Original Message----- From: Brown, Chris (GE Healthcare) = Sent: Thursday, February 02, 2012 2:52 PM To: 'Andrew Cathrow' Cc: users(a)ovirt.org Subject: RE: [Users] ovirt VM custom properties Andy, Many thanks! That got me going the right direction. I did some extensive testing of with this. Here are the changes I made but = basically what I do is: - If the user specifies a custom property of usbtablet, just rewrite the in= put tag with: This will of course rewr= ite the existing But in this case we kn= ow we desire usbtablet so just re-write with what we want. For non problematic guests or guests to which the agent can be installed we= simply remove the custom property after the agent is added. For legacy guests all the way back to redhat 7.3 and win98/win2k etc we can= simply use usbtablet for now. Once the issues with the mouse input issues with the aforementioned guest t= ypes are resolved we again won't need this (hopefully). - Chris = #!/usr/bin/python # VDSM Hook Script for RHEV/oVirt # Enables USB tablet support for a guest # use rhevm-config for RHEV or eng= ine-config for oVirt to add UserDefinedVMProperties # EX: rhevm-config -s U= serDefinedVMProperties=3D'usbtablet=3D^(true|false)$' --cver=3D3.0 # Rememb= er to restart jboss # Use VM custom property usbtablet=3Dtrue in vm configu= ration (Custom Properties) import os import sys import hooking import traceback if os.environ.has_key('usbtablet'): try: sys.stderr.write('usbtablet requested\n') domxml =3D hooking.read_domxml() devices =3D domxml.getElementsByTagName('devices')[0] inputdev =3D domxml.getElementsByTagName('input')[0] inputdev.setAttribute('bus', 'usb') inputdev.setAttribute('type', 'tablet') inputdev.setAttribute('id', 'input0') hooking.write_domxml(domxml) sys.stderr.write('usbtablet support enabled\n') except: sys.stderr.write('usbtablet: [unexpected error]: %s\n' % traceback.= format_exc()) sys.exit(2) -----Original Message----- From: Andrew Cathrow [mailto:acathrow(a)redhat.com] Sent: Wednesday, February 01, 2012 5:01 PM To: Brown, Chris (GE Healthcare) Cc: users(a)ovirt.org Subject: Re: [Users] ovirt VM custom properties Not tested, no error handling (eg. does the element exist already) but ... #!/usr/bin/python import os import sys import hooking import traceback if os.environ.has_key('usbtablet'): try: sys.stderr.write('tablet: adding usbtablet support\n') domxml =3D hooking.read_domxml() devices =3D domxml.getElementsByTagName('devices')[0] tablet =3D domxml.createElement('input') tablet.setAttribute('bus', 'usb') devices.appendChild(tablet) hooking.write_domxml(domxml) except: sys.stderr.write('tablet: [unexpected error]: %s\n' % traceback.for= mat_exc()) sys.exit(2) ----- Original Message ----- > From: "Chris Brown (GE Healthcare)" > To: "Andrew Cathrow" > Cc: users(a)ovirt.org > Sent: Wednesday, February 1, 2012 5:20:09 PM > Subject: RE: [Users] ovirt VM custom properties > = > Thanks Andy, > I was afraid that might be case ;) > I'll check out the examples and see what I can come up with. > - Chris > = > -----Original Message----- > From: Andrew Cathrow [mailto:acathrow(a)redhat.com] > Sent: Wednesday, February 01, 2012 3:29 PM > To: Brown, Chris (GE Healthcare) > Cc: users(a)ovirt.org > Subject: Re: [Users] ovirt VM custom properties > = > = > = > ----- Original Message ----- > > From: "Chris Brown (GE Healthcare)" > > To: users(a)ovirt.org > > Sent: Wednesday, February 1, 2012 4:16:35 PM > > Subject: [Users] ovirt VM custom properties > > = > > = > > = > > = > > = > > In an effort to work around the mouse issues with spice consoles and = > > certain guests I had an idea for the time being. > > = > > My thought process is to leverage custom properties to enable = > > usb-tablet support on said guests. > > = > > --> ( > > http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Virtualization/3. > > 0/html/Administration_Guide/VDSM_Hooks.html > > ) > > = > > = > > = > > I perused the available documentation and it appears that these = > > custom properties are ultimately fed into the generated libvirt = > > domain xml. > > = > > Thus sifting through --> > > http://libvirt.org/formatdomain.html#elementsInput we can pass in: > > = > > > > = > > > > = > > > > = > > = > > = > > The issue I am hung up on is that since this contains multi-level = > > elements can this even be specified as a custom property? > = > The custom property wouldn't contain the XML it would contain data you = > want to pass to a hook script eg. addTablet=3Dtrue, then it's down to = > your hook script to add the appropriate element to the device node in = > the libvirt xml. > There's a number of good examples in the vdsm git repo. > = > = > > = > > If so can one of the ovirt developers provide an example on how to = > > go about it? > = > = > > = > > = > > = > > - Chris > > _______________________________________________ > > Users mailing list > > Users(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/users > > = >=20 --===============4204713487156781258==-- From iheim at redhat.com Wed Feb 15 01:57:46 2012 Content-Type: multipart/mixed; boundary="===============8836900816711318576==" MIME-Version: 1.0 From: Itamar Heim To: users at ovirt.org Subject: Re: [Users] ovirt VM custom properties Date: Wed, 15 Feb 2012 08:57:37 +0200 Message-ID: <4F3B5761.9070907@redhat.com> In-Reply-To: C63EAE2B896C144EA58784406C423B991829CB@CINMLVEM37.e2k.ad.ge.com --===============8836900816711318576== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 02/14/2012 11:29 PM, Brown, Chris (GE Healthcare) wrote: > Something else I thought of on this. While the admin portal allows for cu= stom properties and this works there for the user portal it does not. > Thus a power user in the PUP cannot specify this as a custom property. Th= is again would inhibit their ability to interact with and install certain g= uests. > Is there a way we can allow a power user to specify a custom property on = a VM w/o admin interaction? I expect only when we'll develop permissions for them. > - Chris > > -----Original Message----- > From: Brown, Chris (GE Healthcare) > Sent: Thursday, February 02, 2012 2:52 PM > To: 'Andrew Cathrow' > Cc: users(a)ovirt.org > Subject: RE: [Users] ovirt VM custom properties > > Andy, > Many thanks! > That got me going the right direction. > I did some extensive testing of with this. Here are the changes I made bu= t basically what I do is: > - If the user specifies a custom property of usbtablet, just rewrite the = input tag with: > This will of course r= ewrite the existing But in this case we= know we desire usbtablet so just re-write with what we want. > For non problematic guests or guests to which the agent can be installed = we simply remove the custom property after the agent is added. > For legacy guests all the way back to redhat 7.3 and win98/win2k etc we c= an simply use usbtablet for now. > Once the issues with the mouse input issues with the aforementioned guest= types are resolved we again won't need this (hopefully). > > - Chris > > #!/usr/bin/python > # VDSM Hook Script for RHEV/oVirt > # Enables USB tablet support for a guest # use rhevm-config for RHEV or e= ngine-config for oVirt to add UserDefinedVMProperties # EX: rhevm-config -s= UserDefinedVMProperties=3D'usbtablet=3D^(true|false)$' --cver=3D3.0 # Reme= mber to restart jboss # Use VM custom property usbtablet=3Dtrue in vm confi= guration (Custom Properties) > > import os > import sys > import hooking > import traceback > > > if os.environ.has_key('usbtablet'): > try: > sys.stderr.write('usbtablet requested\n') > domxml =3D hooking.read_domxml() > > devices =3D domxml.getElementsByTagName('devices')[0] > inputdev =3D domxml.getElementsByTagName('input')[0] > > inputdev.setAttribute('bus', 'usb') > inputdev.setAttribute('type', 'tablet') > inputdev.setAttribute('id', 'input0') > hooking.write_domxml(domxml) > sys.stderr.write('usbtablet support enabled\n') > > except: > sys.stderr.write('usbtablet: [unexpected error]: %s\n' % traceba= ck.format_exc()) > sys.exit(2) > > > -----Original Message----- > From: Andrew Cathrow [mailto:acathrow(a)redhat.com] > Sent: Wednesday, February 01, 2012 5:01 PM > To: Brown, Chris (GE Healthcare) > Cc: users(a)ovirt.org > Subject: Re: [Users] ovirt VM custom properties > > > Not tested, no error handling (eg. does the element exist already) but ... > > > > #!/usr/bin/python > > import os > import sys > import hooking > import traceback > > > if os.environ.has_key('usbtablet'): > try: > sys.stderr.write('tablet: adding usbtablet support\n') > domxml =3D hooking.read_domxml() > > devices =3D domxml.getElementsByTagName('devices')[0] > tablet =3D domxml.createElement('input') > tablet.setAttribute('bus', 'usb') > > devices.appendChild(tablet) > > hooking.write_domxml(domxml) > except: > sys.stderr.write('tablet: [unexpected error]: %s\n' % traceback.= format_exc()) > sys.exit(2) > > > ----- Original Message ----- >> From: "Chris Brown (GE Healthcare)" >> To: "Andrew Cathrow" >> Cc: users(a)ovirt.org >> Sent: Wednesday, February 1, 2012 5:20:09 PM >> Subject: RE: [Users] ovirt VM custom properties >> >> Thanks Andy, >> I was afraid that might be case ;) >> I'll check out the examples and see what I can come up with. >> - Chris >> >> -----Original Message----- >> From: Andrew Cathrow [mailto:acathrow(a)redhat.com] >> Sent: Wednesday, February 01, 2012 3:29 PM >> To: Brown, Chris (GE Healthcare) >> Cc: users(a)ovirt.org >> Subject: Re: [Users] ovirt VM custom properties >> >> >> >> ----- Original Message ----- >>> From: "Chris Brown (GE Healthcare)" >>> To: users(a)ovirt.org >>> Sent: Wednesday, February 1, 2012 4:16:35 PM >>> Subject: [Users] ovirt VM custom properties >>> >>> >>> >>> >>> >>> In an effort to work around the mouse issues with spice consoles and >>> certain guests I had an idea for the time being. >>> >>> My thought process is to leverage custom properties to enable >>> usb-tablet support on said guests. >>> >>> --> ( >>> http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Virtualization/3. >>> 0/html/Administration_Guide/VDSM_Hooks.html >>> ) >>> >>> >>> >>> I perused the available documentation and it appears that these >>> custom properties are ultimately fed into the generated libvirt >>> domain xml. >>> >>> Thus sifting through --> >>> http://libvirt.org/formatdomain.html#elementsInput we can pass in: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> The issue I am hung up on is that since this contains multi-level >>> elements can this even be specified as a custom property? >> >> The custom property wouldn't contain the XML it would contain data you >> want to pass to a hook script eg. addTablet=3Dtrue, then it's down to >> your hook script to add the appropriate element to the device node in >> the libvirt xml. >> There's a number of good examples in the vdsm git repo. >> >> >>> >>> If so can one of the ovirt developers provide an example on how to >>> go about it? >> >> >>> >>> >>> >>> - Chris >>> _______________________________________________ >>> Users mailing list >>> Users(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >>> >> > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users --===============8836900816711318576==-- From Christopher.Brown at med.ge.com Wed Feb 15 10:34:50 2012 Content-Type: multipart/mixed; boundary="===============5855435608163292939==" MIME-Version: 1.0 From: Brown, Chris (GE Healthcare) To: users at ovirt.org Subject: Re: [Users] ovirt VM custom properties Date: Wed, 15 Feb 2012 10:34:47 -0500 Message-ID: In-Reply-To: 4F3B5761.9070907@redhat.com --===============5855435608163292939== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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. 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. Let me know your thoughts. -Chris -----Original Message----- From: Itamar Heim [mailto:iheim(a)redhat.com] = Sent: Wednesday, February 15, 2012 12:58 AM To: Brown, Chris (GE Healthcare) Cc: Andrew Cathrow; users; lpeer >> Livnat Peer Subject: Re: [Users] ovirt VM custom properties On 02/14/2012 11:29 PM, Brown, Chris (GE Healthcare) wrote: > Something else I thought of on this. While the admin portal allows for custom properties and this works there for the user portal it does not. > Thus a power user in the PUP cannot specify this as a custom property. This again would inhibit their ability to interact with and install certain guests. > Is there a way we can allow a power user to specify a custom property on a VM w/o admin interaction? I expect only when we'll develop permissions for them. > - Chris > > -----Original Message----- > From: Brown, Chris (GE Healthcare) > Sent: Thursday, February 02, 2012 2:52 PM > To: 'Andrew Cathrow' > Cc: users(a)ovirt.org > Subject: RE: [Users] ovirt VM custom properties > > Andy, > Many thanks! > That got me going the right direction. > I did some extensive testing of with this. Here are the changes I made but basically what I do is: > - If the user specifies a custom property of usbtablet, just rewrite the input tag with: > This will of course rewrite the existing But in this case we know we desire usbtablet so just re-write with what we want. > For non problematic guests or guests to which the agent can be installed we simply remove the custom property after the agent is added. > For legacy guests all the way back to redhat 7.3 and win98/win2k etc we can simply use usbtablet for now. > Once the issues with the mouse input issues with the aforementioned guest types are resolved we again won't need this (hopefully). > > - Chris > > #!/usr/bin/python > # VDSM Hook Script for RHEV/oVirt > # Enables USB tablet support for a guest # use rhevm-config for RHEV or engine-config for oVirt to add UserDefinedVMProperties # EX: rhevm-config -s UserDefinedVMProperties=3D'usbtablet=3D^(true|false)$' --cver=3D3.0 # Remember to restart jboss # Use VM custom property usbtablet=3Dtrue in vm configuration (Custom Properties) > > import os > import sys > import hooking > import traceback > > > if os.environ.has_key('usbtablet'): > try: > sys.stderr.write('usbtablet requested\n') > domxml =3D hooking.read_domxml() > > devices =3D domxml.getElementsByTagName('devices')[0] > inputdev =3D domxml.getElementsByTagName('input')[0] > > inputdev.setAttribute('bus', 'usb') > inputdev.setAttribute('type', 'tablet') > inputdev.setAttribute('id', 'input0') > hooking.write_domxml(domxml) > sys.stderr.write('usbtablet support enabled\n') > > except: > sys.stderr.write('usbtablet: [unexpected error]: %s\n' % traceback.format_exc()) > sys.exit(2) > > > -----Original Message----- > From: Andrew Cathrow [mailto:acathrow(a)redhat.com] > Sent: Wednesday, February 01, 2012 5:01 PM > To: Brown, Chris (GE Healthcare) > Cc: users(a)ovirt.org > Subject: Re: [Users] ovirt VM custom properties > > > Not tested, no error handling (eg. does the element exist already) but ... > > > > #!/usr/bin/python > > import os > import sys > import hooking > import traceback > > > if os.environ.has_key('usbtablet'): > try: > sys.stderr.write('tablet: adding usbtablet support\n') > domxml =3D hooking.read_domxml() > > devices =3D domxml.getElementsByTagName('devices')[0] > tablet =3D domxml.createElement('input') > tablet.setAttribute('bus', 'usb') > > devices.appendChild(tablet) > > hooking.write_domxml(domxml) > except: > sys.stderr.write('tablet: [unexpected error]: %s\n' % traceback.format_exc()) > sys.exit(2) > > > ----- Original Message ----- >> From: "Chris Brown (GE Healthcare)" >> To: "Andrew Cathrow" >> Cc: users(a)ovirt.org >> Sent: Wednesday, February 1, 2012 5:20:09 PM >> Subject: RE: [Users] ovirt VM custom properties >> >> Thanks Andy, >> I was afraid that might be case ;) >> I'll check out the examples and see what I can come up with. >> - Chris >> >> -----Original Message----- >> From: Andrew Cathrow [mailto:acathrow(a)redhat.com] >> Sent: Wednesday, February 01, 2012 3:29 PM >> To: Brown, Chris (GE Healthcare) >> Cc: users(a)ovirt.org >> Subject: Re: [Users] ovirt VM custom properties >> >> >> >> ----- Original Message ----- >>> From: "Chris Brown (GE Healthcare)" >>> To: users(a)ovirt.org >>> Sent: Wednesday, February 1, 2012 4:16:35 PM >>> Subject: [Users] ovirt VM custom properties >>> >>> >>> >>> >>> >>> In an effort to work around the mouse issues with spice consoles and >>> certain guests I had an idea for the time being. >>> >>> My thought process is to leverage custom properties to enable >>> usb-tablet support on said guests. >>> >>> --> ( >>> http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Virtualization/3. >>> 0/html/Administration_Guide/VDSM_Hooks.html >>> ) >>> >>> >>> >>> I perused the available documentation and it appears that these >>> custom properties are ultimately fed into the generated libvirt >>> domain xml. >>> >>> Thus sifting through --> >>> http://libvirt.org/formatdomain.html#elementsInput we can pass in: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> The issue I am hung up on is that since this contains multi-level >>> elements can this even be specified as a custom property? >> >> The custom property wouldn't contain the XML it would contain data you >> want to pass to a hook script eg. addTablet=3Dtrue, then it's down to >> your hook script to add the appropriate element to the device node in >> the libvirt xml. >> There's a number of good examples in the vdsm git repo. >> >> >>> >>> If so can one of the ovirt developers provide an example on how to >>> go about it? >> >> >>> >>> >>> >>> - Chris >>> _______________________________________________ >>> Users mailing list >>> Users(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >>> >> > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users --===============5855435608163292939==-- From iheim at redhat.com Wed Feb 15 14:46:00 2012 Content-Type: multipart/mixed; boundary="===============3377144768319191345==" MIME-Version: 1.0 From: Itamar Heim To: users at ovirt.org Subject: Re: [Users] ovirt VM custom properties Date: Wed, 15 Feb 2012 21:45:55 +0200 Message-ID: <4F3C0B73.8020709@redhat.com> In-Reply-To: C63EAE2B896C144EA58784406C423B991829CC@CINMLVEM37.e2k.ad.ge.com --===============3377144768319191345== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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. --===============3377144768319191345==-- From Christopher.Brown at med.ge.com Wed Feb 15 15:29:48 2012 Content-Type: multipart/mixed; boundary="===============2297318325530963402==" MIME-Version: 1.0 From: Brown, Chris (GE Healthcare) To: users at ovirt.org Subject: Re: [Users] ovirt VM custom properties Date: Wed, 15 Feb 2012 15:29:45 -0500 Message-ID: In-Reply-To: 4F3C0B73.8020709@redhat.com --===============2297318325530963402== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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-.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/ovir t/engine/ui/userportal/client/modalpanels --> file: NewVmModalPanel.java --> lines 76 - 84 --> add: TabButton customPropertiesTabButton; --> lines 100 - 108 --> add: customPropertiesTabButton =3D 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-.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(a)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. --===============2297318325530963402==--