December 2011 - Devel - oVirt List Archives

[Engine-devel] Requirements for Aeolus instance data injection.
by jvlcek 14 Jan '12

14 Jan '12

Itamar, The below, provided by David Lutterkort, is a good description of the requirements for Aeolus instance data injection. Joe VLcek RHEV-M shall accept a small blob of data as part of the 'start VM' action. That data has to be placed somewhere where the VM can easily and securely access it. The data must only be visible to the VM it is intended for. Possibilities for where to put the data include placing it into a file on a virtual floppy or CD-ROM that the instance can mount, or posting it on a webserver that only the instance has access to (cf. EC2's handling of userData for the RunInstances call) The size limitation for the amount of data shouldn't be kept artificially low, but if there are important reasons to make it this small 1k would certainly suffice. In practical terms, the blob of data should be passed to the 'start VM' call base64 encoded, and RHEV-M should decode it just before putting it into its proper place.

6 13

[Engine-devel] Stable Device Addresses HLD/LLD for tomorrow meeting (15:00 GMT+1)
by Eli Mesika 04 Jan '12

04 Jan '12

High level design : http://www.ovirt.org/wiki/Features/Design/StableDeviceAddresses Low level design : http://www.ovirt.org/wiki/Features/Design/DetailedStableDeviceAddresses (probably will be modified until the meeting)

4 5

[Engine-devel] SPM Priority Design - Wiki Page
by Muli Salem 02 Jan '12

02 Jan '12

Hi all, In the link below there is a wiki page describing the requirements and design of the SPM Priority feature. The feature allows the admin to define priorities between hosts regarding the SPM selection process http://www.ovirt.org/wiki/Features/SPMPriority Please feel free to share your comments. Thanks, Muli

8 18

[Engine-devel] MOM Stable Device Address DR
by Eli Mesika 01 Jan '12

01 Jan '12

The following summarizes the DR meeting from today Attendees: Backend Team + Moran & Haim from QA ----------------------------------------- => marks responsibility for action items.| ----------------------------------------- Issues/Action Items: 1) Video - memory allocation logic, check again why the logic of how much memory to allocate to a video device should move to backend. => (Eli, Igor) 2) Generic-device - rename to vm_device (Eli) 3) Verify hash is only on devices (not on all domxml) , check if can be expanded to VM scope (app list etc.) => (Eli, Igor) 4) Floppy/CD - should be handled as vm_device that means we have to add to it also boot order => (Eli, Igor) 5) Hot plug - need to check for added/deleted devices, Open issue how to handle for managed device. same for any other device that is changed not via backend => (Eli, Igor) 6) How boot order affects GUI (order of NICs) - check with Einav if support can be added for that in UI (for disks use only 1) (Eli,Einav) 7) OVF - add new devices , addresses , coordinate with V2V => (Eli) 8) Live snapshot , check if affects design => (Eli, Igor) 9) Review class diagram of detailed design => (Eli) 10) Do we have to persist indexes ? check if addresses are respected in spite of indexes.... => (Eli, Igor) 11) Update wiki pages => (Eli) Reference: http://www.ovirt.org/wiki/Features/Design/StableDeviceAddresses http://www.ovirt.org/wiki/Features/Design/DetailedStableDeviceAddresses

3 2

[Engine-devel] JBoss RPM vs JBoss zip file
by Ronen Angluster 29 Dec '11

29 Dec '11

Hello, I guess this discussion was being carried offline and i wanted to get the as many opinions as possible about this issue. Currently, we provide the users with 2 methods of handling JBoss AS's deployments: 1. Download the zip file from jboss.org and deploy it wherever the user wishes. 2. Install a specially crafted RPM that is designed & destined to work with the ovirt-engine's RPM set of files. (This is a temporary deployment phase that will end when jboss will release their own set of RPMs) in MHO, i think that the RPM deployment should be used ONLY when installing the ovirt-engine RPMs and not when using the ovirt-engine's git repository for development. especially since deployment to the file system of the host requires root permissions and this is not something that should be a consideration when you're developing code. I think that developers should use the JBoss zip package and deploy it locally, and NOT use the ovirt-engine-jbossas RPM. opinions? Ronen

4 5

[Engine-devel] Stable PCI Addresses DR
by Eli Mesika 27 Dec '11

27 Dec '11

Hi We will have a design review meeting this THU, Dec 29 at 15:00 (GMT+1 , ISRAEL time) regarding the new 3.1 Stable PCI Addresses. Meeting is planned to be 1 Hour. Higher level design doc can be found in our oVirt wiki : http://www.ovirt.org/wiki/Features/Design/StableDeviceAddresses Detailed design will be added prior to the meeting. You are invited to join. == Conference Call Info == * Toll Free Dial-In Number (US & Canada): (800) 451-8679 * International dial-in listed below * Conference Code: 9197544554 If you are not actively participating in the conversation please put your line on mute to make it easier for all participants to hear. *6 -- Mute your line #6 -- Unmute your line Global Access Numbers Local: Australia, Sydney Dial-In #: 0289852326 Austria, Vienna Dial-In #: 012534978196 Belgium, Brussels Dial-In #: 027920405 China Dial-In #: 4006205013 Denmark, Copenhagen Dial-In #: 32729215 Finland, Helsinki Dial-In #: 0923194436 France, Paris Dial-In #: 0170377140 Germany, Berlin Dial-In #: 030300190579 Ireland, Dublin Dial-In #: 014367793 Italy, Milan Dial-In #: 0236269529 Netherlands, Amsterdam Dial-In #: 0207975872 Norway, Oslo Dial-In #: 21033188 Singapore Dial-In #: 64840858 Spain, Barcelona Dial-In #: 935452328 Sweden, Stockholm Dial-In #: 0850513770 Switzerland, Geneva Dial-In #: 0225927881 United Kingdom Dial-In #: 02078970515 United Kingdom Dial-In #: 08445790676 United Kingdom, LocalCall Dial-In #: 08445790678 United States Dial-In #: 2127295016 Global Access Numbers Tollfree: Argentina Dial-In #: 8004441016 Australia Dial-In #: 1800337169 Austria Dial-In #: 0800005898 Bahamas Dial-In #: 18002054776 Bahrain Dial-In #: 80004377 Belgium Dial-In #: 080048325 Brazil Dial-In #: 08008921002 Bulgaria Dial-In #: 008001100236 Chile Dial-In #: 800370228 Colombia Dial-In #: 018009134033 Costa Rica Dial-In #: 08000131048 Cyprus Dial-In #: 80095297 Czech Republic Dial-In #: 800700318 Denmark Dial-In #: 80887114 Dominican Republic Dial-In #: 18887512313 Estonia Dial-In #: 8000100232 Finland Dial-In #: 0800117116 France Dial-In #: 0805632867 Germany Dial-In #: 8006647541 Greece Dial-In #: 00800127562 Hong Kong Dial-In #: 800930349 Hungary Dial-In #: 0680016796 Iceland Dial-In #: 8008967 India Dial-In #: 0008006501533 Indonesia Dial-In #: 0018030179162 Ireland Dial-In #: 1800932401 Israel Dial-In #: 1809462557 Italy Dial-In #: 800985897 Jamaica Dial-In #: 18002050328 Japan Dial-In #: 0120934453 Korea (South) Dial-In #: 007986517393 Latvia Dial-In #: 80003339 Lithuania Dial-In #: 880030479 Luxembourg Dial-In #: 80026595 Malaysia Dial-In #: 1800814451 Mexico Dial-In #: 0018664590915 New Zealand Dial-In #: 0800888167 Norway Dial-In #: 80012994 Panama Dial-In #: 008002269184 Philippines Dial-In #: 180011100991 Poland Dial-In #: 008001210187 Portugal Dial-In #: 800814625 Russian Federation Dial-In #: 81080028341012 Saint Kitts and Nevis Dial-In #: 18002059252 Singapore Dial-In #: 8006162235 Slovak Republic Dial-In #: 0800001441 South Africa Dial-In #: 0800981148 Spain Dial-In #: 800300524 Sweden Dial-In #: 200896860 Switzerland Dial-In #: 800650077 Taiwan Dial-In #: 00801127141 Thailand Dial-In #: 001800656966 Trinidad and Tobago Dial-In #: 18002024615 United Arab Emirates Dial-In #: 8000650591 United Kingdom Dial-In #: 08006948057 United States Dial-In #: 8004518679 Uruguay Dial-In #: 00040190315 Venezuela Dial-In #: 08001627182

1 0

[Engine-devel] vdsm checkConnectivity pitfals
by Roy Golan 26 Dec '11

26 Dec '11

Hi all, VDSM network provisioning api exposes a validity check to know the newly applied changes works. The actual check is comparing the /var/run/vdsm/client.log modified time to the time when the check began and repeats that check after sleeping 1 seconds for X time (where X is connectivityTimeOut) def clientSeen(timeout): start = time.time() while timeout >= 0: if os.stat(constants.P_VDSM_CLIENT_LOG).st_mtime > start: return True time.sleep(1) timeout -= 1 return False Main issues I spot are: 1. In case the host is in maintenance, the caller of the API must generate traffic, concurrently to running api call, and then must join and sync threads to realize when all is done. see http://gerrit.ovirt.org/#change,584 2. locally calling vdsClient also modifies the client.log - we can't rely on that no one will do that during the call. 3. Failure writing to the client log will fail network provisioning! All of the above makes it not very reliable as a check and harder to call, without posing races, as client. Possible alternate solution: 1. We can try to reach the api caller socket in return, maybe use http code 100 ? 2. pass in the API a URL which the VDSM will call. could be a health-check servlet or something similar. Any toughs?

4 4

[Engine-devel] Redunant class of ValueObjectMap ?
by Yair Zaslavsky 23 Dec '11

23 Dec '11

Hi all, Do we need org.ovirt.engine.core.common.queries.ValueObjectMap? Can we use a Java map class directly instead (we had to use this with SOAP WS in the past, prior to current rest-API days)? Yair

3 2

[Engine-devel] Patches that support jboss AS7
by Oved Ourfalli 22 Dec '11

22 Dec '11

Hey, I recently worked on making the proper changes to make the engine code work on Jboss AS7, and it works now! Still needs some testing and probably some more adjustments, but it looks promising. I pushed the commits to gerrit (the first one contains most of the changes, the others are fixes and additions): http://gerrit.ovirt.org/698 (POC - review, don't submit) engine: Jboss-as7 - base commit with jboss-as7 related changes http://gerrit.ovirt.org/699 (POC - review, don't submit) restapi: Jboss-as7 - fix rest api tests http://gerrit.ovirt.org/700 (POC - review, don't submit) engine: Jboss-as7 - Fix utilities to work with jboss as7 http://gerrit.ovirt.org/701 (POC - review, don't submit) engine: Jboss-as7 - Copying the correct jdbc jar to the modules directory I'd be happy to hear your comments. Most changes there were done due to problems I encountered, but feel free to suggest other solutions. Make sure you don't submit this patch yet, as it is a POC, and other changes are needed in order to complete the work on that. These patches work under the latest AS7 version (7.1.0.Beta1b) - http://download.jboss.org/jbossas/7.1/jboss-as-7.1.0.Beta1b/jboss-as-7.1.0.… (The patches currently work only on the version above, as one jar is replaced in the Jboss modules directory to solve LDAP issues). All the versions can be found in: http://www.jboss.org/jbossas/downloads I'm here if you have questions or comments. Thank you, Oved

1 1

[Engine-devel] New oVirt-engine RPMs available
by Ofer Schreiber 21 Dec '11

21 Dec '11

Hi all, We are pleased to announce the availability of the newest release of oVirt-engine RPMs. Thanks to Ronen Angluster, these RPMs include the new "engine-setup" utility, which allows a quick installation of oVirt-engine. In order to install the new RPMs, please follow the instructions described in http://www.ovirt.org/wiki/Installing_ovirt_from_rpm The oVirt-Engine team

1 0

[Engine-devel] API: exposing used/total for images and snapshots
by Geert Jansen 21 Dec '11

21 Dec '11

Hi Michael, i remember that previously we exposed both used and total size for VM images. Right now it seems the API is only exposing total but not used. The GUI is exposing used. Do i remember this correctly? A second question on snapshots: here i think we never showed used/total, and the GUI does not show this either. Do we track this data in the BE, or would this also require backend changes? Please let me know and i'll file the right BZs. Thanks, Geert

1 0

[Engine-devel] ovirt engine bi-weekly meeting
by Livnat Peer 21 Dec '11

21 Dec '11

Hi All, No meeting this week we'll re-sync after the holidays. Livnat

2 1

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

20 Dec '11

All, I have updated[1] the ovf uploader in response to some comments in gerrit and to handle some serious Python 2.6 issues. The 2.6 version of ElementTree (i.e. the XML parser) was producing invalid XML. Fortunately, lxml is a drop-in replacement. [1]: http://gerrit.ovirt.org/#change,574 Cheers, Keith

1 0

[Engine-devel] multi-domain types in one storagepool
by 杨焦 19 Dec '11

19 Dec '11

Hi, all After taking a look at Ovirt-engine, I happen to notice that for one DC(storage pool), only one type of data domain can be attached. As far as I know, from VDSM side, different data storages can be managed by one storagepool. So, why is there such limitation? is it possible to remove such rule from front-end? Maybe there are some reasons I don't know support this rule, hope someone can show me some light. thanks Joseph

3 2

[Engine-devel] jaxb annotations
by Laszlo Hornyak 18 Dec '11

18 Dec '11

Hi! I ran into some jaxb-annotated beans in engine, and the annotations seemed to be a bit unsettled. - Some annotations are on the field, some on the getter. - I have also found a case where the setter is private, it is actually dead code. I was puzzled for a minute :-) It seems in this case jaxb actually sets the value through reflection, so the setter really is dead code. - Some annotations state name, others just build on the defaults Is there an agreement for the annotations? It would be great if we could annotate the getter always and use a proper name in the @XmlElement annotation even if it is equal to the default, so it is less likely to break at refactoring. Laszlo

3 2

[Engine-devel] shared fs support
by Saggi Mizrahi 16 Dec '11

16 Dec '11

This is a multi-part message in MIME format. --------------050004010107020802030308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I have preliminary (WIP) patches for shared FS up on gerrit. There is a lot of work to be done reorganizing the patches but I just wanted all the TLV guys to have a chance to look at it on Sunday. I did some testing and should work as expected for most cases. To test just connectStorageServer with storageType=6 (sharedfs) connection params are {'id'=1, 'spec'='server:/export' 'vfs_type'='nfs\gluster\smb' 'mnt_options'='opt,opt=3,opt' } to check with an existing NFS domain you can just spec=server:/export vfs_type=nfs mnt_options=soft,timeo=600,retrans=6,nosharecache,vers=3 I only tested NFS but I am going to test more exotic stuff on Monday. This is the patch to build the RPM from. http://gerrit.ovirt.org/#change,560 Have a good weekend --------------050004010107020802030308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body text="#000000" bgcolor="#FFFFFF"> <font size="-1">Hi, I have preliminary (WIP) patches for shared FS up on gerrit. There is a lot of work to be done reorganizing the patches but I just wanted all the TLV guys to have a chance to look at it on Sunday.<br> <br> I did some testing and should work as expected for most cases.<br> <br> To test just connectStorageServer with storageType=6 (sharedfs)<br> connection params are<br> {'id'=1,<br>   'spec'='server:/export'<br>   'vfs_type'='nfs\gluster\smb'<br>   'mnt_options'='opt,opt=3,opt' }<br> <br> to check with an existing NFS domain you can just<br> spec=server:/export<br> vfs_type=nfs<br> mnt_options=soft,timeo=600,retrans=6,nosharecache,vers=3<br> <br> I only tested NFS but I am going to test more exotic stuff on Monday.<br> <br> This is the patch to build the RPM from.<br> </font> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> <a href="http://gerrit.ovirt.org/#change,560">http://gerrit.ovirt.org/#change,560</a><br> <br> Have a good weekend<br> </body> </html> --------------050004010107020802030308--

3 6

[Engine-devel] Network features design wiki
by Roy Golan 15 Dec '11

15 Dec '11

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

4 6

[Engine-devel] short research on postgresql enums
by Laszlo Hornyak 15 Dec '11

15 Dec '11

Hi, I looked into Mike's database patch ( http://gerrit.ovirt.org/#change,500 ) today and read Yaniv's comment on it. I have seen another patches related to enums and how they are stored in the database. I made a quick test to compare between varchar and enum and the results are here: http://dummywarhead.blogspot.com/2011/12/postgresql-enums-vs-varchar.html IMO enums could be a good solution, but changing enums could be a pain under postgres 9.1. So what if we could use varchar now and migrate to enum once postgres 9.1 replaces the older installations :) Laszlo

6 9

[Engine-devel] subscribe
by Lei Li 15 Dec '11

15 Dec '11

subscribe -- Lei

1 0

[Engine-devel] http://www.ovirt.org/wiki/Features/Design/StablePCIAddresses
by Dor Laor 13 Dec '11

13 Dec '11

Hi, I read the design here and I like to make sure that the future road map will expand beyond the current scope. The current design totally rely on libvirt and does not parse the content of the PCI addressing. That's really really basic. The user should be able to specify pci slot allocation of his devices through the gui. I guess you won't be able to do that w/ the current scheme. Also, what about devices that can't be hot plug (like qxl)? You need to reveal this info to the user. Currently we have ability in the kvm bios (seabios) to automatically disable the host plug of some critical devices like the vga driver (qxl) and others. The user should be allowed to hot plug/unplug only allowed devices. You have to make your design work w/ pci bridges since we'll add it to qemu and once there is such VM (management should enable the bridge) there will be more pci devices available to it. Regards, Dor

4 3

[Engine-devel] API design and plan
by Adam Litke 13 Dec '11

13 Dec '11

Hi everyone. On today's VDSM call we discussed the requirements, design, and plan for updating the API to include support for QMF and single-host REST API. All members present arrived at a general consensus on the best way to design the next-generation API. I have tried to capture this discussion in the oVirt wiki: http://ovirt.org/wiki/Vdsm_API Please take a look at this page and let's discuss any changes that may be needed in order to adopt it as a working plan that we can begin to execute. Thanks! -- Adam Litke <agl(a)us.ibm.com> IBM Linux Technology Center

5 13

[Engine-devel] VM hibernation to storage domain
by Jon Choate 12 Dec '11

12 Dec '11

Is there any reason anyone can think of why we would need to specify a specific storage domain for a VM to use when it hibernates? Ideally we could just grab any storage domain that has space and use it for hibernation (as long a we remember where we did it!). thoughts?

3 5

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

12 Dec '11

Please find attached to this email a updated tool that will makes it easier to upload an OVF archive file to an oVirt export domain. This version of the tool has the following improvements: 1. The tool will automatically generate UUIDs for the TemplateID and the disk ID. 2. The tool attempts to outline in the help how an OVF archive should be formatted so that a creator will produce archives that are consumable by the tool and oVirt. 3. The makefile has been updated to produce the image uploader's RPM. Sample Usage: > ovirt-image-uploader.py -n 127.0.0.1:/virt/exports -t NEW-IMAGE-NAME-HERE -i -d upload ovf-tgz-here.ovf // First few lines of the help that attempt to document *how* an archive should be formatted... keith@whiplash src (master *)]$ python engine-image-uploader.py -h Usage: engine-image-uploader.py [options] list engine-image-uploader.py [options] upload [file].[file]...[file] The image uploader can be used to list export storage domains and upload OVF files to export storage domains. This tool supports OVF files created in the following manner: 1. The OVF archive must be a gzip archive. 2. The archive must have the following internal layout: |-- images | |-- <Image Group UUID> | |--- <Image UUID (this is the disk image)> |-- master | |---vms | |--- <Template UUID> | |--- <Template UUID>.ovf 3. The OVF XML file within the archive must have the following characteristics: 3.1. The Content/Name element should be non-nill 3.2. The Content/TemplateID element should have a UUID matching the name of the OVF XML file 3.3. The disk resource types (i.e. ResourceType=17) within Content/Section/Item should have an InstanceId element should have a UUID that matches <Image UUID (this is the disk image)> 3.4. The disk resource types (i.e. ResourceType=17) within Content/Section/Item should have a HostResource element should have a string in the following format <Image Group UUID>/<Image UUID (this is the disk image)> 3.5 Each References/File:href attribute should match 3.4 3.6 Each References/File:id attribute should match 3.3 3.7 Each Section/Disk:diskId attribute should match 3.3 3.8 Each Section/Disk:fileRef should match 3.4 4. The tool only supports one disk per Image Group. If you need more then you need to create multiple Content/Section/Item elements. Cheers, Keith / /

1 0

[Engine-devel] RESTAPI: optional body in DELETE request
by Michael Pasternak 11 Dec '11

11 Dec '11

Recently we asked RESTeasy to support one of our unique use-cases: - (optional) body in DELETE request e.g case 1: DELETE /api/vms/xxx <action> <force>true|false</force> </action> case 2: DELETE /api/vms/xxx and now they do allow us passing body in DELETE request what is permitted by HTTP spec., but a bit awkward from the user perspective, therefore i would like to start discussion on this where the goal is deprecating this feature and consume /force/ from url parameters instead, e.g: DELETE /api/vms/xxx DELETE /api/vms/xxx?force=true note: we continue supplying very same uniform interface and all url parameters will be properly documented in RSDL, U/G. -- Michael Pasternak RedHat, ENG-Virtualization R&D

1 0

[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