Re: [Users] engine-manage-domains can't add user , domain
- Original Message - > From: "T-Sinjon" > To: "Roy Golan" > Cc: "Oved Ourfalli" , users@ovirt.org > Sent: Tuesday, May 22, 2012 5:33:06 AM > Subject: Re: [Users] engine-manage-domains can't add user , domain > > HI, Roy > > I have update my engine to newest use ' rpm -Uvh ' - > > I used rpms from > http://jenkins.ovirt.org/view/ovirt_engine/job/ovirt_engine_create_rpms/ > . > > [root@ovirt-engine ~]# rpm -qa | grep ovirt-engine > ovirt-engine-dbscripts-3.1.0_0001-1.8.fc16.x86_64 > ovirt-engine-config-3.1.0_0001-1.8.fc16.x86_64 > ovirt-engine-log-collector-3.1.0_0001-1.8.fc16.x86_64 > ovirt-engine-3.1.0_0001-1.8.fc16.x86_64 > ovirt-engine-image-uploader-3.1.0_0001-1.8.fc16.x86_64 > ovirt-engine-restapi-3.1.0_0001-1.8.fc16.x86_64 > ovirt-engine-sdk-1.3-1.fc16.noarch > ovirt-engine-tools-common-3.1.0_0001-1.8.fc16.x86_64 > ovirt-engine-backend-3.1.0_0001-1.8.fc16.x86_64 > ovirt-engine-jbossas-1.2-2.fc16.x86_64 > ovirt-engine-iso-uploader-3.1.0_0001-1.8.fc16.x86_64 > ovirt-engine-setup-3.1.0_0001-1.8.fc16.x86_64 > ovirt-engine-userportal-3.1.0_0001-1.8.fc16.x86_64 > ovirt-engine-jboss-deps-3.1.0_0001-1.8.fc16.x86_64 > ovirt-engine-webadmin-portal-3.1.0_0001-1.8.fc16.x86_64 > ovirt-engine-genericapi-3.1.0_0001-1.8.fc16.x86_64 > ovirt-engine-notification-service-3.1.0_0001-1.8.fc16.x86_64 > > and now I add domain again , it still have error and there's no log > can find from engine-manage-domains.log, what should i do now ? > > [root@ovirt-engine ~]# engine-manage-domains -action=add > -domain=local -user=admin -provider=IPA -interactive > Failed reading current configuration. Details: Error "Error fetching > LDAPProviderTypes value: no such entry with version 'general'." > while reading configuration value LDAPProviderTypes. > Looks like your database isn't updated. I'm not sure whether a database upgrade is run automatically when you update the RPMs, but according to the error you get it is probably isn't. In the RPM ovirt-engine-dbscripts-3.1.0_0001-1.8.fc16.x86_64 you should have an upgrade script. (use rpm -qil on ovirt-engine-dbscripts-3.1.0_0001-1.8.fc16.x86_64 to find out where it is, as I'm not sure exactly where it's installed). Run it using the command" ./upgrade.sh -u postgres It will upgrade your database. Oved > On 15 May, 2012, at 5:10 PM, Roy Golan wrote: > > > On 05/15/2012 08:48 AM, Yair Zaslavsky wrote: > >> On 05/15/2012 08:35 AM, Oved Ourfalli wrote: > >>> > >>> - Original Message - > From: "T-Sinjon" > To: "Oved Ourfalli" > Cc: users@ovirt.org > Sent: Tuesday, May 15, 2012 5:53:16 AM > Subject: Re: [Users] engine-manage-domains can't add user , > domain > > after use kinit login tsinjon , the error changes to , why this > happened? > > [root@ovirt-engine ~]# engine-manage-domains -action=add > -domain='local' -user='tsinjon' -interactive > Enter password: > > No user in Directory was found for tsinjon@LOCAL. Trying next > LDAP > server in list > Failure while testing domain local. Details: No user information > was > found for user > > >>> Can't see why kinit matters here, but looking at your command I > >>> noticed you used single quotes for the user and domain name. > >>> I'm not sure it knows to handle this correctly. > >>> Did you try without the quotes? > >>> > >>> Also, what version are you working with? > >>> We had a problem a few weeks ago, of identifying the correct ldap > >>> provider. To fix that we added an option to specify the ldap > >>> provider type. It determines which query will be used in order > >>> to get the user details. > >>> > >>> cc-ing Roy, which added this. iirc it is mandatory to provide > >>> this option, so you probably don't have this option in your > >>> environment. > >>> Roy - is there an upstream release with this fix? > >> Oved - this was merged upstream. > >> T-Sinjon - have you cloned the git repo and compiled or are you > >> using RPMs? > > T-Sinjon - once your updated you'll be able to specify the which > > type is your LDAP server and overcome this problem. > > > > e.g. > > engine-manage-domains -action=add -domain='local' -provider=ipa > > -user='tsinjon' -interactive > > > > > >> > >> > >>> Regards, > >>> Oved > On 15 May, 2012, at 10:47 AM, T-Sinjon wrote: > > > I have added those SRV info into my zone file , and it did go , > > the log looks fine , but engine-manage-domains still return > > error > > > > 2012-05-15 10:45:19,222 INFO > > [org.ovirt.engine.core.utils.kerberos.ManageDomains] Creating > > kerberos configuration for domain(s): local > > 2012-05-15 10:45:19,258 INFO > > [org.ovirt.engine.core.utils.kerberos.ManageDomains] > > Successfully > > created kerberos configuration for domain(s): local > > 2012-05-15 10:45:19,259 INFO > > [org.ovirt.engine.core.utils.kerberos.ManageDomains] Testing > > kerberos configu
Re: [Users] engine-manage-domains can't add user , domain
HI, Roy I have update my engine to newest use ' rpm -Uvh ' - I used rpms from http://jenkins.ovirt.org/view/ovirt_engine/job/ovirt_engine_create_rpms/ . [root@ovirt-engine ~]# rpm -qa | grep ovirt-engine ovirt-engine-dbscripts-3.1.0_0001-1.8.fc16.x86_64 ovirt-engine-config-3.1.0_0001-1.8.fc16.x86_64 ovirt-engine-log-collector-3.1.0_0001-1.8.fc16.x86_64 ovirt-engine-3.1.0_0001-1.8.fc16.x86_64 ovirt-engine-image-uploader-3.1.0_0001-1.8.fc16.x86_64 ovirt-engine-restapi-3.1.0_0001-1.8.fc16.x86_64 ovirt-engine-sdk-1.3-1.fc16.noarch ovirt-engine-tools-common-3.1.0_0001-1.8.fc16.x86_64 ovirt-engine-backend-3.1.0_0001-1.8.fc16.x86_64 ovirt-engine-jbossas-1.2-2.fc16.x86_64 ovirt-engine-iso-uploader-3.1.0_0001-1.8.fc16.x86_64 ovirt-engine-setup-3.1.0_0001-1.8.fc16.x86_64 ovirt-engine-userportal-3.1.0_0001-1.8.fc16.x86_64 ovirt-engine-jboss-deps-3.1.0_0001-1.8.fc16.x86_64 ovirt-engine-webadmin-portal-3.1.0_0001-1.8.fc16.x86_64 ovirt-engine-genericapi-3.1.0_0001-1.8.fc16.x86_64 ovirt-engine-notification-service-3.1.0_0001-1.8.fc16.x86_64 and now I add domain again , it still have error and there's no log can find from engine-manage-domains.log, what should i do now ? [root@ovirt-engine ~]# engine-manage-domains -action=add -domain=local -user=admin -provider=IPA -interactive Failed reading current configuration. Details: Error "Error fetching LDAPProviderTypes value: no such entry with version 'general'." while reading configuration value LDAPProviderTypes. On 15 May, 2012, at 5:10 PM, Roy Golan wrote: > On 05/15/2012 08:48 AM, Yair Zaslavsky wrote: >> On 05/15/2012 08:35 AM, Oved Ourfalli wrote: >>> >>> - Original Message - From: "T-Sinjon" To: "Oved Ourfalli" Cc: users@ovirt.org Sent: Tuesday, May 15, 2012 5:53:16 AM Subject: Re: [Users] engine-manage-domains can't add user , domain after use kinit login tsinjon , the error changes to , why this happened? [root@ovirt-engine ~]# engine-manage-domains -action=add -domain='local' -user='tsinjon' -interactive Enter password: No user in Directory was found for tsinjon@LOCAL. Trying next LDAP server in list Failure while testing domain local. Details: No user information was found for user >>> Can't see why kinit matters here, but looking at your command I noticed you >>> used single quotes for the user and domain name. >>> I'm not sure it knows to handle this correctly. >>> Did you try without the quotes? >>> >>> Also, what version are you working with? >>> We had a problem a few weeks ago, of identifying the correct ldap provider. >>> To fix that we added an option to specify the ldap provider type. It >>> determines which query will be used in order to get the user details. >>> >>> cc-ing Roy, which added this. iirc it is mandatory to provide this option, >>> so you probably don't have this option in your environment. >>> Roy - is there an upstream release with this fix? >> Oved - this was merged upstream. >> T-Sinjon - have you cloned the git repo and compiled or are you using RPMs? > T-Sinjon - once your updated you'll be able to specify the which type is your > LDAP server and overcome this problem. > > e.g. > engine-manage-domains -action=add -domain='local' -provider=ipa > -user='tsinjon' -interactive > > >> >> >>> Regards, >>> Oved On 15 May, 2012, at 10:47 AM, T-Sinjon wrote: > I have added those SRV info into my zone file , and it did go , > the log looks fine , but engine-manage-domains still return error > > 2012-05-15 10:45:19,222 INFO > [org.ovirt.engine.core.utils.kerberos.ManageDomains] Creating > kerberos configuration for domain(s): local > 2012-05-15 10:45:19,258 INFO > [org.ovirt.engine.core.utils.kerberos.ManageDomains] Successfully > created kerberos configuration for domain(s): local > 2012-05-15 10:45:19,259 INFO > [org.ovirt.engine.core.utils.kerberos.ManageDomains] Testing > kerberos configuration for domain: local > > [root@ovirt-engine ~]# engine-manage-domains -action=add > -domain='local' -user='tsinjon' -interactive > Enter password: > > Error: exception message: Integrity check on decrypted field > failed (31) - PREAUTH_FAILED > Failure while testing domain local. Details: Kerberos error. Please > check log for further details. > > > On 14 May, 2012, at 10:12 PM, Oved Ourfalli wrote: > >> >> - Original Message - >>> From: "T-Sinjon" >>> To: users@ovirt.org >>> Sent: Monday, May 14, 2012 5:07:46 PM >>> Subject: [Users] engine-manage-domains can't add user , domain >>> >>> >>> I use FreeIPA to authenticate users, ipa user-add has no >>> problem, >>> but when i do : >>> >>> [root@ovirt-engine ~]# engine-manage-domains -action=add >>> -domain='local' -user='tsinjon' -interactive >>> >>> Error: Authentication Failed. Pl
Re: [Users] Host can't join the cluster
Usually, you can have more information in these files: in node host: /var/log/vdsm/log, /vdsm/log/libvirt.log in engine: /var/log/engine.log On 2012-5-16 18:58, ov...@qip.ru wrote: After upgrade of vdsm from 4.9.6-0.196.gitb8b79b5 to 4.9.6-0.201.git98e8078 engine set host in nonoperational mode, the error is "Host kvm04 is compatible with versions (3.0,3.1) and cannot join Cluster Default which is set to version 3.1." -- ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users -- Shu Ming IBM China Systems and Technology Laboratory ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Host can't join the cluster
On Mon, May 21, 2012 at 09:55:11AM -0400, Omer Frenkel wrote: > > > - Original Message - > > From: "Yair Zaslavsky" > > To: "Itamar Heim" > > Cc: users@ovirt.org > > Sent: Monday, May 21, 2012 4:46:20 PM > > Subject: Re: [Users] Host can't join the cluster > > > > On 05/19/2012 05:54 PM, Itamar Heim wrote: > > > On 05/18/2012 04:20 PM, Dan Kenigsberg wrote: > > >> On Thu, May 17, 2012 at 10:03:31PM +0300, Itamar Heim wrote: > > >>> On 05/17/2012 02:11 PM, Omer Frenkel wrote: > > >>> ... > > >>> > > > > > > second, iirc, the definition was vdsm can override engine vdsm > > > version > > > check, so a newer vdsm could still report it will work with an > > > older > > > engine, without needing to change the older engine to match it? > > > > > > > i agree as well, i think the intention was for newer builds in > > the > > same version, > > so revision can be changed, but major version should be > > coordinated > > with the engine. > > maybe the logic can changed just to make sure > > there is a match between supported cluster levels in vdsm and > > engine > > and ignore engine / vdsm software versions > > >>> > > >>> indeed. > > >>> and code seems to be correct for that flow. > > >>> either engine has support for vdsm version. > > >>> or > > >>> vdsm reports it supports this engine version. > > >>> > > >>> so danken - i think the missing part is actually vdsm telling > > >>> engine > > >>> 3.1 version is supported: > > >>> in > > >>> ./vdsm/dsaversion.py.in:'supportedRHEVMs': ['3.0'], > > >>> > > >>> (and yes, need to change this to supportedEngine naming, but i > > >>> suggest doing this in a separate patch for engine to do this with > > >>> backward compatibility) > > >> > > >> I do not mind adding 3.1 to supportedRHEVMs on vdsm side, but I > > >> think > > >> that if vdsm reports that it supports clusterLevel 3.1, Engine > > >> should > > >> believe vdsm. supportedRHEVMs was intended as a hack to allow new > > >> vdsms > > >> tell old Engines that they are fine. That should not be the main > > >> path of > > >> fixing the issue. > > > > > > I think there was some concept of distinguishing between supported > > > compatibility levels vs. supported versions of engine with that > > > compatibility level if engine did not specify it supports that vdsm > > > version (i.e., tested and supported vs. we just think this should > > > work) > > Itamar - this is true. > > The misleading error occurs as at engine code we use the same message > > for both cases. > > We can separate to having two error messages: > > a. Incompatible cluster level > > b. VDSM version not supported. > > > > However, if we use this, it means that after every release of VDSM, > > we > > should update the SupportedVDSMVersions (i.e - add 4.9.6 to it) > > Is this what we want to do? > > The other option -as previously mentioned is to rely only on cluster > > compatibility level comparison (using the 'supprtedRHEVMs' reported > > by > > VDSM) > > Thoughts about this are more than welcome > > > > Yair > > i agree with this approach, > just one fix, we should use vdsm's 'supportedProtocols' > which match the engine's cluster levels. > this way the versions of the software are not important, > only what 'protocols' (or cluster levels) are supported in both. Is supportedProtocols ever used by Engine now? I think it is stale. I resent introducing it, as the logic is too complex as it is. I think it is enough to have a set of SupportedVDSMVersions, with the extra ability to ship a vdsm with another version, reporting its supportedeRHEVMs. It is unlikely that vdsm is ever shipped without a change to the protocol (we are not in the business of reimplementation of old APIs). So supportedProtocols is not going to change any slower than vdsm version. Please add vdsm-4.9.6 to the set of SupportedVDSMVersions. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Host can't join the cluster
On 05/21/2012 04:55 PM, Omer Frenkel wrote: > > > - Original Message - >> From: "Yair Zaslavsky" >> To: "Itamar Heim" >> Cc: users@ovirt.org >> Sent: Monday, May 21, 2012 4:46:20 PM >> Subject: Re: [Users] Host can't join the cluster >> >> On 05/19/2012 05:54 PM, Itamar Heim wrote: >>> On 05/18/2012 04:20 PM, Dan Kenigsberg wrote: On Thu, May 17, 2012 at 10:03:31PM +0300, Itamar Heim wrote: > On 05/17/2012 02:11 PM, Omer Frenkel wrote: > ... > >>> >>> second, iirc, the definition was vdsm can override engine vdsm >>> version >>> check, so a newer vdsm could still report it will work with an >>> older >>> engine, without needing to change the older engine to match it? >>> >> >> i agree as well, i think the intention was for newer builds in >> the >> same version, >> so revision can be changed, but major version should be >> coordinated >> with the engine. >> maybe the logic can changed just to make sure >> there is a match between supported cluster levels in vdsm and >> engine >> and ignore engine / vdsm software versions > > indeed. > and code seems to be correct for that flow. > either engine has support for vdsm version. > or > vdsm reports it supports this engine version. > > so danken - i think the missing part is actually vdsm telling > engine > 3.1 version is supported: > in > ./vdsm/dsaversion.py.in:'supportedRHEVMs': ['3.0'], > > (and yes, need to change this to supportedEngine naming, but i > suggest doing this in a separate patch for engine to do this with > backward compatibility) I do not mind adding 3.1 to supportedRHEVMs on vdsm side, but I think that if vdsm reports that it supports clusterLevel 3.1, Engine should believe vdsm. supportedRHEVMs was intended as a hack to allow new vdsms tell old Engines that they are fine. That should not be the main path of fixing the issue. >>> >>> I think there was some concept of distinguishing between supported >>> compatibility levels vs. supported versions of engine with that >>> compatibility level if engine did not specify it supports that vdsm >>> version (i.e., tested and supported vs. we just think this should >>> work) >> Itamar - this is true. >> The misleading error occurs as at engine code we use the same message >> for both cases. >> We can separate to having two error messages: >> a. Incompatible cluster level >> b. VDSM version not supported. >> >> However, if we use this, it means that after every release of VDSM, >> we >> should update the SupportedVDSMVersions (i.e - add 4.9.6 to it) >> Is this what we want to do? >> The other option -as previously mentioned is to rely only on cluster >> compatibility level comparison (using the 'supprtedRHEVMs' reported >> by >> VDSM) >> Thoughts about this are more than welcome >> >> Yair > > i agree with this approach, > just one fix, we should use vdsm's 'supportedProtocols' > which match the engine's cluster levels. > this way the versions of the software are not important, > only what 'protocols' (or cluster levels) are supported in both. Exactly, my bad. Thanks for the correction! > >> >> >>> ___ >>> Users mailing list >>> Users@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >> >> ___ >> Users mailing list >> Users@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users >> ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Host can't join the cluster
- Original Message - > From: "Yair Zaslavsky" > To: "Itamar Heim" > Cc: users@ovirt.org > Sent: Monday, May 21, 2012 4:46:20 PM > Subject: Re: [Users] Host can't join the cluster > > On 05/19/2012 05:54 PM, Itamar Heim wrote: > > On 05/18/2012 04:20 PM, Dan Kenigsberg wrote: > >> On Thu, May 17, 2012 at 10:03:31PM +0300, Itamar Heim wrote: > >>> On 05/17/2012 02:11 PM, Omer Frenkel wrote: > >>> ... > >>> > > > > second, iirc, the definition was vdsm can override engine vdsm > > version > > check, so a newer vdsm could still report it will work with an > > older > > engine, without needing to change the older engine to match it? > > > > i agree as well, i think the intention was for newer builds in > the > same version, > so revision can be changed, but major version should be > coordinated > with the engine. > maybe the logic can changed just to make sure > there is a match between supported cluster levels in vdsm and > engine > and ignore engine / vdsm software versions > >>> > >>> indeed. > >>> and code seems to be correct for that flow. > >>> either engine has support for vdsm version. > >>> or > >>> vdsm reports it supports this engine version. > >>> > >>> so danken - i think the missing part is actually vdsm telling > >>> engine > >>> 3.1 version is supported: > >>> in > >>> ./vdsm/dsaversion.py.in:'supportedRHEVMs': ['3.0'], > >>> > >>> (and yes, need to change this to supportedEngine naming, but i > >>> suggest doing this in a separate patch for engine to do this with > >>> backward compatibility) > >> > >> I do not mind adding 3.1 to supportedRHEVMs on vdsm side, but I > >> think > >> that if vdsm reports that it supports clusterLevel 3.1, Engine > >> should > >> believe vdsm. supportedRHEVMs was intended as a hack to allow new > >> vdsms > >> tell old Engines that they are fine. That should not be the main > >> path of > >> fixing the issue. > > > > I think there was some concept of distinguishing between supported > > compatibility levels vs. supported versions of engine with that > > compatibility level if engine did not specify it supports that vdsm > > version (i.e., tested and supported vs. we just think this should > > work) > Itamar - this is true. > The misleading error occurs as at engine code we use the same message > for both cases. > We can separate to having two error messages: > a. Incompatible cluster level > b. VDSM version not supported. > > However, if we use this, it means that after every release of VDSM, > we > should update the SupportedVDSMVersions (i.e - add 4.9.6 to it) > Is this what we want to do? > The other option -as previously mentioned is to rely only on cluster > compatibility level comparison (using the 'supprtedRHEVMs' reported > by > VDSM) > Thoughts about this are more than welcome > > Yair i agree with this approach, just one fix, we should use vdsm's 'supportedProtocols' which match the engine's cluster levels. this way the versions of the software are not important, only what 'protocols' (or cluster levels) are supported in both. > > > > ___ > > Users mailing list > > Users@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/users > > ___ > Users mailing list > Users@ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Host can't join the cluster
On 05/19/2012 05:54 PM, Itamar Heim wrote: > On 05/18/2012 04:20 PM, Dan Kenigsberg wrote: >> On Thu, May 17, 2012 at 10:03:31PM +0300, Itamar Heim wrote: >>> On 05/17/2012 02:11 PM, Omer Frenkel wrote: >>> ... >>> > > second, iirc, the definition was vdsm can override engine vdsm > version > check, so a newer vdsm could still report it will work with an older > engine, without needing to change the older engine to match it? > i agree as well, i think the intention was for newer builds in the same version, so revision can be changed, but major version should be coordinated with the engine. maybe the logic can changed just to make sure there is a match between supported cluster levels in vdsm and engine and ignore engine / vdsm software versions >>> >>> indeed. >>> and code seems to be correct for that flow. >>> either engine has support for vdsm version. >>> or >>> vdsm reports it supports this engine version. >>> >>> so danken - i think the missing part is actually vdsm telling engine >>> 3.1 version is supported: >>> in >>> ./vdsm/dsaversion.py.in:'supportedRHEVMs': ['3.0'], >>> >>> (and yes, need to change this to supportedEngine naming, but i >>> suggest doing this in a separate patch for engine to do this with >>> backward compatibility) >> >> I do not mind adding 3.1 to supportedRHEVMs on vdsm side, but I think >> that if vdsm reports that it supports clusterLevel 3.1, Engine should >> believe vdsm. supportedRHEVMs was intended as a hack to allow new vdsms >> tell old Engines that they are fine. That should not be the main path of >> fixing the issue. > > I think there was some concept of distinguishing between supported > compatibility levels vs. supported versions of engine with that > compatibility level if engine did not specify it supports that vdsm > version (i.e., tested and supported vs. we just think this should work) Itamar - this is true. The misleading error occurs as at engine code we use the same message for both cases. We can separate to having two error messages: a. Incompatible cluster level b. VDSM version not supported. However, if we use this, it means that after every release of VDSM, we should update the SupportedVDSMVersions (i.e - add 4.9.6 to it) Is this what we want to do? The other option -as previously mentioned is to rely only on cluster compatibility level comparison (using the 'supprtedRHEVMs' reported by VDSM) Thoughts about this are more than welcome Yair > ___ > Users mailing list > Users@ovirt.org > http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] HA and Live Migration FS Recommendations
On 05/21/2012 03:02 PM, Neil wrote: I'm very new to oVirt and I have some questions that I can't seem to find answers for, so please go easy on me. We are looking at implementing a HA KVM virtualization environment over two(3 in total at a later stage) physical nodes using oVirt for about 8 guests using Centos 6.2. What I am looking at doing is using a fibre channel SAN to implement shared storage by allowing both physical nodes to see the same LUN on the SAN so that both physical nodes will have access to a shared filesystem for storing guest images on. I've opted for the shared LUN/storage approach to allow for HA and live migration of guests between the physical nodes. Do I need to configure GFS2 before oVirt so that both physical nodes can have access to the same LUN for the guest images; or will oVirt automatically handle locking/fencing etc. on the common filesystem? I've tried using luci/ricci to setup a "storage" cluster using GFS2 with oVirt mounting the GFS2 filesystem as a local directory, but this seems far from ideal. You don't need GFS2 or any other filesystem. Just create a Fibre Channel storage domain with your LUNs and oVirt will use them directly without any filesystem involved. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] HA and Live Migration FS Recommendations
On 05/21/2012 03:02 PM, Neil wrote: I'm very new to oVirt and I have some questions that I can't seem to find answers for, so please go easy on me. We are looking at implementing a HA KVM virtualization environment over two(3 in total at a later stage) physical nodes using oVirt for about 8 guests using Centos 6.2. What I am looking at doing is using a fibre channel SAN to implement shared storage by allowing both physical nodes to see the same LUN on the SAN so that both physical nodes will have access to a shared filesystem for storing guest images on. I've opted for the shared LUN/storage approach to allow for HA and live migration of guests between the physical nodes. Do I need to configure GFS2 before oVirt so that both physical nodes can have access to the same LUN for the guest images; or will oVirt automatically handle locking/fencing etc. on the common filesystem? I've tried using luci/ricci to setup a "storage" cluster using GFS2 with oVirt mounting the GFS2 filesystem as a local directory, but this seems far from ideal. You don't need GFS2 or any other filesystem. Just create a Fibre Channel storage domain with your LUNs and oVirt will use them directly without any filesystem involved. -- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[Users] HA and Live Migration FS Recommendations
Hi guys, I'm very new to oVirt and I have some questions that I can't seem to find answers for, so please go easy on me. We are looking at implementing a HA KVM virtualization environment over two(3 in total at a later stage) physical nodes using oVirt for about 8 guests using Centos 6.2. What I am looking at doing is using a fibre channel SAN to implement shared storage by allowing both physical nodes to see the same LUN on the SAN so that both physical nodes will have access to a shared filesystem for storing guest images on. I've opted for the shared LUN/storage approach to allow for HA and live migration of guests between the physical nodes. Do I need to configure GFS2 before oVirt so that both physical nodes can have access to the same LUN for the guest images; or will oVirt automatically handle locking/fencing etc. on the common filesystem? I've tried using luci/ricci to setup a "storage" cluster using GFS2 with oVirt mounting the GFS2 filesystem as a local directory, but this seems far from ideal. Any advice is appreciated. Thank you. Regards. Neil. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
