[ovirt-users] oVirt orb python3/fedora 31 support
Hi all, I was an happy user of oVirt orb on my laptop to do some testing (New features, foreman integration tests , ansible modules/playbooks/roles tests...) and it worked realy well, thanks guys ! Last week I've upgraded my laptop to fedora 31 and I have to uninstall ovirt-orb/lago related stuff to be able upgrade to this fedora version (related to python2 dependencies packages missing on fedora 31). Is there any planned python3/fedora 31 support for ovirt-orb/lago-ovirt/lago ? If not there is any simple replacement solution to spin up a light ovirt env to this kind of tests ? Have a nice day. Baptiste ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/MXRH57NT27U5GUM65PNDTYOYINFGJEGS/
[ovirt-users] Re: Inconsistencies beteween WebUI, API read verbs and API write verbs
Hello, - On 16 Apr, 2019, at 20:24, Ondra Machacek omach...@redhat.com wrote: > Hello, > > instance type module was merged into Ansible 2.8: > > https://github.com/ansible/ansible/pull/54782 Nice ! Thanks for your responsiveness and for working on this ! Sadly, I think there is some bugs, I found at least two [6] [7] when reading the code few minutes to see if attributes we wanted to manage are present. I will test it and report what I will found when I will test it. I've a long flight at the end of the week it's a good candidate to pass the time faster ;) > > You can try it, if all is working fine for you. > > But the issue you had is just missing header 'All-content: true', which > enable listing all attributes. > > $ curl -H 'All-content: true' -u user@profile:password -k > https://fqdn/ovirt-engine/api/instancetypes I made my tests with the python SDK, I didn't see any references to this header in docs that I had read, thank you for the pointer. Just after your mail the only references I found about it for the python sdk is just what returns this github search [8], so I tried the following: [...] >>> instance_types_service.list(search='name=C1-Large-BIOS', all_content=True) >>> >>> [] >>> instance_types_service.list(search='name=C1-Large-UEFI', all_content=True) >>> [] >>> instance_types_service.list(search='name=C1-Large-BIOS', >>> all_content=True)[0].virtio_scsi >>> instance_types_service.list(search='name=C1-Large-UEFI', >>> all_content=True)[0].bios >>> instance_types_service.list(search='name=C1-Large-BIOS', >>> all_content=True)[0].virtio_scsi >>> instance_types_service.list(search='name=C1-Large-UEFI', >>> all_content=True)[0].bios >>> But it returns nothing. So I tried the curl command that you provided above, I can see the virtio_scsi attribute (that is not present if 'All-content: true' header is not set), but I cannot see any bios reference for an instance type where I defined a different bios type than the default via WebUI. So for me, two conclusion now: * The ovirt python sdk don't pass the 'All-content: true' header on instance type read operations * There is some inconsistencies between WebUI and API (at least for bios attribute) I forgot to mention that I make my tests on the last ovirt-orb 4.3 version (4.3.0.4-1.el7) Have a nice day. Cheers. > Ondra > > On 16/04/2019 16:26, Baptiste Agasse wrote: >> Hi All, >> >> As I stated in a previous thread, we use instances types and wanted to >> automate >> some parts to manage it [1]. Thansk to ovirt-orb/lago and pointers given in >> the >> last thread, I'm working on ansible an module to manage ovirt instance types, >> but I'm facing some troubles for some of instance type attributes. From the >> API, I don't have access to all fields provided via WebUI (eg: Custom >> Emulated >> Machine), and it seems that some fields can be added/updated via the API but >> are not part of the response when you read an instance type (eg: VirtIO-SCSI >> Enabled). Provided examples are not exhaustive. I tried to find my way in the >> oVirt engine code-base to see if the fix will be easy for a non java >> developer >> like me. I find, I think, that it seems to be some API definitions for >> instance >> type [2] that define, if I understand it well, all verbs that can be applied >> to >> each resource and what field can be put when adding an instance type, but >> nothing about fields to be included when you read a resource (and I'm not >> sure >> if its related to v4 API). I find also some java code [3] [4] that seems >> related to this but As I'm not a java developer, its a little bit difficult >> for >> me to find my path in it. For me this inconsistencies are a bug, but as you >> stated that instance types are in deep maintenance mode, do you think that >> bug >> will get some attention ? >> >> My objective is to have a ansible module that manage the hardware/bios >> related >> stuff (memory, boot sequence, scsi controller, bios type, almost all the >> things) and HA for instance type. >> >> Have a nice day. >> >> Cheers. >> >> [1]: >> https://lists.ovirt.org/archives/list/users@ovirt.org/message/TJAXYBMSIAAAYLAYCSLOTONY54WT7K3O/ >> [2]: >> https://github.com/oVirt/ovirt-engine/blob/mas
[ovirt-users] Inconsistencies beteween WebUI, API read verbs and API write verbs
Hi All, As I stated in a previous thread, we use instances types and wanted to automate some parts to manage it [1]. Thansk to ovirt-orb/lago and pointers given in the last thread, I'm working on ansible an module to manage ovirt instance types, but I'm facing some troubles for some of instance type attributes. From the API, I don't have access to all fields provided via WebUI (eg: Custom Emulated Machine), and it seems that some fields can be added/updated via the API but are not part of the response when you read an instance type (eg: VirtIO-SCSI Enabled). Provided examples are not exhaustive. I tried to find my way in the oVirt engine code-base to see if the fix will be easy for a non java developer like me. I find, I think, that it seems to be some API definitions for instance type [2] that define, if I understand it well, all verbs that can be applied to each resource and what field can be put when adding an instance type, but nothing about fields to be included when you read a resource (and I'm not sure if its related to v4 API). I find also some java code [3] [4] that seems related to this but As I'm not a java developer, its a little bit difficult for me to find my path in it. For me this inconsistencies are a bug, but as you stated that instance types are in deep maintenance mode, do you think that bug will get some attention ? My objective is to have a ansible module that manage the hardware/bios related stuff (memory, boot sequence, scsi controller, bios type, almost all the things) and HA for instance type. Have a nice day. Cheers. [1]: https://lists.ovirt.org/archives/list/users@ovirt.org/message/TJAXYBMSIAAAYLAYCSLOTONY54WT7K3O/ [2]: https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/restapi/interface/definition/src/main/resources/rsdl_metadata.yaml#L3990 [3]: https://github.com/oVirt/ovirt-engine/blob/ede62008318d924556bc9dfc5710d90e9519670d/backend/manager/modules/restapi/jaxrs/src/main/java/org/ovirt/engine/api/restapi/resource/BackendInstanceTypesResource.java [4]: https://github.com/oVirt/ovirt-engine/blob/ede62008318d924556bc9dfc5710d90e9519670d/backend/manager/modules/restapi/types/src/main/java/org/ovirt/engine/api/restapi/types/InstanceTypeMapper.java [5]: https://ovirt.github.io/ovirt-engine-sdk/4.1/types.m.html#ovirtsdk4.types.InstanceType -- Baptiste ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/7I745JFB5XXHHX4BFTJAOXHJNH3TKIHC/
[ovirt-users] Re: Please don't remove instance type
- Le 15 Fév 19, à 16:36, Michal Skrivanek a écrit : BQ_BEGIN On 12 Feb 2019, at 22:21, Greg Sheremeta < [ mailto:gsher...@redhat.com | gsher...@redhat.com ] > wrote: Hi! On Sat, Feb 2, 2019 at 1:35 PM Baptiste Agasse < [ mailto:baptiste.aga...@lyra-network.com | baptiste.aga...@lyra-network.com ] > wrote: BQ_BEGIN Hi all, We are happy oVirt users for some years now (we started with 3.6, now on 4.2) and we manage most of our virtualization stacks with it. To provision and manage our machines, we use the foreman (for bare metal and virtual machines) on top of it. I made some little contributions to the foreman and other underlying stuff to have a deeper integration with oVirt, like to be able to select instance type directly from foreman interface/api and we rely on it. We use instance types to standardize our vms by defining system resources (memory, cpu and cpu topology) console type, boot options. On top of that we plan to use templates to apply OS (CentOS 7 and CentOS 6 actually). Having resources definitions separated from OS installation help us to keep instance types and templates lists small and don't bother users about some technical underlying stuff. As we are interested in automating oVirt maintenance tasks and configuration with ansible, I asked at FOSDEM oVirt booth if there is any ansible module to manage instance types in Ovirt as I didn't find it in ovirt ansible infra repo. The person to whom I asked the question said that you are planning to remove instance types from ovirt, and this make me sad :(. So here I am to ask why do you plan to remove instance types from oVirt. As far as I know, it's fairly common to have "instance types" / "flavors" / "sizes" on one side and then templates (bare OS, preinstalled appliances...) on other side and pick one of each to make an instance. If this first part is missing in future version of ovirt, it will be a pain point for us. So, my question is, do you really plan to remove instances type definitely ? I don't know the future plans (maybe someone else can comment), but I have heard that instance types are barely used. You might be the first person I know of who is using them. The argument for keeping templates but removing instance types is probably that templates already are effectively instance types. That's why I never use them. For example, create a CentOS template with 16 CPUs, 32GB RAM, 500GB disk ... that's effectively a large instance type. Create another template with 1 CPU, 2GB RAM, 30GB disk ... that's effectively a small instance type. Is there a use case beyond this that instance types provide that templates don’t? BQ_END It was supposed to give better abstraction for hw, and more importantly something you can change later on and it gets reflected in all VMs using that type. Problem with that is that it got quite complex and we never really found the right cut between what belongs to Instance and what to Template. It works…but there are few corner cases here and there which are quite difficult to fix. But no, we do not plan to remove them. It’s just in a deep maintenance mode where we don’t really invest time to cover REST, ansible and all the bells and whistles. If it works for you, great. If not and you would want to submit a fix then please feel free to do so too. Thanks, michal BQ_END Hi, First, thank you both for your answers, and sorry for the delay. To be more clear on how we use instance types and templates, we use it like our external cloud providers use this kind of concepts: * Templates is a pre-provisionned OS (and maybe one or more application installed on top of it). Template needs storage space on storage domain(s) to be stored. * Instance types are "size" and other "metadata" applied to the template/VM (eg: CPUs/Cores count, RAM size, headless VM, SPICE, or VNC ?, scsi support ? HA ? ...). You can have a lot of "profiles" at "no cost" because it's just configuration IMHO, on our workload, as we have a limited set of templates but a lot of different "sizes/types" of VMs. If instead of using instance types + templates, we only use templates we will have a lot of templates with mostly the same OSes/application preinstalled on it and the maintenance/storage costs will be a lot greater than today. For some corner cases, we also have "non templated" VMs and we apply instance type to it too (we enforce that any VM, build from template or not on our clusters have an instance type applied to it) We are greatly interested in ansible modules to maintain and configure our multiple oVirt stacks. I know that you will not invest time in providing ansible module for instance types as you said that part of ovirt is in maintenance mode, but contribution are welcome on this part (I saw
[ovirt-users] Please don't remove instance type
Hi all, We are happy oVirt users for some years now (we started with 3.6, now on 4.2) and we manage most of our virtualization stacks with it. To provision and manage our machines, we use the foreman (for bare metal and virtual machines) on top of it. I made some little contributions to the foreman and other underlying stuff to have a deeper integration with oVirt, like to be able to select instance type directly from foreman interface/api and we rely on it. We use instance types to standardize our vms by defining system resources (memory, cpu and cpu topology) console type, boot options. On top of that we plan to use templates to apply OS (CentOS 7 and CentOS 6 actually). Having resources definitions separated from OS installation help us to keep instance types and templates lists small and don't bother users about some technical underlying stuff. As we are interested in automating oVirt maintenance tasks and configuration with ansible, I asked at FOSDEM oVirt booth if there is any ansible module to manage instance types in Ovirt as I didn't find it in ovirt ansible infra repo. The person to whom I asked the question said that you are planning to remove instance types from ovirt, and this make me sad :(. So here I am to ask why do you plan to remove instance types from oVirt. As far as I know, it's fairly common to have "instance types" / "flavors" / "sizes" on one side and then templates (bare OS, preinstalled appliances...) on other side and pick one of each to make an instance. If this first part is missing in future version of ovirt, it will be a pain point for us. So, my question is, do you really plan to remove instances type definitely ? Cheers. -- Baptiste ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/TJAXYBMSIAAAYLAYCSLOTONY54WT7K3O/
[ovirt-users] Re: Resizing ovirt-engine disk
Hi Vojta, Thank you for your fast response. Do you know if this patch will be backported in 4.2 or it will land only in the next major release ? Have a nice day. Cheers. - Le 11 Oct 18, à 16:48, Vojtech Juranek vjura...@redhat.com a écrit : > Hi, > >> Can we grow the ovirt-engine disk like any other managed VM ? > > I assume you mean hosted engine. No, unfortunately this is not possible right > now. Today I proposed a patch [1] which should fix it. > >> And if not, how can we grow the ovirt-engine disk out of standard >> installation procedure ? > > it's possible, but includes calling vdsm client directly and editing the > database, so I'd recommend to avoid it. > > Cheers > Vojta > > [1] https://gerrit.ovirt.org/94855 > > > ___ > Users mailing list -- users@ovirt.org > To unsubscribe send an email to users-le...@ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/users@ovirt.org/message/GR7MTEEE3ZRJGKUVYQFAJPJTWPQGGJX7/ -- Baptiste AGASSE Lyra Network France, Senior GNU/Linux engineer 109 Rue de l'innovation, 31670 Labège - France Phone: (+33)5.67.22.31.87 Website: https://www.lyra.com ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/CP73EHJ7FQUUYQS4ONZZEF2HCUYIIIAF/
[ovirt-users] Resizing ovirt-engine disk
Hi all, We have a running ovirt installation on a SAN backend (installed in 4.0 via appliance, then updated to 4.1 and now in 4.2). At installation time we choose (or didn't change) the disk size and this one is about 10GB: fdisk -l /dev/vda Disk /dev/vda: 10.7 GB, 10737418240 bytes, 20971520 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk label type: dos Disk identifier: 0x000686fc Device Boot Start End Blocks Id System /dev/vda1 *20482097151910484736 83 Linux Can we grow the ovirt-engine disk like any other managed VM ? And if not, how can we grow the ovirt-engine disk out of standard installation procedure ? Have a nice day. Cheers. Baptiste. ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/QCWC7SQI7TFW5S3D3Y32CRGICFUZLWCT/
Re: [ovirt-users] Request for feedback on your db vacuum status
Hi, - Le 12 Déc 16, à 13:54, Shirly Radco a écrit : > Hi Baptiste, > Thank you very much for your reply. > I understand that you updated your DWH to collect every 60 seconds instead of > 20. > I'm the oVirt DWH maintainer and I would really appreciate if you can share > what > led you to this decision? > And some details on your setup. > Do you have it installed on the same machine as the engine or on a remote one? > Is your database remote or local? > What is the scale of you environment ? Number of hosts/vms... > This will may help us with the bug Roy mentioned. >From my mind, it was the ovirt_engine_history DB, i don't remember if there >was one or more tables that reported a lot of disk space usage. A full vacuum >corrected this size issue. For the bugzilla mentioned, i saw it and i applied the sampling suggestion to see if the DB grows more slowly. For our environment we have today (and growing) * 4 DC * 5 Clusters * 9 Storages domains (iscsi) * About 360 virtual disks in storage domains * 13 Hosts (growing) * About 250 VMs (growing) * The engine + DWH + DB server are all on the same server (hosted engine) * DB Size is about 3.2 GB (after the vacuum) * As all was on the same box, the engine setup via appliance was preferred and it was not possible to customize the size of the appliance at install/update, we wanted to keep the DB size as small as possible, but with some history. I saw that the engine appliance size will be customizable soon, so we will maybe extend the engine disk at update and keep a little bit more history or decrease the sampling interval again. Have a nice day. Regards. > Best regards, > Shirly Radco > BI Software Engineer > Red Hat Israel Ltd. > 34 Jerusalem Road > Building A, 4th floor > Ra'anana, Israel 4350109 > On Thu, Dec 8, 2016 at 5:01 PM, Baptiste Agasse < > baptiste.aga...@lyra-network.com > wrote: >> - Le 8 Déc 16, à 15:18, Roy Golan < rgo...@redhat.com > a écrit : >>> Hi all, >>> Following the thread about vacuum tool [1] I would like to gather some >>> feedback >>> about your deployment's db vacuum status The info is completely anonymous >>> and >>> function running it is a read only reporting one and should have little or >>> no >>> effect on the db. >>> The result can be pretty verbose but again will not disclose sensitive info. >>> Anyway review it before pasting it. It should look something like that(a >>> snippet of one table): >>> INFO: vacuuming "pg_catalog.pg_ts_template" >>> INFO: index "pg_ts_template_tmplname_index" now contains 5 row versions in 2 >>> pages >>> DETAIL: 0 index row versions were removed. >>> 0 index pages have been deleted, 0 are currently reusable. >>> CPU 0.00s/0.00u sec elapsed 0.00 sec. >>> 1. sudo su - postgres -c "psql engine -c 'vacuum verbose'" &> >>> /tmp/vacuum.log >>> 2. review the /tmp/vacuum.log >>> 3. paste it to http://paste.fedoraproject.org/ and reply with the link here >>> [1] http://lists.ovirt.org/pipermail/devel/2016-December/014484.html >>> Thanks, >>> Roy >>> ___ >>> Users mailing list >>> Users@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >> http://paste.fedoraproject.org/501769/48120789/ >> But, we run a full vacuum about one month ago that have free about 8GB of >> space >> and we set DWH_SAMPLING=60 to decrease data size of DWH (install is ~ 1y and >> half old, updated from 3.5 to 3.6 to 4.0). >> Have a nice day. >> Regards. >> -- >> Baptiste >> ___ >> Users mailing list >> Users@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users -- Baptiste ___ Users mailing list Users@ovirt.org http://lists.phx.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] Request for feedback on your db vacuum status
- Le 8 Déc 16, à 15:18, Roy Golan a écrit : > Hi all, > Following the thread about vacuum tool [1] I would like to gather some > feedback > about your deployment's db vacuum status The info is completely anonymous and > function running it is a read only reporting one and should have little or no > effect on the db. > The result can be pretty verbose but again will not disclose sensitive info. > Anyway review it before pasting it. It should look something like that(a > snippet of one table): > INFO: vacuuming "pg_catalog.pg_ts_template" > INFO: index "pg_ts_template_tmplname_index" now contains 5 row versions in 2 > pages > DETAIL: 0 index row versions were removed. > 0 index pages have been deleted, 0 are currently reusable. > CPU 0.00s/0.00u sec elapsed 0.00 sec. > 1. sudo su - postgres -c "psql engine -c 'vacuum verbose'" &> /tmp/vacuum.log > 2. review the /tmp/vacuum.log > 3. paste it to http://paste.fedoraproject.org/ and reply with the link here > [1] http://lists.ovirt.org/pipermail/devel/2016-December/014484.html > Thanks, > Roy > ___ > Users mailing list > Users@ovirt.org > http://lists.ovirt.org/mailman/listinfo/users http://paste.fedoraproject.org/501769/48120789/ But, we run a full vacuum about one month ago that have free about 8GB of space and we set DWH_SAMPLING=60 to decrease data size of DWH (install is ~ 1y and half old, updated from 3.5 to 3.6 to 4.0). Have a nice day. Regards. -- Baptiste ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] external users problem
Hi, - Le 4 Nov 16, à 18:22, Greg Sheremeta a écrit : > Sorry for the delay. Did anyone help out on this yet? If not, I can look now. No problem. No evolution on this side, if you can take a look, it will be nice. Thank you. > Greg > On Mon, Oct 24, 2016 at 8:52 AM, Martin Perina < mper...@redhat.com > wrote: >> Alex/Greg, could you please take a look? >> Thanks >> Martin >> On Mon, Oct 24, 2016 at 2:02 PM, Baptiste Agasse < >> baptiste.aga...@lyra-network.com > wrote: >>> Hi, >>> - Le 24 Oct 16, à 11:25, Martin Perina < mper...@redhat.com > a écrit : >>>> On Mon, Oct 24, 2016 at 11:18 AM, Baptiste Agasse < >>>> baptiste.aga...@lyra-network.com > wrote: >>>>> Hi Ondra, >>>>> - Le 24 Oct 16, à 10:36, Ondra Machacek omach...@redhat.com a écrit : >>>>> > On 10/21/2016 12:00 PM, Baptiste Agasse wrote: >>>>> >> Hi all, >>>>> >> We use ovirt 4.0.4 with FreeIPA as external provider. The external >>>>> >> provider was >>>>> >> configured via the 'ovirt-engine-extension-aaa-ldap-setup' command. The >>>>> >> authentication works fine, but in the webui, when you go on the >>>>> >> 'Active User >>>>> >> Sessions', all users uuid is showed as >>>>> >> '----'. >>>>> >> Other problem, maybe related, when a user create a VM, by default a >>>>> >> permission >>>>> >> is created with the role of 'UserVmManager'. On the 'Permissions' >>>>> >> pane, we see >>>>> >> a line with no value for User, Authorization provider, Namespace. The >>>>> >> only >>>>> >> value set on this line is the role (UserVmManager in that case). When >>>>> >> we try to >>>>> >> remove this line, an exception occurs in the webui that prevent >>>>> >> deletion of >>>>> >> this line. >>>>> > I've never see such issue with FreeIPA. Can you please share what's >>>>> > your IPA version? >>>>> > Can you also please share the log of error which occurs, when you try >>>>> > to remove the permission? >>>>> We have multiple ovirt envs, all ovirt version are the same as described, >>>>> but >>>>> FreeIPA servers are in different versions on these envs. We have one env >>>>> with >>>>> FreeIPA on CentOS 6 (ipa-server-3.0.0-42.el6.centos.x86_64) and the other >>>>> on >>>>> FreeIPA on CentOS 7 (ipa-server-4.2.0-15.0.1.el7.centos.6.1.x86_64). The >>>>> both >>>>> envs have the same problem. On our envs, the role mapping in oVirt is >>>>> done on >>>>> user groups and not on individual users. >>>>> For the permission problem, the problem only occurs when the VM is >>>>> created via >>>>> the user webui. Creating VM with API or admin webui is OK. When we try to >>>>> remove the permission, an UI exception occurs and no logs on the >>>>> engine.log >>>>> side. I've attached screenshots and ui.log. >>>> Unfortunately by default UI code is obfuscated, so we cannot find exact >>>> issue. >>>> Could you please perform following steps and send us new ui.log? >>>> 1. Install UI debug packages >>>> yum install ovirt-engine-webadmin-portal-debuginfo >>>> ovirt-engine-userportal-debuginfo >>>> 2. Restart ovirt-engine >>>> systemctl restart ovirt-engine >>>> 3. Reproduce the error and share up-to-date ui.log with use >>>> If needed more info about UI logs can be found at >>>> http://www.ovirt.org/develop/developer-guide/engine/engine-debug-obfuscated-ui/ >>> I've reproduced the error, see attached engine.log at VM creation time and >>> the >>> ui.log when trying to remove inconsistent permission. >>> Thanks. >>>> Thanks >>>> Martin Perina >>>> >>>>> >> This behavior is verified on all our oVirt environments (oVirt 4.0.4 + >>>>> >> FreeIPA) >>>>> >> Someone hit the same problem ? >>>>> >> Have a nice day. >>>>> >> Regards. >>>>> Regards. >>>>> -- >>>>> Baptiste AGASSE >>>>> ___ >>>>> Users mailing list >>>>> Users@ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/users >>> -- >>> Baptiste AGASSE > -- > Greg Sheremeta, MBA > Red Hat, Inc. > Sr. Software Engineer > gsher...@redhat.com -- Baptiste AGASSE Lyra Network France, Senior GNU/Linux engineer 109 Rue de l'innovation, 31670 Labège - France Phone: (+33)5.67.22.31.87 Fax: (+33)5.67.22.31.61 E-mail: baptiste.aga...@lyra-network.com Website: http://www.lyra-network.com ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] external users problem
Hi,
- Le 24 Oct 16, à 11:25, Martin Perina a écrit :
> On Mon, Oct 24, 2016 at 11:18 AM, Baptiste Agasse <
> baptiste.aga...@lyra-network.com > wrote:
>> Hi Ondra,
>> - Le 24 Oct 16, à 10:36, Ondra Machacek omach...@redhat.com a écrit :
>> > On 10/21/2016 12:00 PM, Baptiste Agasse wrote:
>> >> Hi all,
>> >> We use ovirt 4.0.4 with FreeIPA as external provider. The external
>> >> provider was
>> >> configured via the 'ovirt-engine-extension-aaa-ldap-setup' command. The
>> >> authentication works fine, but in the webui, when you go on the 'Active
>> >> User
>> >> Sessions', all users uuid is showed as
>> >> '----'.
>> >> Other problem, maybe related, when a user create a VM, by default a
>> >> permission
>> >> is created with the role of 'UserVmManager'. On the 'Permissions' pane,
>> >> we see
>> >> a line with no value for User, Authorization provider, Namespace. The only
>> >> value set on this line is the role (UserVmManager in that case). When we
>> >> try to
>> >> remove this line, an exception occurs in the webui that prevent deletion
>> >> of
>> >> this line.
>> > I've never see such issue with FreeIPA. Can you please share what's
>> > your IPA version?
>> > Can you also please share the log of error which occurs, when you try
>> > to remove the permission?
>> We have multiple ovirt envs, all ovirt version are the same as described, but
>> FreeIPA servers are in different versions on these envs. We have one env with
>> FreeIPA on CentOS 6 (ipa-server-3.0.0-42.el6.centos.x86_64) and the other on
>> FreeIPA on CentOS 7 (ipa-server-4.2.0-15.0.1.el7.centos.6.1.x86_64). The both
>> envs have the same problem. On our envs, the role mapping in oVirt is done on
>> user groups and not on individual users.
>> For the permission problem, the problem only occurs when the VM is created
>> via
>> the user webui. Creating VM with API or admin webui is OK. When we try to
>> remove the permission, an UI exception occurs and no logs on the engine.log
>> side. I've attached screenshots and ui.log.
> Unfortunately by default UI code is obfuscated, so we cannot find exact
> issue.
> Could you please perform following steps and send us new ui.log?
> 1. Install UI debug packages
> yum install ovirt-engine-webadmin-portal-debuginfo
> ovirt-engine-userportal-debuginfo
> 2. Restart ovirt-engine
> systemctl restart ovirt-engine
> 3. Reproduce the error and share up-to-date ui.log with use
> If needed more info about UI logs can be found at
> http://www.ovirt.org/develop/developer-guide/engine/engine-debug-obfuscated-ui/
I've reproduced the error, see attached engine.log at VM creation time and the
ui.log when trying to remove inconsistent permission.
Thanks.
> Thanks
> Martin Perina
>
>> >> This behavior is verified on all our oVirt environments (oVirt 4.0.4 +
>> >> FreeIPA)
>> >> Someone hit the same problem ?
>> >> Have a nice day.
>> >> Regards.
>> Regards.
>> --
>> Baptiste AGASSE
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
--
Baptiste AGASSE
2016-10-24 12:12:18,460 INFO [org.ovirt.engine.core.bll.AddVmFromTemplateCommand] (default task-54) [4e8be722] Lock Acquired to object 'EngineLock:{exclusiveLocks='[testperm=]', sharedLocks='[----=]'}'
2016-10-24 12:12:18,810 INFO [org.ovirt.engine.core.bll.AddVmFromTemplateCommand] (default task-54) [] Running command: AddVmFromTemplateCommand internal: false. Entities affected : ID: 8de6230e-9162-4b93-8ae8-cca33c97c836 Type: Cluster
Action group CREATE_VM with role type USER, ID: ---- Type: VmTemplateAction group CREATE_VM with role type USER
2016-10-24 12:12:19,851 INFO [org.ovirt.engine.core.bll.AddGraphicsDeviceCommand] (default task-54) [7f91c712] Running command: AddGraphicsDeviceCommand internal: true. Entities affected : ID: 3a97234b-5007-44f6-96cb-a279dfe850d6 Type: VMAction group EDIT_VM_PROPERTIES with role type USER
2016-10-24 12:12:20,010 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-54) [7f91c712] Correlation ID: 4e8be722, Job ID: 86b0cea2-6c2a-46b2-8df1-c943a09c8674, Call Stack: null, Custom Event ID: -1, Message: VM testperm was created by foo...@example.com-authz.
2016-10-2
[ovirt-users] external users problem
Hi all, We use ovirt 4.0.4 with FreeIPA as external provider. The external provider was configured via the 'ovirt-engine-extension-aaa-ldap-setup' command. The authentication works fine, but in the webui, when you go on the 'Active User Sessions', all users uuid is showed as '----'. Other problem, maybe related, when a user create a VM, by default a permission is created with the role of 'UserVmManager'. On the 'Permissions' pane, we see a line with no value for User, Authorization provider, Namespace. The only value set on this line is the role (UserVmManager in that case). When we try to remove this line, an exception occurs in the webui that prevent deletion of this line. This behavior is verified on all our oVirt environments (oVirt 4.0.4 + FreeIPA) Someone hit the same problem ? Have a nice day. Regards. -- Baptiste AGASSE ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] Inconsistency beteween hosted engine id and sanlock id
- Le 12 Avr 16, à 17:29, Simone Tiraboschi stira...@redhat.com a écrit : > On Tue, Apr 12, 2016 at 5:12 PM, Martin Sivak wrote: >> Hi, >> >> thanks for the summary, this is what I was suspecting. >> >> Just a clarification about the hosted engine host-id and lockspace. >> Hosted engine has a separate lockspace from VDSM and uses >> hosted-engine's host-id there consistently to protect a metadata >> whiteboard. It has nothing to do with the VM and there is no conflict >> here. >> >> >> The issue seems to be that the VDSM lockspace is being used when >> connect storage domain is called and both hosted engine and >> ovirt-engine can call the connect command. Unfortunately hosted engine >> does not know the vds_spm_id when mounting the volume for the first >> time (even before ovirt-engine VM is started) and uses the host-id for >> that. >> >> Now, there is probably no issue when all hosts accessing that storage >> domain are hosted engine enabled right from the start as the storage >> domain is mounted to all hosts before the engine starts and the >> locking uses consistent id (hosted engine host-id). >> >> The problem surfaces on a host where the engine manages to call the >> "connect hosted engine storage domain" first. Because engine uses the >> vds_spm_id for the requested lease and a collision happens. >> >> I do not see any easy fix at this moment, maybe except telling engine >> to use hosted engine id when it tries to connect the hosted engine >> storage domain. That feels like a hack, but might work. >> >> There also seems to be a bug for this issue now: >> https://bugzilla.redhat.com/show_bug.cgi?id=1322849 IMHO, it seems that this bug is related. >> >> Simone/Nir can you please comment on the issue to confirm that our >> findings are correct? > > I feel so but probably the solution you proposed is not enough since > we also allow to mix hosted-engine enabled hosts and regular hosts > (where you don't have any hosted-engine id) in the same cluster and, > once the hosted-engine-storage domain got imported by engine, the > engine will going to connect it on all of them. More than in one cluster, i think that problem is data-center wide. As you said as the hosted-engine-storage domain got imported by engine, any host in the DC can connect to it (in my case virt4 and virt7 are hosts from different clusters, but in the same DC). > >> Thanks >> >> Regards >> >> -- >> Martin Sivak >> SLA / oVirt >> >> On Tue, Apr 12, 2016 at 4:31 PM, Baptiste Agasse >> wrote: >>> Hi all, >>> >>> Last week we had problem on our ovirt infrastructure. The hosted engine >>> didn't >>> came up after the reboot of the host which hosted it. With the help of some >>> people on #ovirt IRC channel (msivak, nsoffer and some others, thank to all >>> of >>> them) i managed to have my hosted engine up and running, but the underlying >>> problem is still there. I think there is an inconsistency between sanlock >>> ID of >>> the hosts. >>> >>> Some background: >>> >>> We installed ovirt in 3.5 on CentOS 7 about 9 month ago. We have one DC >>> with two >>> clusters: >>> >>> cluster 1: 4 hosts (virt1, virt2, virt3, virt4) that were installed with >>> 'hosted-engine --deploy' so there are capable to run the engine VM. >>> cluster 2: 2 hosts (virt6 and virt7) that were installed via the webui, so >>> are >>> 'normal' ovirt hosts. >>> >>> Since that we have successfully upgraded ovirt to 3.6 and set our cluster >>> to 3.6 >>> compatibility mode. >>> >>> Some weeks after something broke and the virt4 host rebooted. After some >>> help on >>> the IRC channel, i managed to get the engine vm up and running. After that i >>> dug into the problem that seems to be around the sanlock part. >>> >>> After explanations, that i understand is: >>> >>> sanlock manage locks at DC level. there is an hosted_engine lock to manage >>> who >>> run the VM and there is a vdsm level lock on the hosted_engine disk (or any >>> other VM disks) to know who can write to the disk. >>> >>> The problem in my case is that on some hosts that were installed in 3.5, the >>> hosted_engine ID and the vds_spm_id are not the same, and some other host >>> have >>> it vds_spm_id identical to some other host hosted_engine_id. So
[ovirt-users] Inconsistency beteween hosted engine id and sanlock id
Hi all, Last week we had problem on our ovirt infrastructure. The hosted engine didn't came up after the reboot of the host which hosted it. With the help of some people on #ovirt IRC channel (msivak, nsoffer and some others, thank to all of them) i managed to have my hosted engine up and running, but the underlying problem is still there. I think there is an inconsistency between sanlock ID of the hosts. Some background: We installed ovirt in 3.5 on CentOS 7 about 9 month ago. We have one DC with two clusters: cluster 1: 4 hosts (virt1, virt2, virt3, virt4) that were installed with 'hosted-engine --deploy' so there are capable to run the engine VM. cluster 2: 2 hosts (virt6 and virt7) that were installed via the webui, so are 'normal' ovirt hosts. Since that we have successfully upgraded ovirt to 3.6 and set our cluster to 3.6 compatibility mode. Some weeks after something broke and the virt4 host rebooted. After some help on the IRC channel, i managed to get the engine vm up and running. After that i dug into the problem that seems to be around the sanlock part. After explanations, that i understand is: sanlock manage locks at DC level. there is an hosted_engine lock to manage who run the VM and there is a vdsm level lock on the hosted_engine disk (or any other VM disks) to know who can write to the disk. The problem in my case is that on some hosts that were installed in 3.5, the hosted_engine ID and the vds_spm_id are not the same, and some other host have it vds_spm_id identical to some other host hosted_engine_id. So in some case, some host can't acquire the lock on some disks and have different IDs in the sanlock space. Example, im my case: # # For the hosted_engine hosts: # [root@virt1 ~]# grep host_id /etc/ovirt-hosted-engine/hosted-engine.conf host_id=1 [root@virt2 ~]# grep host_id /etc/ovirt-hosted-engine/hosted-engine.conf host_id=2 [root@virt3 ~]# grep host_id /etc/ovirt-hosted-engine/hosted-engine.conf host_id=3 [root@virt4 ~]# grep host_id /etc/ovirt-hosted-engine/hosted-engine.conf host_id=4 # # For all hosts, including hosted engine: # [root@virt1 ~]# sanlock client status daemon 3a99892c-5d3a-4d3d-bac7-d35259363c98.virt1 p -1 helper p -1 listener p -1 status s hosted-engine:1:/var/run/vdsm/storage/377ae8e8-0eeb-4591-b50f-3d21298b4146/607719dd-b71e-4527-814a-964ed0c1f8ea/6a0b878d-fe7e-4fb6-bd5d-1254bebb0ca0:0 s 295207d7-41ea-4cda-a028-f860c357d46b:1:/dev/295207d7-41ea-4cda-a028-f860c357d46b/ids:0 s daf1b53c-7e29-4b18-a9e2-910605cc7080:1:/dev/daf1b53c-7e29-4b18-a9e2-910605cc7080/ids:0 s 680d5ed1-ed70-4340-a430-ddfa39ee3052:1:/dev/680d5ed1-ed70-4340-a430-ddfa39ee3052/ids:0 s 350e5736-41c0-4017-a8fd-9866edad:1:/dev/350e5736-41c0-4017-a8fd-9866edad/ids:0 s 377ae8e8-0eeb-4591-b50f-3d21298b4146:1:/dev/377ae8e8-0eeb-4591-b50f-3d21298b4146/ids:0 [root@virt2 ~]# sanlock client status daemon 48fe11a1-6c64-4a56-abf0-6f9690e6a8c2.virt2 p -1 helper p -1 listener p -1 status s hosted-engine:2:/var/run/vdsm/storage/377ae8e8-0eeb-4591-b50f-3d21298b4146/607719dd-b71e-4527-814a-964ed0c1f8ea/6a0b878d-fe7e-4fb6-bd5d-1254bebb0ca0:0 s 377ae8e8-0eeb-4591-b50f-3d21298b4146:2:/dev/377ae8e8-0eeb-4591-b50f-3d21298b4146/ids:0 s 295207d7-41ea-4cda-a028-f860c357d46b:3:/dev/295207d7-41ea-4cda-a028-f860c357d46b/ids:0 s daf1b53c-7e29-4b18-a9e2-910605cc7080:3:/dev/daf1b53c-7e29-4b18-a9e2-910605cc7080/ids:0 s 680d5ed1-ed70-4340-a430-ddfa39ee3052:3:/dev/680d5ed1-ed70-4340-a430-ddfa39ee3052/ids:0 s 350e5736-41c0-4017-a8fd-9866edad:3:/dev/350e5736-41c0-4017-a8fd-9866edad/ids:0 r 350e5736-41c0-4017-a8fd-9866edad:SDM:/dev/350e5736-41c0-4017-a8fd-9866edad/leases:1048576:26 p 9304 r 377ae8e8-0eeb-4591-b50f-3d21298b4146:d704cf05-e294-4ada-9627-920c9997cf22:/dev/377ae8e8-0eeb-4591-b50f-3d21298b4146/leases:49056:21 p 32747 [root@virt3 ~]# sanlock client status daemon 3388d8e5-922d-45ab-8ecb-6e321a7a8a4a.virt3 p -1 helper p -1 listener p -1 status s daf1b53c-7e29-4b18-a9e2-910605cc7080:2:/dev/daf1b53c-7e29-4b18-a9e2-910605cc7080/ids:0 s 680d5ed1-ed70-4340-a430-ddfa39ee3052:2:/dev/680d5ed1-ed70-4340-a430-ddfa39ee3052/ids:0 s 295207d7-41ea-4cda-a028-f860c357d46b:2:/dev/295207d7-41ea-4cda-a028-f860c357d46b/ids:0 s 350e5736-41c0-4017-a8fd-9866edad:2:/dev/350e5736-41c0-4017-a8fd-9866edad/ids:0 s 377ae8e8-0eeb-4591-b50f-3d21298b4146:2:/dev/377ae8e8-0eeb-4591-b50f-3d21298b414
Re: [ovirt-users] ovirt 3.5 engine web certificate
Hi, - Le 1 Sep 15, à 9:43, Sandro Bonazzola a écrit : > On Mon, Aug 31, 2015 at 6:08 PM, Alon Bar-Lev < alo...@redhat.com > wrote: >> - Original Message ----- >> > From: "Baptiste Agasse" < baptiste.aga...@lyra-network.com > >> > To: "users" < users@ovirt.org > >> > Sent: Monday, August 31, 2015 6:54:28 PM >> > Subject: [ovirt-users] ovirt 3.5 engine web certificate >> > Hi all, >> > I've followed the procedure to replace self signed certificate to one >> > issued >> > by our internal PKI to avoid security failure when users access to the >> > webui >>> ( >>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.5/html/Administration_Guide/appe-Red_Hat_Enterprise_Virtualization_and_SSL.html#Replacing_the_SSL_certificate_used_by_Red_Hat_Enterprise_Virtualization_Manager_to_identify_itself_to_users_connecting_over_https >> > ). >> > The connection to the webui now works fine without any security warning >> > (the >> > internal PKI CA is in the trusted CA of our clients OS). But on the other >> > hand, i've some troubles: >> > * I've to specify the --ca-file option for ovirt-shell and >> > engine-iso-uploader (i didn't test the engine-image-upload command), it >> > will >> > be nice if the documentation provide a way to replace this by default (or >> > use the trusted ca store of the OS ?). This is not a bug just some feedback >> > on the certificate change procedure that don't cover these side effects. >> This is [1], probably you want to modify the configuration files of these >> tools >> at /etc so you will have proper defaults. >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1146710 Thank you for this link. >> > * I can't add new ovirt-node anymore. >> If ovirt-node was added using previous certificate it "Remembers" that >> certificate. >> You can remove it from /etc/pki/vdsm/engine_web_ca.pem and try to register >> again. >> > * The ovirt-hosted-engine --deploy fails >> > on new nodes with an SSL error. To workaround this i've to modify the file >> > "/usr/lib/python2.7/site-packages/ovirtsdk/web/connection.py" around line >> > 233 to make an insecure connection to the engine and add the new node. I >> > didn't have tested to add a new node from the ovirt engine cli/webui but i >> > think it will be the same issue because the error occurs on the vdsm >> > activation that is common to the 'new hosted engine node' and 'new node' >> > deployment. I've seen https://bugzilla.redhat.com/show_bug.cgi?id=1059952 >> > but the workaround noted in the comment #8 didn't work for me. >> CC sandro for this. > Can you please share full sos report? The report is a little bit big (about 57MB) to be sent by mail, have you any procedure i can use to send it to you ? >> > Someone have more info on this issue or have the same problem ? >> > This deployment is on ovirt 3.5.3, CentOS 7 (engine and nodes). >> > Have a nice day. >> > Regards. >> > -- >> > Baptiste >> > ___ >> > Users mailing list >> > Users@ovirt.org >> > http://lists.ovirt.org/mailman/listinfo/users > -- > Sandro Bonazzola > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com -- Baptiste ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] ovirt 3.5 engine web certificate
Hi all, I've followed the procedure to replace self signed certificate to one issued by our internal PKI to avoid security failure when users access to the webui (https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.5/html/Administration_Guide/appe-Red_Hat_Enterprise_Virtualization_and_SSL.html#Replacing_the_SSL_certificate_used_by_Red_Hat_Enterprise_Virtualization_Manager_to_identify_itself_to_users_connecting_over_https). The connection to the webui now works fine without any security warning (the internal PKI CA is in the trusted CA of our clients OS). But on the other hand, i've some troubles: * I've to specify the --ca-file option for ovirt-shell and engine-iso-uploader (i didn't test the engine-image-upload command), it will be nice if the documentation provide a way to replace this by default (or use the trusted ca store of the OS ?). This is not a bug just some feedback on the certificate change procedure that don't cover these side effects. * I can't add new ovirt-node anymore. The ovirt-hosted-engine --deploy fails on new nodes with an SSL error. To workaround this i've to modify the file "/usr/lib/python2.7/site-packages/ovirtsdk/web/connection.py" around line 233 to make an insecure connection to the engine and add the new node. I didn't have tested to add a new node from the ovirt engine cli/webui but i think it will be the same issue because the error occurs on the vdsm activation that is common to the 'new hosted engine node' and 'new node' deployment. I've seen https://bugzilla.redhat.com/show_bug.cgi?id=1059952 but the workaround noted in the comment #8 didn't work for me. Someone have more info on this issue or have the same problem ? This deployment is on ovirt 3.5.3, CentOS 7 (engine and nodes). Have a nice day. Regards. -- Baptiste ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] Hosted engine multipath iscsi
Hi all, I'm currently testing ovirt 3.5 on centos 7, with hosted engine on iscsi equallogic SAN.. It's running fine, i've configured multipath through the engine (http://www.ovirt.org/Feature/iSCSI-Multipath) for VMs storage but i didn't find any documentation on hosted engine iscsi multipath. There is a way to configure iscsi multipath for the engine storage ? Have a nice day. Regards. -- Baptiste ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] so, what do you want next in oVirt?
Hi all, - Mail original - > De: "Itamar Heim" > À: users@ovirt.org > Envoyé: Mardi 20 Août 2013 23:19:16 > Objet: [Users] so, what do you want next in oVirt? > > earlier in the year we did a survey for feature requests / > improvements > / etc. > > since a lot of things were added, and priorities usually change, I'd > like to ask again for "what do you need the most from oVirt / what > are > your pain points" next? > > below[1] I've listed my understanding of what already went in from > previous survey requests (to various degrees of coverage). > > Thanks, > Itamar > > [1] from the top 12 > V Allow disk resize > V Integrate Nagios/Zabbix monitoring - via a ui plugin > V Highly Available engine - via hosted engine[2] > V Open vSwitch integration - via neutron integration > X Allow cloning VMs without template > ? Enable hypervisor upgrade/updates through engine[3] > V Allow engine on an oVirt hosted VM - via hosted engine[2] > V Enable guest configuration (root password, SSH keys, network) via >guest agent in engine - via cloud-init > X Integrate v2v into engine > ? Bond/extend ovirtmgmt with a second network for HA/increased >bandwidth[4] > X Integrate scheduling of snapshots and VM export for backups in >engine[5] > V Spice – support Google Chrome - via mime based launch > > > Other items mentioned in previous survey which should be covered by > now: > - Fix timeout when adding local host during all-in-one configuration > - Fix engine set-up when SELinux is disabled > - Provide packages for el6 (CentOS, Red Hat Enterprise Linux) > - Allow multiple VMs to be deployed from the same template at the > same >time > - ISO domains on local/GlusterS > - Show IP addresses in Virtual Machines->Network Interfaces > - OpenStack Quantum support (now called Neutron) > - noVNC support > - Support spice.html5 and websocket proxy > - Add other guest OSes to list > - Port oVirt guest agent to Ubuntu[6] > - SLA - Allow resource time-sharing > - Spice - Mac client (via mime based launch) > - Spice - port XPI plug-in to Windows (not sure this will happen, but >mime based launch allows using firefox now) > - Spice - client for Ubuntu/Debian (should be covered via mime based >launch) > > > [2] hosted engine is in active development, but not released yet. > [3] host update is supported, but not for general yum update. > [4] a lot of improvements were done in this space, but i'm not sure > if > they cover this exact use case > [5] backup api is now being pushed to master, and orchestration of > backups should probably happen via 3rd part backup vendors? > [6] I'm not sure packaging exists yet, but ubuntu is covered for the > basic functionality of the guest agent. > ___ > Users mailing list > Users@ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > Thanks for this thread ! - ISCSI EqualLogic SAN support or use standard iscsi tools/configuration - SSO for webui and cli (IPA integration) - PXE boot for nodes - VMs dependencies on startup Have a nice day. Regards. --- Baptiste ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] iSCSI multipath with EqualLogic SAN
Hi all, - Mail original - > De: "Sven Knohsalla" > À: "Chris Noffsinger" , "Jonathan Horne" > > Cc: "Baptiste AGASSE" , users@ovirt.org > Envoyé: Vendredi 22 Février 2013 06:30:11 > Objet: AW: [Users] iSCSI multipath with EqualLogic SAN > > > > > Never heard of HIT before. > Seems to be a proprietary Dell solution? > Ok, I just high-lighted the classical /most common SAN connection :) > > We are using a Dell MD3220i (much smaller then EQ series) with MD1200 > units, and yes the network configuration for subnet separated > multipathing seems to be more complicated at first, > > but it will give you load-balancing and auto fail-over functionality. > > Of course a nice and quick alternative as suggested here “…but you > can configure your nodes to use the other paths using the command > line on the Centos nodes…”, > > is also possible. > > > > Cheers, > Sven. > > > > Von: Chris Noffsinger [mailto:cnoff...@gmail.com] > Gesendet: Do nnerstag, 21. Februar 2013 20:05 > An: Jonathan Horne > Cc: Sven Knohsalla; Baptiste AGASSE; users@ovirt.org > Betreff: Re: [Users] iSCSI multipath with EqualLogic SAN > > > > > We have 2 Equallogic PS4100s. And someone more knowledgeable may > prove me wrong here but, > > > > > Multipathd is not my most favorite thing to configure, but you can > configure your nodes to use the other paths using the command line > on the Centos nodes. > > > > > > Yeah Dell will tell you that they want you to use their software > (like the mem plugin in Vmware) but the Linux OS will see the other > paths and treat it like any other SAN, you are just going to have to > configure them to use them. The link sent earlier in the thread is > the official guide to doing that. > > > > > > https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/pdf/DM_Multipath/Red_Hat_Enterprise_Linux-6-DM_Multipath-en-US.pdf > > > Here is another Doc I used that is for Rhel5 but I beleive the > multipath commands are the same: > > > > > > http://www.equallogic.com/WorkArea/downloadasset.aspx?id=8727 > > > > > > > > > On Thu, Feb 21, 2013 at 1:09 PM, Jonathan Horne < jho...@skopos.us > > wrote: > > Ive discussed this at length with dell's EQ support team, and on a > regular system that's connected in to an equallogic san, all the > iscsi ports would be on the same subnet. The kicker is, dell really > wants you to use their specialized driver/iscsiinitiator to access > (known as their HIT kit...host integration tools), and the HIT kit > handles establishing all the multiple sessions into the EQ SAN. > > Unfortunately, equallogic doesnt support RHEV (and thus ovirt), and > ovirt does not seem to execute the commands the HIT driver would > want to intitiate multiple connections. > > Dell says that the use of bonding for iscsi just begs for tcp > retransmits. since bonding is the only method of failover I see for > now, were using anyway against their recommendations (so far zero > retransmits, but were not running our systems hard yet). > > Cheers, > Jonathan > > -Original Message- > From: users-boun...@ovirt.org [mailto: users-boun...@ovirt.org ] On > Behalf Of Sven Knohsalla > Sent: Thursday, February 21, 2013 8:55 AM > To: Baptiste AGASSE > Cc: users@ovirt.org > Subject: Re: [Users] iSCSI multipath with EqualLogic SAN > > Hi Baptiste, > > usually a SAN doesn't support bonding (see post of Nicolas) of its > interfaces, so you have to use multipathing technology. > > You have to separate all nics in different subnets so multipath can > work. > Command multipath -ll with show the connected paths. > > If you "merge" all paths in one subnet you will have the > result/behavior you just posted. > > So this is less oVirt related, more network specific. > We have a running iSCSI config with 4 networks and oVirt runs well. > > Maybe the following link will help you here: > https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/pdf/DM_Multipath/Red_Hat_Enterprise_Linux-6-DM_Multipath-en-US.pdf > > Cheers, > Sven. > > -Ursprüngliche Nachricht- > Von: users-boun...@ovirt.org [mailto: users-boun...@ovirt.org ] Im > Auftrag von Nicolas Ecarnot > Gesendet: Donnerstag, 21. Februar 2013 15:48 > An: users@ovirt.org > Betreff: Re: [Users] iSCSI multipath with EqualLogic SAN > > Le 21/02/2013 11:30, Baptiste AGASSE a écrit : > > Hi all, > > > > I'm testing ovirt 3.1 on centos boxes. I setup ovirt
[Users] iSCSI multipath with EqualLogic SAN
Hi all, I'm testing ovirt 3.1 on centos boxes. I setup ovirt management node and 4 vdsm hosts. vdsm hosts have 2 nics on the SAN subnet. When i create a iscsi storage domain, it use only one of the two nics on the SAN network (showed with iscsiadm -m session on vdsm nodes). Does ovirt support multiples nics on the same subnet for iscsi SAN connection ? Have a nice day. Regards. Baptiste. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
