December 2011 - Devel - oVirt List Archives

[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