Re: [ovirt-devel] Firewalld migration.
On 28/03/17 17:58, Martin Sivak wrote: > I actually like the radical option Didi mentioned -> using Ansible for > the whole deploy flow. A simple host-deploy dir with playbooks (and > builtin roles) is something most people would understand easily. > > And it would even remove all the infrastructure burden from us, oVirt > would not be the host management solution, Ansible would take the role > and we would just invoke it when deploying a new host much like we do > with host deploy now (except Ansible manages its own ssh connection > too). +1 but some drawback (actual ansible user here): you in fact need _some_ libs on the managed hosts for certain ansible features to work (e.g. if you want to respect selinux settings on the host), so you would also need to provide these or list them as prerequisites. I understand ovirt can't just provide config mgmt solutions for every tool out there (puppet, chef, ansible, saltstack, etc.). the best approach would be, if it is pluggable, like foreman did this with it's smart proxys and plugins: https://theforeman.org/plugins/ so you could provide a plugin infrastructure and maybe write the ansible integration yourself and the community can add their own plugins like puppet or chef modules at will. If they mature enough you could even ship those (optional). I really think there would be some value in this, because many small deployments use tools like puppet or ansible, while these do not scale well for large environments, where you tend to have things like salt or chef. PS: if you want to annoy some users you could even declare a hard dependency on foreman and use foreman for the host deployment (a tool that's actually written for exact this scope), others might find this higher integration nice. I'm not sure if I would like it or not. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +495772 293100 F: +495772 29 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Firewalld migration.
Hi, just a quick note from the end user /sys admin/dev ops perspective: wouldn't it suffice if you have rules for common config management systems at hand / in the docs/ on github? I like packages the most, that don't try to own the whole system. just provide a saltstack formula and I'm fine ;) just my 2 cent Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +495772 293100 F: +495772 29 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] cloud-init metadata service
On 01/03/17 16:53, Marc Young wrote: > What feels hacky is that I have so little information about the VM i'm > running from within that I'd have a hard time crawling the API enough to > know the information I got was about the VM I'm testing against. Per my > later email the ID in /var/lib/cloud/data/instance-id is not the same that > I'd need to hit the REST API to describe I'm glad that this is this way. From a security standpoint, this would be an information leak, which enables third party users from inside the vm to attack the ovirt system. So if you implement new features in this area, I would be very very careful. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +495772 293100 F: +495772 29 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] PatternFly upgrade - how to handle JS dependencies
On 06/01/17 18:45, Vojtech Szocs wrote: > Today, we require `patternfly1` as both Engine RPM build dependency and the > Engine devel. env. dependency. > > To keep things simple, I'd like to propose the following approach: > > - create oVirt specific package, e.g. `ovirt-patternfly`, hosted at Copr, > containing PatternFly + associated libraries (Bootstrap, jQuery) which > are intended *specifically* for use by oVirt UI (hence the ovirt prefix) > > - discontinue maintenance of `patternfly1` package at Copr afaik you're also requiring patternfly1 for ovirt-engine installation, not just dev or build env? if that is correct and your new "ovirt-patternfly" would superseed that I'm afraid you would violate fedora and rhel/centos package guidelines by throwing this all together in one package? I hope I understood the scope of this correct, if not, just disregard my comment. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +495772 293100 F: +495772 29 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [RFE] treat local NFS storage as localfs
On 21/12/16 11:44, Pavel Gashev wrote: > Hello, > > I'd like to introduce a RFE that allows to use a local storage in multi > server environments https://bugzilla.redhat.com/show_bug.cgi?id=1406412 > > Most servers have a local storage. Some servers have very reliable > storages with hardware RAID controllers and battery units. > > Example user cases: > https://www.mail-archive.com/users@ovirt.org/msg36719.html > https://www.mail-archive.com/users@ovirt.org/msg36772.html > > The best way to use local storage in multi server "shared" datacenters > is exporting it over NFS. Using NFS allows to move disks and VMs among > servers. > > In order to improve performance, disk I/O bound VMs can be pinned to > a host with local storage. However there still is a performance > drawback of NFS layers. Treating a local NFS storage as a local storage > improves performance for VMs pinned to host. > > Currently setting up of NFS exports is out of scope of oVirt. However > this would be a way to get rid of "Local/Shared" storage types of > datacenter. So that all storages are shared, but local storages are > used as local. > > Any questions/comments are welcome. > > Specifically I'd like to request for comment on potential data > integrity issues during online VM or disk migration between NFS and > localfs. > Just let me say that I really like this as an end user. Hope this get's in. This seems less overhead than a complete hyperconverged gluster setup. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +495772 293100 F: +495772 29 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Request for oVirt Ansible modules testing feedback
Hi, which ovirt versions will these ansible modules support? only 4.x or also 3.6? This looks very promising, because I'm already automating template provisioning for ovirt via ansible (parts of it) and it would be cool to also make the actual template creation of the vm part of the ansible playbooks, but I can't switch over to ovirt 4 yet. I will try to get some time to test this out, if it supports the older version. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +495772 293100 F: +495772 29 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] performance improvements and gwt-rpc switch
On 01/12/16 16:27, Greg Sheremeta wrote: > I'm working on 3.6 now. My expectation is that we can speed it up a bit, > but it'll never be as fast as 4.0.6/4.1. Unless we decide to commit time to > it, in which case we've proven that it can be done, it's just a matter of > resources. Sorry for getting a little offtopic, but I'm really confused: It was stated somewhere that 3.6.7 will be the last release, and there has not been an official 3.6. release since then, but otoh there seems to be ongoing work on 3.6, see: https://gerrit.ovirt.org/#/admin/projects/ovirt-engine,branches there are branches for 3.6.8 and 3.6.9 already. Will there be future 3.6 releases, or not? Or is this just work for downstream RHEV which will get support much longer? It would be nice if someone could clarify this. Personally I really would like to see additional 3.6.z releases, especially with these performance improvements around the webui. Thanks and sorry for hijacking this thread. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +495772 293100 F: +495772 29 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] VDSM changes Linux memory dirty ratios - why?
On 30/11/16 09:13, Yaniv Kaul wrote: > Thanks, but it really makes no sense to me. The direct IO by the VMs is > going to a different storage than what the host is writing to, in most > cases. > The host would write to the local disk, the VMs - to a shared storage, > across NFS or block layer or so. Moreover, their IO is not buffered. > There is very little IO coming from the host itself, generally (I hope > so!). > > Partially unrelated - the trend today is actually to put NOOP on the VMs - > the deadline is quite meaningless, as the host scheduler will reschedule > anyway as it see fits. > Most likely it is also a deadline scheduler (but could be NOOP as well if > it's an all flash array, for example). Therefore there is no reason for > anything but simple NOOP on the VMs themselves. > > In short, I think it's an outdated decision that perhaps should be > revisited. Not urgent, though. > Y. I know it's not the most cared about usecase but I'd like to add that this might affect local storage domains, which I happen to use a lot, and maybe others too. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +495772 293100 F: +495772 29 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] VDSM changes Linux memory dirty ratios - why?
On 30/11/16 08:48, Martin Polednik wrote: > It's not really irrelevant, the host still uses disk cache. Anyway, > there is BZ[1] with a presentation[2] that (imho reasonably) states: > > "Reduce dirty page limits in KVM host to allow > direct I/O writer VMs to compete successfully > with buffered writer processes for storage > access" > > I wonder why virtual-host tuned profile doesn't contain these values: > > $ grep vm.dirty /usr/lib/tuned/virtual-host/tuned.conf > vm.dirty_background_ratio = 5 > > [1]https://bugzilla.redhat.com/show_bug.cgi?id=740887 > [2]http://perf1.lab.bos.redhat.com/bengland/laptop/rhev/rhev-vm-rsptime.pdf Could you share [2] with the wider community? This would be awesome! -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +495772 293100 F: +495772 29 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [RFC] Communicating within the community [was Re: [ovirt-users] I wrote an oVirt thing]
On 29/11/16 15:54, Martin Sivak wrote: > I actually checked the oVirt 4.0.0 and 4.0.5 release notes and I do > not see anything mentioning ovirt-cli or REST v3 deprecation. This > will (removal of RESTv3 support) affect the optimizer and quite > possibly even hosted engine setup. Hi, this seems to indicate that even core ovirt devs do not know about every feature which gets deprecated. Maybe this could be solved by sandro's suggestion to at least create an BZ for each deprecation. I would agree with that, but also like to propose an alternative way, because at the stage of bug creation the deprecation is already set in stone and can't be discussed further (I fear). So my proposal would be to mail to the devel list at least the proposal: "I/we want to get rid of feature/implementation X, use Z instead". This would give developers and users enough time to engage with the community, replacing dependencies or start a discussion if removal can't be done later. A clear deprecation guideline would also be helpful, I guess. Something like: Features will get marked as deprecated in release X.Y and removed in X.Y+2 (or whatever number you might chose). This would allow for much better preparation in the community and lead to less unpleasant surprises. HTH & keep up the good work! -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +495772 293100 F: +495772 29 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Heads-up: moving Libvirt xml creation to the engine
Hi, very first question which comes to mind is: will vdsm hooks which alter the libvirt xml still work? I believe this is a much used feature and if it would not work anymore out of the box this would be a huge pain in upgrading existing systems. furthermore I don't really see the benfits when you generate the xml in engine: you still need to alter it in vdsm as you write, to fill in host specific things like storagepaths anyway, meaning you have to maintain twice the codebase _and_ coordinate between the two of them, so nothing goes wrong if one project changes something in the xml. but this are just my 2 cent :-) -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +495772 293100 F: +495772 29 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Alternatives to automatically move bugs to MODIFIED
On 17/08/16 13:25, Nir Soffer wrote: > Only the owner of the bug knows if the all the required patches are merged > and backported to the correct repositories. Why not just set needinfo on bug assignee when all linked patches are merged? this would ensure that missing patches get uploaded asap and once this is done and all patches are merged you can clear needinfo and move the bug to modified manually? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +495772 293100 F: +495772 29 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] problem setting up bonding via rest in ovirt 3.6.6.2
Hi,
I'd like to setup host network in the following way:
I have 4 interfaces: eth0, eno1, eno2, eno3
ovirtmgmt network resides on eth0 and is working.
Now I want to setup a bonding with the slave interfaces
eno2 and eno3 via the hosts "setupnetworks" function:
URL:
https://engine-fqdn/api/hosts/9cdcc85b-dd87-4dcf-9275-b993ee5b5e9c/nics/setupnetworks
Request:
{
"modified_bonds": {
"host_nic": [{
"name": "bond0",
"bonding": {
"options": {
"option": [{
"name": "mode",
"value": "1"
}, {
"name": "miimon",
"value": "100"
}]
},
"slaves": {
"host_nic": [{
"name": "eno2"
}, {
"name": "eno3"
}]
}
}
}]
}
}
Response from ovirt-engine:
Incomplete parameters
Action [hostNics] required for setupNetworks
When I look at the rsdl docs this seems perfectly fine.
I tried google with this error condition but it didn't return anything
useful unfortunately.
Your help would be greatly appreciated.
The official RH docs also do not mention anything else:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.6/html-single/REST_API_Guide/index.html#Multiple_Network_Setup_Action
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.6/html-single/REST_API_Guide/index.html#Bonded_Interfaces
Also this tool doesn't seem to mention anything else:
https://jhernand.fedorapeople.org/ovirt-api-explorer/#/services/host/methods/setup_networks
--
Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator
Mittwald CM Service GmbH & Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +495772 293100
F: +495772 29
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Killing XMLRPC on master
On 22/06/16 10:39, Michal Skrivanek wrote: > bypassing vdsm for mom things is a good idea, but we need to make sure we’re > not killing the rest of the system Wouldn't that mean you need the whole authentication and communication code duplicated to mom? or is it already in there? from a sysadmin perspective I would like to keep the needed ports to open between engine and virt-host on a minimum. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +495772 293100 F: +495772 29 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] oVirt 3.6.7 Fifth Release Candidate is now available for testing
On 22/06/16 09:50, Yaniv Kaul wrote: > It's harder to do for minor releases, as they don't have distinct target > milestones as major versions do. > For example, 4.0 has 4.0.0-rc1, 4.0.0-rc2, 4.0.0-rc3, etc. > 3.6.7 doesn't have that. > Y. But there are no special categories for the 4.0.0 rcs as well? https://www.ovirt.org/release/4.0.0/ There used to be tracker bugs for every RC IIRC, from which you could extract at least the blocking bugs for each RC. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +495772 293100 F: +495772 29 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] oVirt 3.6.7 Fifth Release Candidate is now available for testing
Hi, while I appreciate all the work that has been done for this release, please let me add some critic: on the old website it was pretty easy to track down what exactly changed between each release candidate in terms of closed BZs etc. This is not possible anymore. Are there any plans to restore the previous functionality? Are there technical reasons this information is not mentioned in the release notes anymore? kind regards Sven signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] oVirt 4.0 and fedora support
On 21/06/16 09:19, Yedidyah Bar David wrote: > Hi all, > > oVirt 4.0 should be released real soon now, and also Fedora 24. > > Currently, there are several different issues with oVirt on fedora 23, > both on engine side and on hosts. > > We currently intend to release 4.0 without official support for > fedora, and hope to manage to stabilize things enough after Fedora 24 > is out, so that oVirt 4.0.1 will support it. > > Comments are welcome. > > Best, > You should announce this on the users list. In the past there where some users actually using fedora for deployments. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +495772 293100 F: +495772 29 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] oVirt 4.0 Nightly repo
Hi, first thanks for this in depth and long explanation. I'm actually already aware of what you just explained. But I'm a long time user, I guess, so I had plenty of time to get used to all this. But you didn't factor in other important things like: which datacenter or cluster version does include feature X (e.g. support for el6.6, el6.7 el7.0, etc). this is further complicated by the fact that someone packages vdsm for el6epel, but apparently in a backwards incompatible version for older ovirt releases. e.g. the current version in epel for el6 is: vdsm-4.16.20-1.git3a90f62.el6.x86_64.rpm so you have to blacklist this if you run an older engine and happen to need some other packages from epel. I honestly don't know really why vdsm is included in epel at all. In order to use it, you need an ovirt-engine with the necessary repository anyway, which contains vdsm in the correct version, so why would you want to pull vdsm from epel? I don't want to complain a lot, but I hope in the future we'll have fewer backwards incompatible changes, so newer vdsm can talk to older engines (even if not all features are supported). My general impression is, that ovirt becomes more stable, the more releases come out. So again: keep up the good work! :-) -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +495772 293100 F: +495772 29 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] oVirt 4.0 Nightly repo
On 14/06/16 17:34, Vojtech Szocs wrote: > Hi, > > ovirt-engine-dashboard is currently built from master as well. > > We should probably create a stable branch, e.g. ovirt-engine-dashboard-1.0. Hi, speaking as an end user (mostly): please not yet-another-versioning in the great ovirt project. I'm already having severe issues tracking which engine versions works with which vdsm version, let alone track which datacenter and cluster version within each engine version works with which vdsm version and which features are (un)supported. Please don't add another different version to the already far to complex equation. I'd suggest you take the same version number as the supported ovirt-engine, you also should adjust release cycles of all the subprojects where possible (I know that doesn't work always). this would make every users life make so much less painful. keep up the great work! -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +495772 293100 F: +495772 29 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Add a local drive to Ovirt
On 18.04.2016 17:07, Bryan Hughes wrote: > All, > > I am trying to add a physical drive to Ovirt. For instance, my physical > machine has 3 extra hard drives attached and I want to add it directly > instead of through Gluster or iSCSI. Is this possible? > > I tried using POSIX by creating an xfs filesystem on /dev/sde1 and tried to > add that as a POSIX datastore but it fails in trying to mount the filesystem. > > Any help is appreciated. I guess you're looking for this feature: http://www.ovirt.org/develop/release-management/features/storage/mixed-types-data-center/ however you need to do this via a shared DC type as mentioned in the above link. Some bugs tracking this feature are mentioned here: https://bugzilla.redhat.com/show_bug.cgi?id=1134318 However I'm not quite sure if this is fully implemented yet.. kind regards Sven signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] v2v: download/stream disks via Libvirt API
On 07/04/16 10:14, Shahar Havivi wrote: > Any suggestions/notes? > > > Very cool feature, but I have a question: Would it be possible to tunnel this through ssh or other TCP Connections over the network? Because in many cases you don't want to stream sensible data via unencrypted connections or you just have ssh access to special servers. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +495772 293100 F: +495772 29 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Ovirt API Import OVA
On 10/03/16 15:24, Juan Hernández wrote: > On 03/10/2016 02:25 PM, Sven Kieske wrote: >> On 07/03/16 09:47, Sven Kieske wrote: >>> On 06/03/16 22:04, Arik Hadas wrote: >>>> Actually it depends on the content of the OVA file. If the OVA >>>> file was generated by vSphere (export VM) then since oVirt 3.6 >>>> you can import it via the webadmin (virtual machines tab -> >>>> import -> select OVA as the source). Note that you'll need to >>>> copy the OVA to one of your hosts that is installed with >>>> virt-v2v for that. This action is missing in the API. >>> >>> >>> Hi, >>> >>> is there already a bug tracking this missing feature for the rest >>> api or should I create one? >> >> Ping? >> > > As far as I know there is no such RFE, please open it. > Here you go: https://bugzilla.redhat.com/show_bug.cgi?id=1316854 PS: It took me a while to find the rest api component (under ovirt-engine product). In my opinion it should be selectable on the "product" level, just like the SDKs. What do you think? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +495772 293100 F: +495772 29 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Ovirt API Import OVA
On 07/03/16 09:47, Sven Kieske wrote: > On 06/03/16 22:04, Arik Hadas wrote: >> Actually it depends on the content of the OVA file. >> If the OVA file was generated by vSphere (export VM) then since oVirt 3.6 >> you can import it via the webadmin (virtual machines tab -> import -> select >> OVA as the source). >> Note that you'll need to copy the OVA to one of your hosts that is installed >> with virt-v2v for that. >> This action is missing in the API. > > > Hi, > > is there already a bug tracking this missing feature for the rest api > or should I create one? Ping? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +495772 293100 F: +495772 29 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Ovirt API Import OVA
On 06/03/16 22:04, Arik Hadas wrote: > Actually it depends on the content of the OVA file. > If the OVA file was generated by vSphere (export VM) then since oVirt 3.6 you > can import it via the webadmin (virtual machines tab -> import -> select OVA > as the source). > Note that you'll need to copy the OVA to one of your hosts that is installed > with virt-v2v for that. > This action is missing in the API. Hi, is there already a bug tracking this missing feature for the rest api or should I create one? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +495772 293100 F: +495772 29 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ANN] oVirt 3.6.3 Fourth Release Candidate is now available for testing
On 01.03.2016 10:32, Sandro Bonazzola wrote: > No it isn't intentional. a bug in the migration tool dropped all bz > references ( https://github.com/oVirt/ovirt-site/issues/98 ) > > > >> I'm talking about the "bugs fixed" section. >> >> furthermore it is not anymore updated what exactly was fixed in the last >> RC etc. >> >> I found the old format way more helpful. >> > > I agree. I'm trying to fix the release notes for today GA. Thank you very much, it's much appreciated. Can't wait to test the GA in my dev system, but this will likely be not this week, because I got higher priorities from my mgmt. kind regards Sven ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ANN] oVirt 3.6.3 Fourth Release Candidate is now available for testing
On 24.02.2016 15:09, Sandro Bonazzola wrote: > The oVirt Project is pleased to announce the availability > of the Fourth Release Candidate of oVirt 3.6.3 for testing, as of February > 24th, 2016 > > This release is available now for Fedora 22, > Red Hat Enterprise Linux 6.7, CentOS Linux 6.7 (or similar) and > Red Hat Enterprise Linux >= 7.2, CentOS Linux >= 7.2 (or similar). > > This release supports Hypervisor Hosts running > Red Hat Enterprise Linux >= 7.2, CentOS Linux >= 7.2 (or similar) and > Fedora 22. > Highly experimental support for Debian 8.3 Jessie has been added too. > > This release candidate includes updated packages for: > >- ovirt-engine > > >- vdsm > > >- ovirt-hosted-engine-ha > > >- ovirt-hosted-engine-setup > > > > This release of oVirt 3.6.3 includes numerous bug fixes. > See the release notes [1] for an initial list of the new features and bugs > fixed. > > Please refer to release notes [1] for Installation / Upgrade instructions. > A new oVirt Live ISO will be available soon [2]. > > Please note that mirrors[3] may need usually one day before being > synchronized. > > * Read more about the oVirt 3.6.3 release highlights: > http://www.ovirt.org/release/3.6.3/ > * Get more oVirt Project updates on Twitter: https://twitter.com/ovirt > * Read more about oVirt Project community events: > http://www.ovirt.org/Upcoming_events > > [1] http://www.ovirt.org/release/3.6.3/ Is it intentional, that all links to BZ have disappeared from the release notes (afaik they where there on the old wiki site, but it's late, so maybe I'm wrong)? I'm talking about the "bugs fixed" section. furthermore it is not anymore updated what exactly was fixed in the last RC etc. I found the old format way more helpful. Thanks Sven ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [vdsm][virt] what's new in virt (20160216)
On 16/02/16 15:35, Francesco Romani wrote: > * Francesco: the `convirt' module mostly (support containers with > libvirt API) plus cleanup Hi, I assume this is a self written module for ovirt/libvirt to manage containers? Is convirt the real name of it? Because there seems to be another open source software "convirt" for kvm/xen management? https://www.convirture.com/ https://www.convirture.com/products_opensource.php maybe rename it, to avoid trademark conflicts? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +495772 293100 F: +495772 29 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] outdated quickstart guide
On 29/01/16 16:17, Nir Soffer wrote: > This is a wiki, you can update it. yes I know, i even have an account, but just no time atm. so I figured maybe someone can do it quicker. I also noticed that el 7.2 does not get mentioned as a supported platform, just 7.1. I will edit all places when I find the time, maybe next week :) -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +495772 293100 F: +495772 29 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] outdated quickstart guide
Hi, I'm just installing ovirt 3.6.2 in a new dev setup and noticed that the quickstart guide still just mentions 3.4 and 3.5: https://www.ovirt.org/Quick_Start_Guide#Install_oVirt_Engine_.28Fedora_.2F_Red_Hat_Enterprise_Linux_.2F_CentOS.29 maybe this can get adjusted? PS: Any ETA for ovirt 3.6.3 yet? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +495772 293100 F: +495772 29 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.
On 26/01/16 16:29, Yaniv Dary wrote: > Hi, I wanted to bring this up to get feedback on this proposed > change. VDSM doesn't align to other project under the oVirt > umbrella like ovirt-engine, ovirt-node, ovirt-guest-agent etc.. > > I suggest for ease of use and tracking we change the versioning to > align to the engine (4.0.0 in oVirt 4.0 GA) to make it easy to know > which version was in which release and also change the package > naming to something like ovirt-host-manager\ovirt-host-agent. > > What do you think on this? What do you think the name should be? Hi, just commenting from the end user perspective: version align: +1 ovirt-prefix: +1 new name(suffix): host-agent: don't know, I think it crashes a little with ovirt-guest-agent (already used). This might confuse some users, or what do you thing? maybe ovirt-host-manager suites it more (to differentiate between vdsm and guest-agent)? I personally don't like the work "manager" for a software. in the end it's your decision and I could also get along with ovirt-host-agent. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +495772 293100 F: +495772 29 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [RFE - doc] Repositories not listed on all-in-one feature page
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, just a side note to get a little more attention to this topic (sorry for thread hijacking): as I just learned the AIO deployment is already deprecated in 3.6. according to: https://bugzilla.redhat.com/show_bug.cgi?id=1282798 but as already mentioned there, I do not find any information regarding this decision in the release notes. there still seem to be some obstacles to reshape ovirt into a true open source project where decisions are made through the community in a transparent fashion. see also the mass closing of bugs marked as "RFE" without further explanation. - -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +495772 293100 F: +495772 29 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhaus en Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJWTH8IAAoJEMby9TMDAbQR06UP/2t2yKzsUCL15iOyXEVB2y7l onHHLZ27pJCbYxeoq3k11swCkw6+wugKfPf5Fa8OyLVkD8viqBVRIW8JXTRF2XmL oD1UoIi1GI4HCATcuJaop1yP0icgo8cxufA3R8VM7js0en1Z3qMCEKSg89JT9QMM 2vx9Bk0ABideKkubNXVRhzgLrt3maEhbXQC8xshZNnsoee2sFlFjbl61HZxbaPaG jPkWTNoRUE7kFPqjBBWVB0t0OhfGQxQZ9ALxlfncxxnLiwydo6vhCYtD8P6v0nYP Nf3Ey+VZZteP15kDKz+GUO4UDwa8CqW7vYkTeX4VJigartL6bzhfvf3htBhDS2/Q Ww4VTGmfSIodYk7lI7GyVi6uFBDXRvtmYsgkTaD1RlH7Oxa5O3RoQmAqXf4MHqwS wQAqfZekqlfpoS7Nm0A9nePwO/c1h1iEUsKjfj2oh/EYiad/lKBYpzpoRDWmHv8P uE2XIjUSQ0tPQm8NRF874scHtXkwV4RzN8//WVwl7yrqXMqESbKA9xcNxAYhTQ4y BTR3QQDe3xMiFTy4ylaoZPb83dVMWhCSifJEv+Yrd+hSW1W1J5FtNN7bherEUCtj nKp+FiyJrHOpxNgc0VCtQzpJ+eJ5NeedG8c6B2RArcxHx6nCk/+oV1KI8mYEvaEa wkjJJrsxGI2bIuxDL9Wy =PYHq -END PGP SIGNATURE- ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] [QE][ACTION REQUIRED] oVirt 3.6.0 status
On 02.10.2015 13:19, Dan Kenigsberg wrote: > Annoys automated QA, but not seen in manual checks. I'm not sure it > should block ovirt-3.6.0. I'd love to hear if a lot of ovirt users use > automated scripts with no retries to setup host networking. Yes, of course I do. And I don't see a reason to retry a failed automatic setup automatically. this way lies madness. kind regards Sven ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] VM won't start because of -incoming flag after upgrading to alpha-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/07/15 09:26, Francesco Romani wrote: > ... AFAIR, in the patchset which is part of qemu-kvm-ev, a lot of > devices are disabled for security/safety/auditing reasons, and > new, stable machines are added (rhel*). Thanks Franceso and Michal for clearing this up. I really thought that the only technical difference is live migration support, I didn't know that there where further tweaks to qemu-kvm-ev. - -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +495772 293100 F: +495772 29 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhaus en Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVnNwnAAoJEMby9TMDAbQR7xUQANjTJHwEuLIGyMuaGtl8AnhP cjeOfmbc7858vxZ6PMmLd1xruds+XbOh1d/7h3mpEV8rYkJyRvXHUFvzdnAvsqXP u/Ml6HY7zis+1ucrrAScZGb7javZohY1nnoG6+hqzm85IKc9SMLu5IeKPfZslFAj I6taYvxl9/djZnp1Mbo0E1NyNqpriGHySZSI9+3cntJFU8eZysQmflBjxkQlsaI8 fIpmLDxFSWVxnttMlWhDkP0tVPfsr3IkVTpi1UwGur9P8gp3S1bH7W1FWWUUpwxj K3EOVgMVf+av8syEsfmn9BGXkYqxrwTaVkr0yY4P0nknc+Qqn8AGZGmfLhsH6F6L UjDDDO81wNUaFNBFlhF9j0XdiM7NF6H0vBQmzxGmPJ68sP/4cK7qdD4H3ZCKqmEm iXfX9jkMEI1abOoAOILcNP3IiwygahkOyUFp++CTeu9MkuaGwLQ0758qXdSTicCv m+yjqd2BPUhiz7nZQC55PBcjZqLriPqHjF+Z8Ys02Fevljvi2vf2anAsPBqy7Mbv Lw85au30g6TQbiOWDxvWhusfzt5ksLkTLS8MWFJCXnQS8moK1BLqfup83hfTXR4Q urH661yc/BjR8CQfnNh8pa+RoAVshmyXnY3Rd+5zcCqoupe4UYRRbxTBGVJzILWp vcfLIsnvsu0DsZApjeOK =YZ2e -END PGP SIGNATURE- ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [!!Mass Mail]Re: VM won't start because of -incoming flag after upgrading to alpha-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/07/15 13:36, Francesco Romani wrote: > but if you suspended on qemu and resumed on qemu-kvm-ev, or vice > versa, then I'm not sure this flow is supported (AFAIR, it isn't). I wonder why that should not be supported, afaik the only difference between qemu-kvm and qemu-kvm-ev is the enabled flag to allow live migrations. I can't see why this would introduce a flag of "-incoming" on the qemu command line. is there a technical reason why this is not supported? or is this just a "you moved from binary name a to b, so it's not supported" case, no matter the almost 100% exact same content within those binarys? - -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +495772 293100 F: +495772 29 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhaus en Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVnMx/AAoJEMby9TMDAbQRxV8P/0Zy/nrMG6acKGX34IcMaveL 4l7SqJktjk/i/F520B7D08Ub6iZKsTMP4IrK2ZGV/uF11OfE8ERG3xxKxdAvymES RV+NoBJWWuZHX/6twF8caUqLopnun6q76gHgGQg0ynnECOxlgbnpKE1uLuHF2QZM sS2FlLGC8Zm7ycs+I+/M3ANrV8zXykud1OCl4Oj8Z3wn0lSa8+p4rXrfARs0yamO 4PKwvMJU9jYwf/ZhGO0z2+Qy9ZXofSt/G8OLljGnQlmwzUQvc/oNiENTmh3q+BwB 6/8GSALaAhnHL11VPqB26Os/0+HNp1DgH2mVoFGUa4NhxhVozyWu2Efh73p0Of0I 4lZyxsoUaCdAJg2omC7RCB8DKFZwKFmBfRUGrLtivUmAfpm7oaGV+t+YJaYO+/Fx oabApAHDTJeNA3Zq/QshnwfWg2jpbLBXIO8plJ2Ygwyi7jzgxK+WmUhuEAcm8Ab5 l6kp3ctnnhJW/VErhHnzVDtNHSEUT5c16JcwQniob4haRdtK9ANTqnUbwhjq+K7Q yqbSBiHvZ6LBkXBN1yFekEzFuzQFF954DQP4k/l5BAiJ3o9F/Abk5HZtzf3AeTG4 cL6fXOfrgZAv6iaKogNsETDj9guaqVzrr6FqG0hnGanVNxnwVz2ew4cecxcTF5j/ 777ezRh/zBRpV5Jufsrb =uccx -END PGP SIGNATURE- ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Shared gluster storage domain for templates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03.07.2015 22:31, Christopher Pereira wrote: > Hi, > > I'm trying to setup a gluster data storage domain exclusively for > templates (read only) and share it among different geo distributed > ovirt data centers. I believe this is a common requirement. Do you > know if there is a clean/efficient way to do this? > > My experiment: > > I geo-replicated the templates storage domain in order to keep a > local copy on each data center for faster new VM instantiation or > thin template provisioning. The problem I faced is it's not > possible to import a replicated storage domain when the original > Storage Domain UUID is already registered in the same Engine > installation. A workarround was to detach the original SD (from > Data Center 1) and attach the replicated SD (on Data Center 2)...or > use another Engine installation. This works, but still requires to > detach and reattach the storage domain. > > Is there anyway to copy a storage domain or change its UUID? I > guess I can change the Storage Domain UUID (dirname and > dom_md/metadata), but I'm afraid of the multiple references inside > the binary file 'dom_md/ids'. > > BTW, using a gluster replica-n volume seems to be the cleanest > solution because this way Engine would only be showing one single > templates storage domain (ideal). The only reason I didn't go this > way is because it is not designed between geo distributed data > networks. This is somehow related to my old bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1130090 In short: ovirt has some places where it wants a "name" to be unique instead of using the UUID. also it want's this to be unique system wide, instead of a more sane and flexible approach like data center wide, or cluster wide unqiueness. It would also be a nice RFE to have read only storage which can be attached to multiple DCs at the same time. This already works for ISO domains, so you should be able to add the functionality to also use this as a template source. But maybe all this pain will go away when there are no more storage domains. btw will this feature make it for 3.6 or later? I know decommission of master storage domain is suited for 3.6: https://bugzilla.redhat.com/show_bug.cgi?id=1185830 kind regards Sven -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQGcBAEBCAAGBQJVl6/xAAoJEAq0kGAWDrqlzG8L/0+OS+xwpzIvQ7NtRkYQ0uCR NkHTk8P0svq6ehfa6ZiB1Pwym+EVWaF+uwGLuyE3zDPiAkhfGmfNDqkbL78k25vp zDFQUMqxgP/1WhUkcapp2IwqliIUPrXv5HY+ODOyOLE8B0ImeYhQSFAkMEJmPInJ M4lqxULOfXujE7oqMevooIgAxhFxD3cU1zLqEHcXfNBITcYKSqGvRJqt5+8TKlz/ wm3UpCb8/Ohc6YkZJdWINv4RNoKSYXnQv9BojGzABVIULYUelaPmybKCU1aBXh/m vAVLXP0JSn+DNw0vniRdIOYeRaDEBy9hM1lJGm+SL8IqnSNrS3h5WzspfWSZ7Wz2 KMIV3971Q9GAfxcQIUHkrLMVwr9nY7I1tKid3K8LtMiJ+MsxoYkO6yn2yp12OZyt wFMhTFqsjjc/T7ncDDDMGvk4AgOMrDRF5VgFYF/MZEXmGqFaCa3PE+Pnnfoz5hMo /+kVnNqM7MMbA+KTMdWqn030c7sDmkQ5+Qga5eJjUQ== =3W7z -END PGP SIGNATURE- ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] trouble with already existing mac address in database
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, jhernand was so kind to resolve this for me and asked for a mail to devel, because some people might be interested in it. so here it is: situation: you removed a vm somewhat dirty from ovirt by deleting it in the database, now you want to reuse it's mac address, but ovirt won't let you do it, because "Mac address is already in use." At first I thought I had not deleted all entries regarding this vm, but even when I did a dump of the whole engine db and grepped for the mac it didn't yield any results, so the mac was not in the db anymore, yet ovirt complained. what helped, was a restart of the engine service, because ovirt seems to cache some values in ram, like macs. so in case you got trouble like this, just restart the service. I wonder if it might be worth an RFE, so engine checks from time to time if values in ram are also in the db and if not cleans the ram? thanks again to jhernand for the (somewhat obvious) solution! site note: ovirt-engine is a really fast restarting service, pretty cool. - -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +495772 293100 F: +495772 29 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhaus en Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVlmDNAAoJEMby9TMDAbQR29kQAMyjBZh7RBxMRqoCp5+66rzB oZIv//v4d/y6cDypbFGJlC4k7N5EMNydZ3odl54pbnuOY806YFvnotyh5TT7xalH LLAaxz9oAUSod70sqBZX8A45mMioRR/MERyPyozEZn+YJuFYjhsAVjH1y75BQnhN NBqwpvmmxCMFBhLKpY4NK/oklFKZU8lDW0fuQr4oRGC0ngF0l13+QoC4OwNeYZlo OhECWP9yTIBpYJzSDTeaZCFHZ9bWG9ggL4ahwBbZ7w1AoB7gWAihV3kwlDIXGkql kgp/6xjPmqHrpeyB1dBb7bUzfLpuuN0lzUJAKcpvPU9p+n3ghq8zHMyJJOgMj6CX LpV7rvI5zBPnKbTg3HfFJUlFeb3rrasgJleW8FdDqUiuVpJ8DZr9vzx1HM6voNHW SQj/ZEKe5NNrHJW16djAhkemeT0/htsGF53xrWNPbeHiGky887ivhxhQ8DQ0B/4w Dcv/n4qKPJKCIUeQqGfXkkPpyn8hELysKpY1PIhjM/PXwEWWBFk0oGoNHt7enDaG VGuREioCfCasq4SFgbbw51+B0aQdQ1vYtt0rL8HNhVfl/RTlsZdSV474Dc8Or+Nb 3uxYo1kQrqZtYFCV/UchBzrAsqQLzq288XRFYPpoQAGyiSFSF+iMvwX1VEbiu1GF +90PfHwAV1ZDdjQ3sGd7 =spTC -END PGP SIGNATURE- ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Devel Digest, Vol 14, Issue 21
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/06/15 08:13, Adolfo wrote: > Allon, Amit, can we retarget bug 1110798 to the next 3.5.z? Looking at the BZ and the gerrit commit you can see the code is already merged in the 3.5 branch since May 17. So it should get included in the next 3.5 release. HTH - -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhaus en Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVdqNLAAoJEMby9TMDAbQRlYUQAI5TO0cKCkJfar30dQSYIH+D jtBP25GJ03VUQ0VBe2VEKx6WE9jaJVOyV+hH7VAsmPvaKk4FRGz03KcCxbL96Q6m A8KAHW00XV9/fZSrMmURiFPLgtvxJDNw+IrTPJMu5vsFSiUh0HhVWUwALISaWzU9 yM31cFyazmS2dYxmWBud5J5Qz+y2Zn+mxml7GP0IOuDJ2bjm7UCd7bgylkJfcN0O Nb3yohxwn3dQDyD0HWOH31hKDGJV86OJEumMHs1MrpW84MYrI+cJMG29VFGbfR0a FwEqMCQ/A0jiwA6Rs1Ifk9JD8h0ldffEZCD+YKGSDjj+A30XW2+jNYxbcnuHSw15 CKhI0EeqEN3rKKFpXcVdnhbJHDjk5m/HLzdD27vw8u1EAnM6+OXU+Qk3Rj5ueNmO WkQGtQk4c75+CFFfGXHfEFYMhM15h+QXfRvcYBkA59RBDGZIbffOH0YUblBliqGw qxUIaUXC65d6Gq/vrtcE7cCRKatu9bIE//Angl2za0M09Hq4lh0LjSmFsayOH7pO MvVyIP775VzgNQVZYdpAJVGpznqqrZ86AJc0jevKKp6G18id31li+OJvoWdDZZwv gvRW+JBTVGcAzFSz95D0KfD/R8E798hWW3AfuwlKRTlDSzy4G1rplSgg633vJ5r3 Gnuex7Lkh7lR+fg32teF =zAEa -END PGP SIGNATURE- ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Automated builds and releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05.06.2015 14:06, David Caro wrote: > > Hi everyone! > > > In an effort to improve the project workflow and ease the > maintenance and improve the quality of the project releases I want > to propose start working towards automated builds and releases, the > main ideas are the following: > > > * Stop building differently for release and non-release: - Building > only once, testing what you build and release what you test - Don't > use two different version strings, one for testing and one for > release > > * Automate the build process, and the release process, directly > getting the code from the repos (no manual build tarballs) > > * Adopt semantic versioning, it's a lot more meaningful than the > current scheme and fits very well with the above points > > > > This will ease and lower the maintenance and the extra work > required by maintainers, release engineers (sandro) and infra > itself by making releases as easy as hitting a button at any time. > That will allow us to lower the time features and fixes get to the > users, and deliver packages and builds that have passed through all > the tests we have, instead of rebuilding on another env, at another > time, by someone else, and passing only manual testing. > > > wdyt? > a big +1 from a community member, not so much a coder :-) keep up the good work! kind regards Sven -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQGcBAEBCAAGBQJVcZpWAAoJEAq0kGAWDrql3PcL/jRFRr+dg7gpSFYM9jWWMb06 o4DOfjRmDga0YCPLoHQk1/tZwAHkJqMLSrkrkWk2RWYK9dR0ckaWJ5CIA8OuNA5g et+KCVpVnC5FYwbR1Joo5I3ODgSkPONDsE9JdBn1ClT0JRs4U81Wb5ludZNYdtBo Zxu9va86mPIJNd2B6RDc990XOd0HvTTGxfYtbmiBCwGxKlS6imNkTPUW6HzCVC2w ofL4qLGy9JiV0bHKjdOX1K713BDtqtTXTtiME/tvUqhFJRWSQFdP182ftCEMa/xF I5eGCTc17JDKg3PHbufNCdmQevXuk0PpeFX2QbgRxuGfqkL04RsDW8iTyMfo9men /FImHViJhWkum5xWCZJiNDIPvoNkdKcQndu6J6jWbSuEfrUTPG99etb3VL9/dz4L XM8upOrNnpcVkL1x3SWFUYLs739LEJEaNlZ0R3hWtUWv1D8iu1IjQ2xxWbpjcOAv ccvwyXGV12Uon5F8DWb24y6CQb53WhsBVKY5blYH+Q== =f8Ru -END PGP SIGNATURE- ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] API for executing commands on node?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03.06.2015 08:12, Christopher Pereira wrote: > Thanks Oved, but I need to script and trigger the remote commands > from a centralized script (not through the UI). In this case, I > guess my best option would be to use SSH + keys. why don't you use something like saltstack, chef, ansible, or puppet? do you use ovirt-node based images or good old EL6/7 ? HTH Sven -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQGcBAEBCAAGBQJVbuhoAAoJEAq0kGAWDrqlJt4L/1qBkvlgmjTdkxiqu4bv3/y+ ebb6rjJQSHv6gq5BtU73HyvTe9ODuGVWIc7k5FW8beGRWoX3MawHmkDFaqJQxN17 9AGqcI/YDRoxxAA/lPZmM0yIBTVLD5Fr4ldyV4i2ghhs6R3WuyeiEnsWhVDYSRdF YtKX7COrBDfVZh9UOSz9BW98/2I3bxvoULNNjaht5v5imPb9vn7SmjPJrvPlQhwc izu0F7EJLU3rwGMfBz9PG5RUbzvlUDua4W66wB8pOlAsl/Tk6aRL0308o6AOThzP V5IlEFYdOdA28o9V1sjXB7/2jH3viCQhsL/UQw9SaqjEtuYPM9Wg61SJdawJdkn6 8kTCBxys35f7kSNmhQYV50pwOLhvPYmUQSrrRpH1iqOP2h8j3uHkaNUI5HokDIwm ljYfLU3Vcf43EmFh1S50IyIYW7NG7sMp6bKdXYdg+nlWKTAVpCubqguxVG75vfR3 PrNQnITgjkidG7XSwzK7kmtXm7rmIV6RkR2PzLBPMQ== =GhNn -END PGP SIGNATURE- ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Mixed local and shared storage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/05/15 13:31, David Caro wrote: > > Hi everyone! > > > There's a use case for the $subject that is really favorable for us > (CI guys) and I want to ask you if it's possible, if it's viable > and if not already there if I should open a rfe. > > The case is when you want to spin up vms from a template, but use > them only once and remove them afterwards (for example, running > tests), if you had the option to have a shared storage where you > store the templates, and then a local storage where you spin up the > vms, that allows really fast (local) storage for the vms and avoids > you having to setup a clustered storage (gluster, etc) for those > vms that do not need any of those features. > > > So is that already possible? (For other threads and what I've > tested seems not) Is that viable? Can it be implemented on ovirt? > I guess you talk about this feature: http://www.ovirt.org/Features/Mixed_Types_Data_Center but imho the feature page is out of date - -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhaus en Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVTLZkAAoJEMby9TMDAbQRaK8P/3yYHeZRHPkzs72UnH8r2hCg pu/95LIGIQHBrtbwUIJy86OBIFHXkx09x3jUk5wPFQCtdMPqUKcVq3YEqtQZy+aM +zOlovhYFD16Wuatquz4903VkGJ1S1FnYN53eVrCKsXqREWCXjEHvyDlQyTxKNge 1oAw2qjcviWWwsf8RNk/0XOp7byiGoHxz87gbnqWiLrH6Hkgv7YJFz4bdXQKHQ2B kC9du7MbBKSi980gyo4anNUzyUXeE/aVyLfLURKMEsjvE5Rs2zwL66Dxcanfgh0e 4p5gy+KqYa574Z37moBXdgLFeo0Z9im2q9pOGjiVsykvKyw4P7UyChMofPHMX9zF 0NR8Gw4it3+s3y5C300Rxo7INYBWGwN0YSVdiU6fHg/+Dcn99KnBRzl24ioM+rR3 Kc44KG9+H7N7QtULKGvePZIz5azhSBu8Qrd89WjbAz5DQeUHsm8IY/mkWBO/Zukh sGcyyL9nRut2yyfQI7i5o4AyN9S3XZ4fKYvvr41p0WDgzWhxTqScyB7G4TSwxs27 SEb1uAnaWT73gg36qIB9YUItPFg3XKwceH5oxTAjeLWbTCgwvOin4w2cCp0YAcxH NJJyCqrN6TPDvYJtP1DJxv1Yj8JGEYMrOJhjCn2pGW0SZKqE/s+ci4OLcrtr3WM0 yKfLdXlR+T1jqDOvN7Zn =OqkY -END PGP SIGNATURE- ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] oVirt HA.
On 30/04/15 15:14, Dan Yasny wrote: > No doubt there, however, that's not *just* HA any longer :) sorry for being a nitpick and to quote wikipedia but: "There are three principles of high availability engineering. They are 1. Elimination of single points of failure. This means adding redundancy to the system so that failure of a component does not mean failure of the entire system.[..]" e.g active/active clusters ;) I promise this will be my last mail to this thread :-) -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] oVirt HA.
On 29/04/15 21:53, Dan Yasny wrote: > There is always room for improvement, but think about it: ever since > SolidICE, there has been a demand to minimize the amount of hardware used in > a minimalistic setup, thus the hosted engine project. And now that we have > it, all of a sudden, we need to provide a way to make multiple engines work > in active/passive mode? If that capability is provided, I'm sure a new demand > will arise, asking for active/active engines, infinitely scalable, and so on. of course you wan't active/active clusters for an enterprise product, rather sooner than later > > The question really is, where the line is drawn. The engine downtime can be a > few minutes, it's not that critical in setups of hundreds of hosts. oVirt's > raison d'etre is to make VMs run, everything else is just plumbing around > that. I disagree: ovirt is a provider of critical infrastructure (vms and their management) for modern it business. imagine a large organisation just using ovirt for their virtualization, with lots of different departments which at will can spawn their own vms, maybe even from different countrys with different time zones (just like red hat ;) ). of course, if just the engine service is down for some reason and you can just restart it with an outage of some seconds, or maybe a minute - fine. but everything above a minute could become critical for large orgs relying on the ability to spawn vms at any given time. or imagine critical HA vms running on ovirt: you can't migrate them, when the engine is not running. you might not even want a downtime of a single second for them, that's why you implemented things like live migration in the first place. the bottom line is: if you manage critical infrastructure, the tools to manage this infrastructure have to be as reliable as the infrastructure itself. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] oVirt HA.
On 28/04/15 16:20, Dan Yasny wrote: > HA does not mean multiple running instances of the same service. It means > if the service is gone, it will automatically be restored on a working > server. That is a pretty narrow definition of HA, which is not shared by most parts of the community (and the world), leading to much confusion of users on this very ML. HA in general means your service downtime gets minimized, today mostly realized through load balancing and clustering software services. just restarting a service (in this case ovirt-engine vm) on a different host is not what todays user expect under the term "HA" imho. in theory it should be possible as a design goal to make multiple ovirt-engine share one remote data base (remote database support is already there). I think this would be a huge feature for ovirt, but also requires quite some design and coding to be done. thus adding the devel list. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Agenda for today oVirt Weekly Sync
Hi, I'd like to ask about the status of my bug, as I didn't get any answer via BZ yet: https://bugzilla.redhat.com/show_bug.cgi?id=1156115 What I'm concerned about is, that the supplied patch doesn't fix the actual reported problem, but I'm not 100% sure, so it would be cool if someone more familiar with the code could reply. Thanks -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [vdsm] vdsm hosts clock sync
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OT: you should not use "vdsm-de...@lists.fedorahosted.org" any more. use devel@ovirt.org instead. kind regards Sven -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQGcBAEBAgAGBQJVJCZtAAoJEAq0kGAWDrql534MAMOCHuv1inVBxoCIPx0nMaFH zvBkWwttQjO8Y1dJJRrfpz6zccgY4LZYtnUbqQIUtM/K92qyJuOU+OqnQa/0Akf4 TNCr8+XOWqoeIrJJT+92tlU0kQG+l5ZXoHKrN0V8/iwh8/D2r/T6UlOWOM7zsW9N D2PGnm1+zGA6sWHxDaHRggxUQWio+seibmbd6g8SUmkMUFuQUrFejAbfDnRB7LXj qN3haYfiUbkdWXevD31BA3og4IPIYGf51C0Nz95z4J+oAd5AK8uAWasn+uG9h6f1 PlRPgxVVJgI0qFQ7MAIZpm7duYmKRlekvKDv83TEwC8vEggExQBEbJD4leDHf6QG PvtFh6lfWBq6vGgkr/OCdcn6OPPjWvHUoGzt2vXjCchUriixrJKq4ZOudbNW0UFT FAAWBe5+iYObMlSgwpn4fhNvKRwE3PoHYaqPDoiEvhRiBcERXFZT1cqIxx2eeTgj bLcYyBxYp1R6OMhtqrUqUNqdzqGzYY8eQtyCMeZgWQ== =96CH -END PGP SIGNATURE- ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] vdsm hosts clock sync
On 07/04/15 10:55, David Jaša wrote: > See my RFE: https://bugzilla.redhat.com/show_bug.cgi?id=1162588 It would be so cool if you would bother to open such RFEs at the upstream project (ovirt), instead of RHEV, so the whole community can be a part of this process. I don't get notifications for these RHEV downstream RFEs but I get them for ovirt. Thanks -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] el6 future in ovirt-3.6
+1 also take a look at the results of the user survey: most users use el6 so even the discussion about "dropping support" will make people uncertain how long they will be able to use el6. me included. On 16/03/15 23:19, Alon Bar-Lev wrote: > I cannot understand these conflicting statements. > > if any component of vdsm needs to run on el6, el6 support cannot be dropped, > this [among other] includes python version and other infra modules, packaging > included. > > a possible sensible solution is to continue maintaining 3.5 for gluster on > el6 with possibly new features, and have master free of el6 for all > dependencies. > > dropping el6 from 3.6 should have been early in development cycle to allow > proper testing. the gluster issue should have resolved even before the 3.6 > cycle. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] adding new paths to iscsi data storage domains
On 15/03/15 15:38, Paul Dyer wrote: > Hope this helps explain my setup. I am not sure how to file a bug. Is > this done on bugzilla or somewhere else? Yes, here: https://bugzilla.redhat.com/enter_bug.cgi?product=oVirt HTH -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [VDSM] dynamic tuning of logging
On 04/03/15 18:24, Nir Soffer wrote: > vdsClient -s 0 setLogLevel 20 Does this survive a restart of the vdsm service? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] Current status of numa integration?
Hi, what is the exact current state of numa integration in currently released ovirt versions (3.5.1)? and what are the plans for 3.5.z and 3.6? the wiki page is fairly outdated and could need an update: http://www.ovirt.org/Features/NUMA_and_Virtual_NUMA Thanks in advance -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [VDSM] about improved libvirt-python bindings
Hi, as far as I understand this would make it easier to implement/use upstreams(libvirt) existing python-bindings in ovirt? in this case, I think this is a huge improvement. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Using travis yaml files to specify dependencies and tests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/02/15 14:04, David Caro wrote: > As long as all the projects use the same path and name for them, I > have no issue with putting them somewhere else. > > I don't think jenkins is a good name, but automation is a nice > one. > > build is too common, used by a lot of different tools, better avoid > it. > > So can we agree to use automation directory? assuming this is about the "bash scripts" I would just like to notice that you should keep them posix compatible so they can be used on different platforms too. Thanks - -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJU0OK5AAoJEC5d3lL7/I9zUacP/i7h2/rIPnAc3nJ6gog4udFe tiNEWZgbgWgbd83WvHWrs/FHUtWC5CukTl/li18jTiZaSgcOqcQBtyPeFHuWUcsy 1PKmd75/3TiTjOdwLcKvxvRrSmttvYJl9bqXrmyiyX+ZOsOcFnmlt8wcllyo26IU gs1nbpgsYynrTCX5qWvlBK0dmCvezHpEqXzIEM0f8gZzWpI0MB9jGmc6jzdMyMDC OAtJg1RstJ3B3Ew9gL4NBCgQYRW/oom9tFNVj+2sh8HmkWQuWbSzwajMlToSbtb3 VFL5T+wRIQRv6oRSuZbMI10VwTWCGM7umJckLkN6OcV6OIB9AUY5e+Dw9d4p5ks1 IpqRBdTC6o9CrNIj13K0SGtOQFF8DKmYAnMNgw/EVhWwtyWhJ8M7I+Pnrfn11Fet a0PyDVgrQaKpEhQxgkdfxAW/s4nf7xYfcWQx2QFc0+n5tev4NBHquzBVSkmXgTOa rcGJx0tOVCFGKLIy5EuMijvaP6TtByL+wkOwwIv/aYKJ5+YSGW4SsnDZUXyi6Czs KDNi9CHArJOuSiXTZ5/Bo82bPKm7KrNnIwpDf9hlKR+PeJj94k9inzkezGlDwdxY mIKQcXURut+EJzGwPggi0uPRgjgnCKX1ZZN9wj/qDtao9KPyf5eREB0GD/+SKGip lxMdv/KZU9/Y1/uDt7ud =E+Ya -END PGP SIGNATURE- ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] oVirt 3.6 Feature: Cumulative Network Usage Statistics
On 28/01/15 13:20, Dan Kenigsberg wrote: > I wonder if Vdsm should keep the > last tx/rx used by this VM so Engine can collect it, and charge the VM > properly. From the user perspective: yes! nice feature! -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Move bugs to ON_QA based on snapshot builds?
Hi, just a quick question: Would this imply that you need to create separate bugs to track these "solved on master" bugs for the next release? So you know the fix/feature really hit's the release? Or how would you track that? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [engine-devel] Turn Blank template into defaults
On 22/01/15 11:28, Tomas Jelinek wrote: > Hi All, > > I have started to work on a new feature[1] which will make it possible to > edit the Blank template. > The proposal is available on the feature page[2] > > Any comments are more than welcome, > Tomas > > [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1130174 > [2]: http://www.ovirt.org/Features/Blank_to_Defaults Well you can't just rename the blank template to "default". You would break any upgrade from 3.5. if you did. At least you could not run any pre 3.6. cluster level vms on this 3.6. engine. Is it intended to break compatibility in this release or not? 3.5 cluster level vms (e.g. new created vms) need afaik the "blank" template. how do you want to handle that? could you instead add this "default" template just for cluster/dc level 3.6, so just "3.6" vms use it? In general I think this is a much anticipated and needed feature, so I'm looking forward to the 3.6 release! :) -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Gluster Volume Snapshots - Feature review
Do you really want to call this entity "schedule"? I find this somehow confusing as there is already a "scheduling" component in ovirt, which does different stuff. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ENGINE] Question about refresh parameter of GetConfigurationValueQuery
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09.01.2015 14:00, Alexander Wels wrote: > If you can find all locations that assume the value is true and > don't explicitly set it, and you change them to explicitly set > them, then there should be no problem. Otherwise things that are > expected to refresh the session will no longer do so, which will > result in some unpredictable behavior. I smell breakage here. > On Friday, January 09, 2015 04:52:15 AM Yair Zaslavsky wrote: >> Hi all, Can anyone think of an issue with changing the default >> value of the refresh parameter to false for the query mentioned >> at $Subject? You should at least provide a reason why you want to change it, imho. kind regards Sven -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQGcBAEBAgAGBQJUr9IaAAoJEAq0kGAWDrqlwxEMAJirB5rBVYod8jlYFX0yH9g5 R+kqjs+ApplJOD/GcOk6H1+bcWh3SoLIz3iAcS0JODNrvPcaItlWh7JNTrN1IYgM WZQD1xL/ctCVfCumNq6ZjGKsHNk2eDKuCXyKWPw6nG0mqe4HXpJ8+YeckC17+9C0 rKpw9qEQJHuyaanpsuu8nKwxkW7QpNy61OX5BEJ3KobJI9wuBshX3rJiPR774InD 1RDHgnnwCG4dsttEZHFug8Ckom4rvZrBPua4I4RP93RVDfgDIaqKPD8VFlA29iC8 nndZwsIEmYfSECpcrBzEHSOzRnCMyN4AGrvjTkChVcSSWINWqEqMWG2e7NPWmM9A ipBTsAXIJQfxf8D938If8CDnsCW6b4cz6UXd8+kBUXEACZtNf3MNqbJY8Lt5SzHO YrDqht6vkFrS6Rq1ExoaSVcS3qzJ6R+vcAeHw1HlpZwmRUArlOoDxhh40cStwZma XUZrnd9CqKeL9d0B6XEdOVx8Bg93G9hoFYyhX2uHZQ== =L6LV -END PGP SIGNATURE- ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] 3.5 live merge findings and mysteries [was Re: Simple way to activate live merge in FC20 cluster]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 15.12.2014 08:33, Gianluca Cecchi wrote: > On Mon, Dec 15, 2014 at 8:27 AM, Gianluca Cecchi > wrote: >> >> On Mon, Dec 15, 2014 at 4:16 AM, Adam Litke >> wrote: >>> >>> Hi, please see below for more details. >>> >>> tl; dr; Live merge works on oVirt-3.5.0 with Fedora 20 hosts >>> that are using qemu and libvirt packages from the virt-preview >>> repo. No other configuration is supported yet. We aim to have >>> support for RHEL7.1 and later and built-in support for Fedora >>> 21. >>> >>> >>> > Sorry... pressed return too quick.. > > Understand me, please. My note was about Release Notes page > misleading in respect with features' set and newcomers... but also > frequent users too > > At http://www.ovirt.org/OVirt_3.5_Release_Notes#Live_Merge ones > reads: > > " Live Merge If an image has one or more snapshots, oVirt 3.5's > merge command will combine the data of one volume into another. > Live merges can be performed with data is pulled from one snapshot > into another snapshot. The engine can merge multiple disks at the > same time and each merge can independently fail or succeed in each > operation. " > > I think you have to mention that it is a restricted use case for > now... and specify that it works only for Fedora 20 and in that > case you have to manually modify the repo definition to install the > qemu packages from virt-preview to get the feature. This still is not fixed! I can already see the bugreports coming in, claiming live merge does not work, because the release notes are very misleading! Did nobody got the time to fix this? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQGcBAEBAgAGBQJUqUDBAAoJEAq0kGAWDrqlMJAL/2Uc4bfFsWczRoce067rMED1 H5zd08MzZ7d2rXViEnUpuQnmE+SJSjsbtZp0ueTE4rgoqGGHP3pauu6YK0JaSNGw 3DpP++Yjqrsn5gCzqhwl3LqN+IQMowZ2ljREcae5ltajzf/SIDrDsdWoiHO4ZQcL RXXTAh4v5cpA0P34fIJZT4KLcJUDjWm7SeBAnY0XAAlEnGZweH/4juU2asq00pRE CnReayZwhuo5+et9FUBc5CBj9TAjcgKTruO3gAM5IMBPIAi1yBVpGMUfU/x4r/o6 6aNvQA9oolWWbCH63Jlz6c+HF/KGdlWEVz+zXaLojsNyyKcOy+UceQiL0ZGnzOfB Klcwfjb88P6ElDb8tzALjuqJXNkyEAR/0xcoAzTyeaKCi5XlIxbqrZjEyrjdSE3W d6GYI7A7G0MbpUtbCaBvy/7fCT1YdlRK7dmtxVMinV8mxDJslSu1jg5mZ/AR/Wd4 TD/TgUY2FRvdXrQpdBpKqKS6UR+s2sfJ+6KnanSGEQ== =uzHE -END PGP SIGNATURE- ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Feature review: Cluster parameters override
On 18/12/14 13:16, Itamar Heim wrote: > 3.5 cluster uses -m rhel6.5 for either rhel 6 or rhel 7 host. > this is about using a -m rhel7.0 mode Thanks for the clarification. What would be the difference inside the vm? Different emulated hardware? Other setting? Where can I look up the machine levels and their specific meaning (any link to a doc)? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Feature review: Cluster parameters override
On 18/12/14 12:34, Itamar Heim wrote: > we never tested 3.5 on rhel7 machine type. Sorry, what? http://www.ovirt.org/OVirt_3.5.1_Release_Notes#Red_Hat_Enterprise_Linux_7_and_CentOS_7_Support How can you support it in the next release when it was never tested? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] VDSM sync meeting minutes December 9th, 2014
On 09/12/14 17:52, Dan Kenigsberg wrote: > # REQUIRED_FOR: engine-3.0 This seems odd to me, as it's not really correct, engine-3.5 would be more correct, wouldn't it? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Creating a new gerrit flag
On 09/12/14 13:47, Oved Ourfali wrote: > safe up to 95% or so. You just made up that number. I don't really understand why you would want to downgrade your code quality by circumventing tests. Maybe someone can elaborate on this a bit? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Important change in UI plugins REST API integration
Thanks for your clarification! -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Important change in UI plugins REST API integration
On 01/12/14 20:26, Vojtech Szocs wrote: > In other words, usability of REST session ID is now strictly > scoped to GUI user being authenticated. If the user logs in, > (always) new REST session ID will be passed to all UI plugins. > If the user logs out, REST session ID will not work anymore. What if I use just REST for logging in and doing something without any GUI interaction at all? this reads a little like: you always need an open web gui to be able to use REST, which does not make sense at all. So I guess I'm misreading this? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [VDSM][JSON] jsonrpc coding/encoding performance on RHEL/Centos 6
On 20/11/14 12:18, Dan Kenigsberg wrote: > RHEV cannot depend on EPEL. If a package is not in RHEL, RHEV must > consume it, which is something that's not worth doing in this case > (where there's not functional benefit). As I said: it already does that: an excerpt from the latest ovirt-release35-001-1.noarch.rpm: in /./usr/share/ovirt-release35/ovirt-el6-deps.repo you find: [ovirt-3.5-epel] name=Extra Packages for Enterprise Linux 6 - $basearch #baseurl=http://download.fedoraproject.org/pub/epel/6/$basearch mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=$basearch failovermethod=priority enabled=1 includepkgs=epel-release,python-uinput,puppet,python-lockfile,python-cpopen,python-ordereddict,python-pthreading,python-inotify,python-argparse,novnc,python-ply,python-kitchen,python-daemon,python-websockify,livecd-tools,spice-html5,mom,python-IPy,python-ioprocess,ioprocess,rubygem-rgen gpgcheck=1 gpgkey=https://dl.fedoraproject.org/pub/epel/RPM-GPG-KEY-EPEL-6 So why can engine depend on epel and vdsm can not? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [VDSM][JSON] jsonrpc coding/encoding performance on RHEL/Centos 6
On 19/11/14 18:36, Dan Kenigsberg wrote: > We've learned the hard way that this was not the case.. > http://gerrit.ovirt.org/#/c/35354 Why don't you just require this one package from epel than? epel is included in EL7, you just need to activate it. Furthermore, some engine packages are also just available via epel, so I see no reason to not require epel for vdsm too? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] Ubuntu/Debian support?
On 17/11/14 08:41, Itamar Heim wrote: > > 1) Is this still an issue? Yes of course, or is it implemented yet? > 2) Can we afford to dilute the focus we have as it is hard enough to >stabilize the currently supported distro's? is it worth the >potential impact? In general: Software which supports multiple operating systems/distros tends to be more stable, because some bugs just get found on specific platforms. the general ovirt technology is available "everywhere" (TM): java & python > 3) Would it have maintainers catering to it so it won't be left behind >/ delay development? this is a question for devel@ovirt.org (CC'ed ;) ) > 4) Why bother with host support, ovirt-node can be used? My impression is, that most users don't use ovirt-node, because this project has not enough dev power and lacks certain stuff > 5) Why bother with engine support, a virtual appliance or a docker >image could be used? docker is inherently insecure (a famous red hatter said: it's like download random code from the internet and run it as root), so docker is no option today, imho. > 6) if we do it, should we focus on Ubuntu or Debian distro first? well, the general rule of thumb is: if it runs on debian it runs on ubuntu. I see way more debian than ubuntu servers, but for modern deployments this changes. my personal opinion is, that ubuntu sucks as a server os. > 7) if we do it, should we focus on host or engine first? atm you are focusing host, there are some bugs open for that and it's planned for 3.6. (that's what I read at least) General note: Imho ovirt would greatly benefit from more supported distros. Not just debian and ubuntu, but you have to start somewhere. you can attract many devs, which just don't use el/fedora. furthermore, the basic technology runs on any linux distribution: java and python so these are "just" integration issues (path to configfiles, different init systems, packaging not in rpm, but deb, etc.) This is still a huge effort, but I guess canonical and various debian developers would maybe join the effort to make ovirt work on their platform. my 2 cent -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Unstable network connections after installing vdsm
On 11/11/14 07:35, Antoni Segura Puimedon wrote: > Yes. It is a bug in /sbin/dhclient-script > https://bugzilla.redhat.com/show_bug.cgi?id=1116004 Hi, this bug is marked as private, would it be possible to make it visible to the general public? Thanks! -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Thoughts on modularization
On 05/11/14 17:07, Vojtech Szocs wrote: > This way, you'd have one "core" module, providing most general > functionality/abstractions. Then you'd have more specific modules, > plugged into "core" module's API etc. In other words, hierarchy of > modules. This is essentially modularization taken to extreme :) Welcome to dependency hell or circular dependencies etc. would you like to code your own dependency resolver? I like modularization, but you can overengineer everything. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] [SCALE][RFC] ksmd bound to one core
Hi, currently ksmd is a single process and is thus bound to one core. This leads to some scaling problems such as: If you got a lot of vms on one host with huge amounts of ram you can observe that the cpu usage by ksmd goes easily to 100%. I wonder if ksmd could not be split up in child/worker threads, thus enabling higher density of vms on one host. or can this just be tweaked by altering values in /etc/ksmtuned.conf ? What do you think? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] usage of the foreman / limitations of puppet
Hi, I just wanted to ask if there are some plans to also support other automation tools like salt, chef, cfengine or others, because puppet is imho not a good tool for large environments performance wise. I noticed there is some support for saltstack in foreman. So this seems to be a first step to extend the support for different configuration management tools. I know RH seems to favor puppet (it's used in the new satellite product) but I don't think it scales well (talking about thousands of hosts to manage). Are there any opinions or plans within the ovirt community regarding this topic? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Reminder: [ovirt-users] [QE][ACTION REQUIRED] oVirt 3.6.0 status - release criteria
On 28/10/14 11:17, Eyal Edri wrote: > i didn't see any date for stable branch creation, or it's called by a > different name? > also, worth maybe doing an internal discussion on ovirt vs rhev 3.6 release, > in terms of milestones, qe verification on upstream, etc... imho you are mixing up release criteria and release schedule. criteria are not time based. notice that release criteria inherit that there must be a testcase and a person / automatism to test each criteria before the release. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] Beginner
On 24/10/14 16:37, navya sri nizamkari wrote: > Hello, i am looking for bugs I can fix.I am new to this. Can somebody help > me out? > > Thank you. I guess devel list can help you more :) write to devel@ovirt.org (cc'ed) -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] how (inefficient) does vdsm import sparse disks in local storage(file based) data domain?
On 23/10/14 15:51, Nir Soffer wrote: > We have this patch for next version: > http://gerrit.ovirt.org/33355 Awesome! >> >> So here's my proposal (if I do not have any mistakes in the above): >> >> at least make a: >> tar -cpSvf disk.tar /path/to/disk >> and than "dd" this over the network, because tar _can_ handle sparse >> files. >> >> Of course any other more efficient mechanism would be okay too. >> >> If my observation is right, and the project think it's worth >> to implement such a thing I would create an RFE for this > > Please do Here it is: https://bugzilla.redhat.com/show_bug.cgi?id=1156115 -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] how (inefficient) does vdsm import sparse disks in local storage(file based) data domain?
Hi, I might be totally mistaken, so please tell me first if I understand the process: when vdsm imports a template from an export domain to local storage, according to my "ps" output, vdsm copies sparse templates using "dd": vdsm 14378 0.3 0.0 59032 4424 ?Shttps://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] CDI limited capabilities in jboss-as-7.1.1
On 06/10/14 19:23, Yevgeny Zaspitsky wrote: > Recently I started using CDI (thanks to Roy Golan contribution) in bll > module code and figured the limitation described in > (https://issues.jboss.org/browse/AS7-4567). That was solved 1.5 years > ago in jboss-as-7.2. Currently we use jboss-as-7.1.1. > Is there a good reason for not moving to jboss-as-7.2 or any newer version? Yes, it's not in EL6 repos afaik -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ANN] oVirt 3.5.0 Fourth Release Candidate is now available for testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02.10.2014 16:47, Sandro Bonazzola wrote: > [1] http://www.ovirt.org/OVirt_3.5_Release_Notes Am I wrong or do the release notes still large parts of the "features" section? Where there no new features for "Virt", "SLA & Scheduling", "Storage" or "UX"? regards Sven -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQGcBAEBAgAGBQJULo5oAAoJEAq0kGAWDrqlTWcL/3Xwv6rEPuHy5nEZxCG5faTf V5KcMCds1aYQ5Tl/J2hbN8lXLiCbuO9KNzex8nO2Q2AEFFWKqwsPMId/OZ/xjK7q ttY1p+wGRZFystttXvX/+8JsTGHEpPMDCAAfBjfHWx6pDBF1G0wWp+dDYzz2K8CX PEX3KAgzebK2czebSeO35pCmiBhThLz32RSbF64QlMHYOqDp42IcVCk+oiQC4Orj gwwa5bvG677oHZOS5iBVufmcprKN6e+oQBZSedh4tkjH817gOACvX2eszoWA8pXJ bY/BmuQ2uZb9PtjMzlB0hgkPN1IHRg17BxCXEzK9GoYBSopVIVy137QdUfIRQtNI ZkChXyhisqVuu10lOsLS0vIkWS4C4S1MTC9Y78NvJ3BAEYgefCgZ+8vWzgc4aESe +naI8/rGqlYgJTIMgzqeny8ET1P5jwzQ8jfA2y5AApYBR2i3zHGSBz3ddWRQFtTV KK/7bxAXapWO/DxERz+ElZaDzCgR+mI/tyxASQrqzg== =L83r -END PGP SIGNATURE- ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [CentOS-devel] Atomic Host Definition [Discussion Draft]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03.10.2014 11:51, Karanbir Singh wrote: > ovirt natively supports docker, you can deploy docker instances > just as you would VM's into the ovirt managed hosts. > > is that what you are looking for ? AFAIK this is still WIP? see: http://www.ovirt.org/Features/Docker_Integration I don't know of any released code in ovirt 3.5 which supports docker yet. I'm pretty informed about ovirt development so I would be surprised to hear this is already implemented without reading about it on the ovirt-devel list. But this gets OT for centos-devel, I guess. Maybe someone from ovirt-devel can shed some light on this topic? kind regards Sven -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQGcBAEBAgAGBQJULojZAAoJEAq0kGAWDrqlGv4MAMuvmzSHdC5eoJb+QeCvIOzX kBIxztRfEHuGVjvXOjZbXAFRvTFz7DYB8dtUAA4w7i38/Y8XSHGIjM9lVGlv6aH0 eFgroTuVnG+5T8xzH0HPWJsb+8N2qlBP5TgSdiMhiKSY64yqx2dcaLSLwo6trYV8 phjqoQV7s4ePUu1Q6a3H6YBWblDwWvE+SlE52oPZcS2Xh4+2uT2ufJnyVkpzA31o z737JBIKSUoyulwS/d5fVQYKLC/StCz6cCGbSRtGVN/lXvFGEkzzFMgKOwWDUDuO yJt1d0HVdXS+WVNi4UEn4Ga+VjNLfludIsQzBR5Ipvkq2Puif9UWL+0hD7rN/Owj PJiOinxUh0y1soocXyn+bR1UdtdmDMrbVh0wIP5EKw7u5MSx7caiqMGY/QrEz1jz hQllIOSSBwr7zIJ6PRDkLwAP5avQV1zVTTG4Gggmp1rdihrzX9j8UEwJmxPA7O3i PnQ5k/J5mLPdjp2OBDhrWzSGyTcrPhldBr+AzC5nQQ== =OBnd -END PGP SIGNATURE- ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [CentOS-devel] Atomic Host Definition [Discussion Draft]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02.10.2014 22:53, Joe Brockmeier wrote: > * Deliver images for bare metal and important cloud/virtualization > platforms (AWS, GCE, KVM, OpenStack). Hi, I do very well know it is not supported yet, but would you mind adding oVirt (ovirt.org) to this list? It would be huge to have docker support there. Also CC'ed ovirt-devel, maybe there is some interest. kind regards Sven -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQGcBAEBAgAGBQJULmUtAAoJEAq0kGAWDrqlKSUL/jeQ7D4vyJ9Q3Ka/96ix1ncs uwoB5Su9eipcOxOoJ5nXPpTdmAk6YXjR2dkyKmy9QkS1VudDmmIU45trUJri7NU/ xHXqQwI/gLchiiAGi3GvmgoR/0XCXBP8tQh5cDQPhqcc6bRo1g2RsnLMhnAxP2mL OaGigcCYr+We3RVm/9gqUj1fWsIJYWUIEyDTH+3a7Tw2HaRE84KZxAzvjeEkA/Wm fRYCx/sVTDPdyTMKsbuiYOO0VG0KkivCDOD8w4GIuUqyL92iif8EwguyS5ehb868 bdEGzVIKqEKVvwusfn4eSnBNUSbKqIkO2L0q65GA0vkCkOXHWTrHI+4R8zcx0DdH NsBk8n69lT2n4s8pHnsk9JvaMvdCnjTuL1YdZYhAUm3AbX3IXZCdt/5wJBPlC4U1 CPUs/SBojHU4I3n3BPmxQHT2zzZ5a0wJBigaRqmEviQOqR4jlWCQ3ctvjQT6K0OG lbheAnwjH951fopdzL5nlE0mg5w9kl4wXvGTk5pWLw== =MX2Z -END PGP SIGNATURE- ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] can't clone vm from export domain via rest/json
Hi, for documentation purpose: jhernand helped me working around this issue. all details and the workaround are found at: https://bugzilla.redhat.com/show_bug.cgi?id=1147011 this is still a problem in latest master, maybe vdsm people (Dan?) should take a look at it. Thanks for the very fast help! -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] can't clone vm from export domain via rest/json
Hi,
I need some devel power here:
this is on ovirt 3.3.3 el6 (yes I know, I need to upgrade..)
error while cloning a vm from export to local storage data domain:
POST
https://REDACTED/api/storagedomains/e89fdbcb-cb51-42b7-b42c-7f4f0ec1f580/vms/fc0f82f3-fb34-429b-aa52-e8276cdc49c0/import
{
"storageDomain":{"id":"15679d40-0f20-4a0e-9880-eb5795cb8d1e","name":"LOCAL_DATA_DOMAIN_NAME"},
"cluster":{"id":"e65dc5f5-61e6-4d17-a5bf-33c677d129c7"},
"vm":{"name":"VM_NAME_1"},
"clone":true
}
ANSWER:
{
"storageDomain":{
"name":"LOCAL_DATA_DOMAIN_NAME",
"id":"15679d40-0f20-4a0e-9880-eb5795cb8d1e"
},
"cluster":{
"id":"e65dc5f5-61e6-4d17-a5bf-33c677d129c7"
},
"vm":{
"name":"VM_NAME_2"
},
"clone":true,
"status":{
"state":"failed"
},
"fault":{
"reason":"Operation Failed",
"detail":"[action type failed import clone not collapsed]"
}
}
why does it fail?
this vm was exported from this storage domain onto the export
domain and should then get re-imported as another vm-name
is this because of lacking/inconsistent json support in 3.3.z?
until now we were able to reverse engineer all needed functionality
via json.
--
Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator
Mittwald CM Service GmbH & Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] [OVIRT-3.5-TEST-DAY-3] Optaplanner
On 22/09/14 14:04, Martin Sivak wrote: > It is the only solution when the remote service does not support SSL. We > might include SSL in some later version, but not for 3.5. What is the problem which prevents inclusion of ssl support? Is this "just" work that needs to be done or are there any obstacles/bugs/ design flaws which need to get fixed? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] Building vdsm within Fedora
On 24/09/14 10:57, Sandro Bonazzola wrote: > Well, since the -rhev package is now available in 3.4, 3.5 and master repos > it shouldn't be a PITA anymore. Thanks for the clarification :) -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Building vdsm within Fedora
On 24/09/14 09:13, Federico Simoncelli wrote: > You probably missed the first part "we were using qemu-kvm/qemu-img in > the spec file". In that case you won't fail in any requirement. > > Basically the question is: was there any problem on centos6 before > committing http://gerrit.ovirt.org/31214 ? Of course there was a problem, please follow the link in this very commit to the according bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1127763 In short: you can not use live snapshots without this updated spec file. And it's a PITA to install this package by hand, you must track it's versions yourself etc pp. you basically lose all the stuff a proper spec file gives you. PS: I also don't get the "we want to get vdsm in every distribution" a) it was never in any distro, it was in epel, which is a third party repository anyway, so you can just provide it via ovirt repo imho. b) no one packages vdsm for debian, ubuntu, gentoo, arch, suse, $nameyourdistro or I completely missed it, so why treat fedora in a special way? Don't misunderstand me, it would be cool if you have packages for every distro, or even bsd based stuff, but I think this is still a long way. c) will anyone use vdsm without ovirt? is this even possible? so imho you need ovirt repos anyway? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [QE][ACTION REQUIRED] oVirt 3.5.0 status
Hi, as the release criteria[1] mentions: "MUST: Have updated quick start guide available" I'd suggest [2] as a blocker. [1]http://www.ovirt.org/OVirt_3.5_release-management#Release_Criteria_.28WIP.29 [2]https://bugzilla.redhat.com/show_bug.cgi?id=1054303 -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] Package vdsm-4.13.4-0.el6.x86_64.rpm is not signed again in 3.3.5. repo
Hi, well the message in the topic already explains what is wrong. This happend already once some days ago and dcaro fixed it, but somehow this occurs again. It would be kind of someone could fix it. Thanks -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [QE][ACTION REQUIRED] oVirt 3.5.0 status
I still think this should block the release. I don't know why it is targeted to 3.5.1. This was working in prior releases (custom script via cloud-init) but it does not in 3.5. so it is a clear regression. On 17/09/14 13:46, Sandro Bonazzola wrote: > 1138314 virtNEW Fail to start vm with payload. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Stable branch gerrit hook and Related-To: bug
Why should an incomplete, thus non working feature get merged? Do you also merge incomplete bugfixes? One commit should contain one feature or one bugfix, imho? I know this can be difficult sometimes, but still, at least in the master branch this rule should get enforced, maybe create a staging branch for incomplete features? On 16/09/14 14:53, Martin Sivak wrote: > it would mean that feature cannot be merged before it is completed. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] mom-0.4.2 released (Karma requested)
I see no new branch created at http://gerrit.ovirt.org/#/admin/projects/mom,branches ? This is all still in master branch. Also a changelog would be awesome to have (there seem to be no huge changes since 0.4.1). Thanks for the new release anyway! On 12/09/14 17:12, Adam Litke wrote: > Hi all, > > I have released mom-0.4.2 and submitted updates for f20[1], el6[2], > and epel7[3]. If you have a spare cycle, please install this new > version from the updates-testing repository and add a comment in the > fedora updates system. This will help expedite the rollout of this > update. Thanks! > > [1] > https://admin.fedoraproject.org/updates/FEDORA-2014-10757/mom-0.4.2-1.fc20 > [2] https://admin.fedoraproject.org/updates/mom-0.4.2-1.el6 > [3] https://admin.fedoraproject.org/updates/mom-0.4.2-1.el7 > -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ATTN] Changing messages with variable placeholders
On 11/09/14 15:04, Einav Cohen wrote: > you don't need to worry about the correctness of the non-English > messages that you are changing; this will be taken care of in the > translation cycle that will follow your patch. you just need to > do the minimal changes necessary (remove placeholders / append > placeholders) so that build errors will not occur. so before these changes get released in an official GA build there must be another translation cycle? as far as I understand this occured during composition of 3.5 and as far as I know there is no new translation cycle planned for 3.5? This would mean you would break translations in 3.5, wouldn't it? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Moving forward our frontend stack
Well I really think this is a very bad idea. I'm pretty sure I don't need to introduce the concept of checksums to anybody on this list and why this is done. You must decide whether you want the correct code or not. If you decide to disable it on one repo, what is the justification to not disable it on another/all repos/projects? just my 2 cents :) Am 29.08.2014 16:54, schrieb Vojtech Szocs: > Well, I meant to avoid disabling checksum checking globally. > If we can selectively disable checksum checking for specific > Maven artifacts like "gwtp" etc. then we could do that.. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Urgent BUG: renaming of template fails
https://bugzilla.redhat.com/show_bug.cgi?id=1130090 Am 18.08.2014 11:53, schrieb Eli Mesika: > If you think that this is important please issue a RFE for it. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Urgent BUG: renaming of template fails
Am 14.08.2014 13:12, schrieb Maor Lipchuk: > Hi Sven, > > I tried changing template name on my setup (based on latest master) and it > worked. > Can you please share the output of the following psql command on your engine > DB: > SELECT vm_guid, vm_name, entity_type, description from vm_static where > vm_name = 'template1' > Hi Maor, it seems you did not test properly. You need 2 DCs with a template in each datacenter. rename one of them to match the other. It will fail, quoting Nir from my Bugzilla entry: > This is how the system works. Changing is nice to > have feature, as it does not effect much the usage of the system. > We have the same issue with cluster names, vm names - most names are > unique globally. > I also find this annoying, and practically create names with > dc-cluser prefixes to avoid this. I really don't understand the logic behind making these names unique on a global level. There are many easily thought use cases where you want the same template name in different DCs, now I will have to juggle with dc-prefixes. I really hope this gets fixed up for 3.6 Thanks for your fast replies anyway. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Urgent BUG: renaming of template fails
BZ created: https://bugzilla.redhat.com/1130090 ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Urgent BUG: renaming of template fails
Here is some log output to help track this down (from engine.log): 2014-08-14 10:28:35,528 WARN [org.ovirt.engine.core.dal.job.ExecutionMessageDirector] (ajp--127.0.0.1-8702-22) [399284fd] The message key UpdateVmTemplate is missing from bundles/ExecutionMessages 2014-08-14 10:28:35,554 WARN [org.ovirt.engine.core.bll.UpdateVmTemplateCommand] (ajp--127.0.0.1-8702-22) [399284fd] CanDoAction of action UpdateVmTemplate failed. Reasons:VAR__ACTION__UPDATE,VAR__TYPE__VM_TEMP LATE,ACTION_TYPE_FAILED_NAME_ALREADY_USED 2014-08-14 10:28:35,568 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (ajp--127.0.0.1-8702-22) Operation Failed: [Cannot edit Template. The Template name is already in use, please choose a unique name and try again.] -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] Urgent BUG: renaming of template fails
Hi, this is my test setup: DC1 with local storage, some templates, e.g. "template1" DC2 with local storage, some templates, e.g. "template2" what I want to do: rename "template2" to "template1" in DC 2 actual results: [Cannot edit Template. The Template name is already in use, please choose a unique name and try again.] This fails via GUI and via REST api (GUI blocks the form, you can't click "ok"). expected results: Template Names should at the very least just be unique for one DC, and not for the whole engine. Strictly speaking even this is not needed as engine uses UUIDs to identify templates, but I agree that it might be handier for end users to just allow a template name once per datacenter. This occurs on ovirt-engine 3.3.3-2.el6 but I fear this is still present in current 3.5 RC and even master. So please, can somebody confirm this bug so I can open a BZ for this? Thanks. PS: the storage architecture type should not matter, I just added it for completeness sake. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [QA] [ACTION REQUIRED] oVirt 3.5.0 RC2 status
Do you block this stuff then in a sane way on EL6 as such new features aren't available there? Am 12.08.2014 18:06, schrieb Adam Litke: > These needn't block oVirt 3.5. The majority of low level > functionality is provided by qemu-2.1 and libvirt-1.2.8 which are both > hitting the virt-preview repo now (or are already there). There are > still some outstanding bugs (1041569, and 1102881) and these should > appear in the next releases of qemu and libvirt (first week of Sept > I'm told). The above two bugs should only impact block storage > domains. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] oVirt 3.5 test day 2 results
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 30.07.2014 18:14, Simone Tiraboschi wrote: > A previous attempt used ssh and scp to do all automatically but it > was rejected being judged not so secure. So who judged it? Maybe he/she could share some reasoning how this could be more insecure and more error prone than a clumsy do-this-by-hand-setup ? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQGcBAEBAgAGBQJT2kYMAAoJEAq0kGAWDrqlgIUL/3H3U0shaJ/X7UySEo5ULYEv 8WmDmqAFdFjIsVrIEAxVCYrqlgLRqNCkL+1IhUn82ng3k22iREwmGXcV33LvDBEG wAMg2U4JgHJwF874cyMSWObl+N6VxfNjoRrKkUDXm4mMr+iJExvZXcFCQ5qfSKKD RnCITKz/Xvnh0DFck0+OQ82SvgG49izZaKxYFHZ+p+0OFRN2IeFZfuhot41eMmHw tmxJnz6REqbipcJS2+QYrjwlAk2Ocu+u4nIXHHtWTLUw4QJ3NSFTUF+LbCctevyL sH72xveBmmBCgQN10rkZy8dtgVlBPkb91IXYTW1Mv3VOp0fNO/MG3gDYksYFOBM6 /CPItVBv1lWK5NDIchKBjYQXpfYfberS8shl/4KrB4017xSbsGzL9xH376y84GYV hvls+xdRyvxFlh9po9SK68Vd6Ds3TIJ0HoN50KZKzANAY+NdQzdIz9KzSB8s3kT+ SJ1ujbULWYT9yIMUMH29iQnNbrPqklY/UnBcXCHkBQ== =E+4w -END PGP SIGNATURE- ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] oVirt 3.5 beta2 - results
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29.07.2014 17:18, Piotr Kliczewski wrote: > I tested gluster related features: > > > Nagios Integration -> > http://www.ovirt.org/Features/Nagios_Integration#HOW_TO Hi, just as a quick heads up: I'd suggest to rename this feature from "Nagios Integration" to "Gluster Nagios Integration" as the former might lead to users thinking you have a general nagios integration. regards Sven -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQGcBAEBAgAGBQJT2JzzAAoJEAq0kGAWDrql65IL/AlU/Iq5lmYdW1M6fFdLq+4A FpiL9uI/c7QvGOVp5ugOCd8ewxZZw+lQGj6qBiOteK4RnNEjfnQeEYl5fkyBZLr/ +UuF74t/lBwL4M8XtaJ1c6H7MlyKrXOOYOnNb1C5dfBdONga/I9+26e7U60U84Mb SlIRSKlyAyDrQ5+YMfcdM82qiMolOf1BNVKSC7UULqc/ZqtKT0W9J30hmKc5gE9T CV48rcUp+xzgypa+EC2PsjqdE5IMqgcRnK+BCYcoMvVws8vdS+1zTpcCOHL6JbmK HiyDX6xdF505d1eMs5irDAbjnnnKw8M7GktFgugIPsdcdOJWJYCt0HFUTAgBd5uU 6lLN9bndzUGGlDxKvFrnYLDsGZYfKelkYyovMBKk+2c1w+ysiDpeC01fIc4CUXHX AbXY4aYO9ZozxKiZOZPClu7VOywBxciZMUwSqW0frr+vXrccmVu0IE9kNSoi11pa WPQ5dBcBffhQMXVJoaMHurWfukw5h46RUB9uAGTz3g== =xDS2 -END PGP SIGNATURE- ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] UI plugins - talking with Engine via JSESSIONID now requires separate request header
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just a few questions from someone who relies on the rest api: Background: I use rest not for UI plugins but for general management stuff (basically all ovirt operations which are possible via rest) I don't use the cookie based session management but pure rest (stateless). Questions: 1. Will stateless rest sessions always be supported or do you plan to change this in the future to just allow cookie based access (so no real rest api, as it's not stateless anymore)? 2. Does this change just affect UI plugins or also other rest api usages? If it does affect other usages, which one? Just cookie based operations? thanks in advance Sven -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQGcBAEBAgAGBQJTxXJzAAoJEAq0kGAWDrqlEpUL/1DhRE0nqmu8LPF6/nIWn/cD HXZ05gIFXWGJ/WDpo88xmX4mukYgl0+9tZutwo1LH18uqzeg8LSrgi0XPqwQ2Xvp lLXLhJzBTrgypx558ub6nS6u0YD4DvHO/6yz5CHVgZC+nHQerd5BqxOyexP36JZl JZCL0pygK35e5Tx0miG5Zrvd1Tpoq+UD1UCMOCy6FYVHk9Wio4ezKYTx7DwglTX/ wL2HxHfrLNVq3lFTcl/TMGxS+dfhv6DxqHn1CtOsV2OSouecvpSlSdgzmnjgElib Ll/zKCXbxS8+P/9yj3EviZzqjLItqmKR+rIWW67Vm+Pky+g+wf9m1lA+leYkJj1r B2CXOtgIUycc4D0SRJXGMjMnsGrrgNTIUFh9lqq77XZw+dxeWuV+zMnPQ1SU5kPB FEadlVTwEWHEBrWtnin08F6NXzCgIQ1VBMgbR9BaV9UR2220BRBR2ocTycohiAbx BOL3k6NhU83JzybFtILrR8MVK7uEPFD7M+sby0j1qw== =QbPl -END PGP SIGNATURE- ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
