- Devel - oVirt List Archives

[Engine-devel] JMX Console on oVirt engine
by David Jorm 08 Dec '11

08 Dec '11

Hi All I have followed the instructions on the wiki: http://ovirt.org/wiki/Installing_ovirt-engine_from_rpm And successfully installed oVirt engine. The instructions worked perfectly. I noticed that JBoss AS 5 came bundled in the ovirt-engine-jbossas package. I understand the reasoning for going out with AS 5 for now. However, the AS 5 default security configuration has not been changed. Once you install oVirt engine using the instructions above, the JMX Console will be running with no authentication. Worms exploiting this weakness are knowing to be circulating; people are likely to get compromised. For now, I have added instructions on securing the JMX Console to the aforementioned wiki page. In the long term, I think we should either disable or completely remove the JMX Console from JBoss AS as it is distributed with oVirt engine. Thanks -- David Jorm / Red Hat Security Response Team

1 0

[Engine-devel] New tool to upload OVF archives
by Keith Robertson 07 Dec '11

07 Dec '11

All, I have created a new tool that makes it easier to upload an OVF archive file to an oVirt export domain. I've attached the patch to this email so that you can try it out and see what it does. I am looking for feedback on the tool so please let me know what you think. Cheers, Keith //---- Begin description The new tool provided in this patch makes it easier to upload an OVF archive to an export domain. An OVF archive is simply a zipped archive that can contain an image and must contain an XML document describing the image to be uploaded. The tool has the following behavior: 1. Before unpacking the archive it will check for requisite space on the local system. 2. Before uploading the requisite parts in the archive it will check for space in the target NFS export domain. 3. At this time only NFS as a transport mechanism is supported. This is slightly different behavior than the iso uploader which supports both NFS and SSH/SFTP. 4. The tool will allow you to rename the image. 5. The tool will allow you to change the UUID of the image. 6. The tool will only upload those files explicitly listed in the archive's XML .ovf file. This prevents spurious cruft which it included in some OVF archives from being moved to the export domain. Example usage: 1. > python ovirt-image-uploader.py -n 127.0.0.1:/virt/exports --template-name=new-name-here --template-id=new-uuid-here upload keith.ovf --force 2. > python ovirt-image-uploader.py --conf-file=./imageuploader.conf list Please provide the REST API password for RHEV-M (CTRL+D to abort): Export Storage Domain Name | Datacenter | Export Domain Status ExportDomain | LegacyDC | active 3. > python ovirt-image-uploader.py -e ExportDomain --template-name=new-name-here --template-id=new-uuid-here upload keith.ovf --force

5 16

[Engine-devel] Agenda for bi-weekly oVirt engine core meeting (Wed Dec. 7th)
by Mike Kolesnik 07 Dec '11

07 Dec '11

--=_604eecab-6a98-4ed3-944f-93e52c5a8fc6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit These are the topics that we are planning to discuss in the meeting: * Open discussion on stable addressing support in the engine. * Michael Kublin - Introducing synchronization/locking mechanism . * Mike Kolesnik - Introducing upcoming changes due to snapshots fixes. If anyone would like to discuss other topics, feel free to reply and add them to the list. Regards, Mike --=_604eecab-6a98-4ed3-944f-93e52c5a8fc6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Times New Roman; font-size: 12pt; color: #000000'>These are the topics that we are planning to discuss in the meeting:<br><br>* Open discussion on stable addressing support in the engine.<br>* Michael Kublin - Introducing synchronization/locking mechanism.<br>* Mike Kolesnik - Introducing upcoming changes due to snapshots fixes.<br><br>If anyone would like to discuss other topics, feel free to reply and add them to the list.<br><br><div><span name="x"></span>Regards,<br>Mike<span name="x"></span><br></div><br></div></body></html> --=_604eecab-6a98-4ed3-944f-93e52c5a8fc6--

2 1

Re: [Engine-devel] Stable PCI/DEvice addresses
by Livnat Peer 05 Dec '11

05 Dec '11

Moving this back to list - On 12/01/2011 01:49 PM, Dan Kenigsberg wrote: > On Thu, Dec 01, 2011 at 06:26:16AM -0500, Eli Mesika wrote: >> Hi guys >> >> I need the xml/json format representing the VM installed devices. >> Livnat asked me to add it to my Wiki >> http://www.ovirt.org/wiki/Features/Design/StableDeviceAddresses >> >> Please feel free to either send it to me or edit the VDSM section adding this info. > > I think that it is wrong to document this in this point in time. The > data is a blob, generated by libvirt, copied by Vdsm, and not expected > to be editted by RHEV-M. > > If you REALLY want to know, it is simply libvirt's domain xml, which is > well-documented in http://libvirt.org/formatdomain.html. > > Dan. > Hi Dan, Since i suspect the next requirement on this would be for RHEVM to parse the "blob" and enable user to specify addresses i think the content of the "blob" should be discussed. Otherwise we'll have to support this "blob" format for the sake of backwards compatibility and not be able to set a reasonable API between the engine and VDSM. Livnat

5 7

[Engine-devel] blog post ovirt-engine
by Livnat Peer 05 Dec '11

05 Dec '11

Hi, I wrote a post about migrating oVirt-engine from MS-SQL to PostgreSQL. http://lpeer.blogspot.com/2011/12/migrating-ovirt-from-ms-sql-to.html Livnat

1 0

[Engine-devel] Stable PCI Addresses design wiki
by Eli Mesika 04 Dec '11

04 Dec '11

http://www.ovirt.org/wiki/Features/Design/StablePCIAddresses

9 19

[Engine-devel] Proposed next-generation vdsm API
by Adam Litke 03 Dec '11

03 Dec '11

Recently we've had some very productive discussions concerning the VDSM API. I want to attempt to refocus the discussion around an emerging proposal and see if we can agree on a sensible path forward. Based on the discussion, I have identified the following requirements that a new API for vdsm should have: 1.) Single API that can be consumed by ovirt-engine and ISVs - We don't want to maintain multiple parallel APIs - To develop a vendor ecosystem, we must have a robust external API to vdsm 2.) Full vdsm capabilities are exposed without requiring ovirt-engine - ovirt components should be modular and independently useful - Some deployments might want to manage nodes without ovirt-engine 3.) Standardized protocol with low overhead - Required for widespread adoption 4.) Support for asynchronous tasks and events - Needed by ovirt-engine and other consumers Based on these requirements, the following proposal has started to emerge: Create a REST API that will provide all of the functionality that is currently available via the xmlrpc interface (with the goal of deprecating xmlrpc once it becomes mature enough). To support advanced clustering features that ovirt-engine is planning, we'll write an QMF broker that can proxy the REST API onto a message bus. ovirt-engine will interact with vdsm exclusively over this bus but the REST API will be the principle API and the entry point for ISV apps. A REST API provides a light-weight and standard way to access all of the vdsm functionality. The REST API will handle events by exposing a new 'events' collection at the api root. REST users will use some sort of polling to collect these events. The details of this interface are being worked on. Several ways for minimizing the impact of polling have been discussed. The QMF broker can expose a publish/subscribe model for events as appropriate. Is this model an acceptable way to improve the vdsm API? I would like to hear the opinions of ovirt-engine developers, vdsm developers, and other stakeholders. Thanks for providing feedback on this proposal! -- Adam Litke <agl(a)us.ibm.com> IBM Linux Technology Center

7 13

Re: [Engine-devel] Announcing a proof of concept REST API for VDSM
by Itamar Heim 30 Nov '11

30 Nov '11

On 11/29/2011 11:36 PM, Adam Litke wrote: > On Tue, Nov 29, 2011 at 12:54:44PM -0800, Chris Wright wrote: >> * Adam Litke (agl(a)us.ibm.com) wrote: >>> On Tue, Nov 29, 2011 at 11:39:08AM -0800, Chris Wright wrote: >>>> * Adam Litke (agl(a)us.ibm.com) wrote: >>>>> >>>>> https://github.com/aglitke/vdsm-rest/ >>>>> >>>>> Today I am releasing a proof of concept implementation of a REST API for vdsm. >>>>> You can find the code on github. My goal is to eventually replace the current >>>>> xmlrpc interface with a REST API. Once completed, ovirt-engine could switch to >>>>> this new API. The major advantages to making this change are: 1) VDSM will gain >>>>> a structured API that conceptually, structurally, and functionally aligns with >>>>> the ovirt-engine REST API, 2) this new API can be made public, thus providing an >>>>> entry point for direct virtualization management@the node level. >>>> >>>> Adam, this looks like a nice PoC. I didn't see how API versioning is >>>> handled. Any VDSM developers willing to review this work? >>> >>> Thanks for taking a look. I am not handling versioning yet. I think we can add >>> a version field to the root API object. As for compatibility, we'll just have >>> to decide on an API backwards-compat support policy. Would this be enough to >>> handle versioning issues? We shouldn't need anything like capabilities because >>> the API is discoverable. >> >> Right, that seems sensible. >> >> Did you find cases where RPC to REST resource mapping was difficult? > > I haven't yet fully implemented the current vdsm API but I suspect that certain > calls (like the ones you mention below) will require some extensions to what I > have available currently. The main missing piece is probably events and a nice > polling API. Another big piece of work will be to rebase onto the newly > redesigned storage model. > >> I could see something like migrate() plus migrateStatus() and >> migrateCancel() needing to add some kind of operational state that to the >> resource. And something like monitorCommand() which has both a possible >> side-effect and some freefrom response... > > Hopefully monitorCommand will not be too bad, since vdsm should be asking > libvirt for the VM details when they are needed. Of course we'll need to be > testing to make sure we aren't keeping state around. Also, I would expect > monitorCommand to 'taint' the VM in the eyes of the vdsm API (as it does for > libvirt). > >>>> <snip> >>>>> ovirt-engine wants to subscribe to asynchronous events. REST APIs do not >>>>> typically support async events and instead rely on polling of resources. I am >>>>> investigating what options are available for supporting async events via REST. >>>> >>>> I think typical is either polling or long polling. If it's a single >>>> resource, then perhaps long polling would be fine (won't be a large >>>> number of connections tied up if it's only a single resource). >>> >>> Not sure if this is what you are referring to, but I was thinking we could do a >>> batch-polling mechanism where an API user passes in a list of task UUIDs and/or >>> event URIs. The server would respond with the status of these resources in one >>> response. I have some ideas on how we could wire up asynchronous events on the >>> server side to reduce the amount of actual work that such a batch-polling >>> operation would require. >> >> Oh, I just meant this: >> >> Polling (GET /event + 404 loop) >> Long polling (GET + block ... can chew up a thread connection) > > Yep. And we can talk later about building an API for efficient, repeated > polling. I wonder if the ovirt-engine guys could weigh in as to whether a REST cc-ing engine-devel... > interface with event polling would be acceptable to them. It is critical that > we settle on an API that can become _the_ first-class vehicle for interacting > with vdsm. > > Thanks! > i have two points for consideration around this: 1. as the api between ovirt-engine and vdsm, I had a preference for the bus like nature of QMF, as it would allow multiple ovirt-engine to load balance handling of messages from the queue, and multiple consumers for some messages (say, history service picking up the stats in parallel to engine picking them, rather than copying them from engine). 2. as node level api, i think a lightweight ovirt-engine managing a single node and exposing the exact same REST API and behavior of the multi-node ovirt engine would be easier to cosnume for someone that wants to interact with a single node same way they would interact with ovirt-engine.

7 19

[Engine-devel] Quota feature design
by Maor 30 Nov '11

30 Nov '11

Hi everyone, Following the introduction of Quota feature description, The following link is the design of Quota feature: http://www.ovirt.org/wiki/Features/Design/Quota Please feel free, to share your comments. Thank you, Maor

1 0

[Engine-devel] Requirement for Locking Mechanism
by Michael Kublin 29 Nov '11

29 Nov '11

Hi All, We are introducing a new short term locking mechanism at engine. The motivation is races which are occurring between different flows, the main problem is : we did not update status of some entity and other flow was started , which is a main cause for different collisions and situation which can not be fixed in appropriate way by engine or vdsm. The current status is a workaround which is trying to reduce a race : in many places in the code, there is additional query to DB in order to check the appropriate status of entity. The proposed solution is internal locking mechanism - which will lock an appropriate entity until its status will not be updated in DB, after that an internal short term lock will be released. The design for locking mechanism can be found here: http://www.ovirt.org/wiki/Features/DetailedLockMechanism The patch which is introduce an implementation for mechanism can be found here: http://gerrit.ovirt.org/#change,403 (Using of new mechanism all around a code and integration with bll will be sent in the future, including cleaning of workaround) Regards Michael

5 6