- Devel - oVirt List Archives

[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"> 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. <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> Have a good weekend </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 14 Dec '11

14 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