new git repo request: ovirt-setup-lib
by Sandro Bonazzola
Please create a new repo "ovirt-setup-lib" which will contain code shared between ovirt-hosted-engine-setup and ovirt-engine setup.
Thanks,
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
8 years, 9 months
Problem with latest vdsm update on Fedora 21
by David Maroshi
Greetings team,
I experience failure trying to update my host. From ovirt-master-snapshot repo.
# yum update vdsm
....
Error: Package: vdsm-4.17.0-1114.git30a0d1c.el7.noarch (ovirt-master-snapshot)
Requires: python >= 2.7.5-18.el7_1.1
^^^^^^^^^^^
Installed: python-2.7.5-16.el7.x86_64 (@anaconda/7.1)
^^^^^^^^^^^^^^
python = 2.7.5-16.el7
Please update the repo for Fedora 21.
Thanks
Joy and happiness
Dudi
--
Dudi Maroshi
Software Engineer
Red Hat Enterprise Virtualization project http://www.redhat.com/en/technologies/virtualization
maroshi(a)redhat.com
--------------------------------
I am perfectly imperfect.
"There is only one absolute truth, and that is: there in no one absolute truth."
8 years, 9 months
Reaming VdcFault to EngineFault
by Eli Mesika
You may get the following error after rebase with master :
http://pastebin.test.redhat.com/295552
The reason is that the CommandEntity has a memeber of type VdcReturnValueBase which contains
the VdcFault. It is serialized by jackson into the db, and when there is
an attempt to deserialize it - you got the error.
This can be addressed by a simple update command followed by engine restart:
psql -U <user> -c "update command_entities set return_value = replace(return_value,'VdcFault','EngineFault'), return_value_class = replace(return_value_class,'VdcFault','EngineFault');" <db>
Please let me know if you have any issues.
Thanks
Eli Mesika
8 years, 9 months
ovirt-node specfile update
by Fabian Deutsch
Hey,
just a quick head's up that I did some bigger changes to the
ovirt-node specfile.
In case that our CI goes red or the (node) world goes down you
now know what is happening.
Greetings
fabian
8 years, 9 months
Pools are create without vms
by Jakub Niedermertl
Hi,
when I create new pool in engine, no matter how many wms are specified, it is created with zero vms. Anyone experiencing similar problem?
Engine commit: 9b82e80
Engine log:
2015-07-08 17:57:44,332 INFO [org.ovirt.engine.core.bll.AddVmPoolWithVmsCommand] (org.ovirt.thread.pool-8-thread-29) [4f71760c] Running command: AddVmPoolWithVmsCommand internal: false. Entities affected : ID: 00000002-0002-0002-0002-00000000026d Type: VdsGroupsAction group CREATE_VM_POOL with role type USER, ID: 53d01889-42ca-4956-8f02-4cdea7078248 Type: VmTemplateAction group CREATE_VM with role type USER
2015-07-08 17:57:44,446 ERROR [org.ovirt.engine.core.bll.AddVmPoolWithVmsCommand] (org.ovirt.thread.pool-8-thread-29) [] Command 'org.ovirt.engine.core.bll.AddVmPoolWithVmsCommand' failed: java.lang.NullPointerException
2015-07-08 17:57:44,446 ERROR [org.ovirt.engine.core.bll.AddVmPoolWithVmsCommand] (org.ovirt.thread.pool-8-thread-29) [] Exception: javax.ejb.EJBException: java.lang.NullPointerException
at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInNoTx(CMTTxInterceptor.java:216) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:262) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.ejb3.tx.CMTTxInterceptor.supports(CMTTxInterceptor.java:399) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:243) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:448)
at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185)
at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
at org.ovirt.engine.core.bll.interfaces.BackendInternal$$$view4.runInternalAction(Unknown Source) [bll.jar:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_45]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_45]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_45]
at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_45]
at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:414) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
at org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:65) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
at org.ovirt.engine.core.bll.BackendCommandObjectsHandler$BackendInternal$BackendLocal$2049259618$Proxy$_$$_Weld$EnterpriseProxy$.runInternalAction(Unknown Source) [bll.jar:]
at org.ovirt.engine.core.bll.CommandBase.runInternalAction(CommandBase.java:2342) [bll.jar:]
at org.ovirt.engine.core.bll.CommonVmPoolWithVmsCommand.addVmsToPool(CommonVmPoolWithVmsCommand.java:161) [bll.jar:]
at org.ovirt.engine.core.bll.CommonVmPoolWithVmsCommand.executeCommand(CommonVmPoolWithVmsCommand.java:144) [bll.jar:]
at org.ovirt.engine.core.bll.CommandBase.executeWithoutTransaction(CommandBase.java:1212) [bll.jar:]
at org.ovirt.engine.core.bll.CommandBase.executeActionInTransactionScope(CommandBase.java:1356) [bll.jar:]
at org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:1979) [bll.jar:]
at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInSuppressed(TransactionSupport.java:174) [utils.jar:]
at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInScope(TransactionSupport.java:116) [utils.jar:]
at org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1392) [bll.jar:]
at org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:375) [bll.jar:]
at org.ovirt.engine.core.bll.MultipleActionsRunner.executeValidatedCommand(MultipleActionsRunner.java:202) [bll.jar:]
at org.ovirt.engine.core.bll.MultipleActionsRunner.runCommands(MultipleActionsRunner.java:170) [bll.jar:]
at org.ovirt.engine.core.bll.MultipleActionsRunner$2.run(MultipleActionsRunner.java:179) [bll.jar:]
at org.ovirt.engine.core.utils.threadpool.ThreadPoolUtil$InternalWrapperRunnable.run(ThreadPoolUtil.java:92) [utils.jar:]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_45]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_45]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_45]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_45]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45]
Caused by: java.lang.NullPointerException
at org.ovirt.engine.core.bll.CommandBase.parentHasCallback(CommandBase.java:1369) [bll.jar:]
at org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1382) [bll.jar:]
at org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:375) [bll.jar:]
at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:459) [bll.jar:]
at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:441) [bll.jar:]
at org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:651) [bll.jar:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_45]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_45]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_45]
at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_45]
at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:70) [wildfly-weld-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:80) [wildfly-weld-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) [wildfly-weld-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) [wildfly-weld-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:52) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:260) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
... 60 more
2015-07-08 17:57:44,452 INFO [org.ovirt.engine.core.bll.AddVmPoolWithVmsCommand] (org.ovirt.thread.pool-8-thread-29) [] Command [id=6e59f612-ebe5-4a14-9311-dfa786c32396]: Compensating CHANGED_STATUS_ONLY of org.ovirt.engine.core.common.businessentities.VmTemplate; snapshot: EntityStatusSnapshot:{id='53d01889-42ca-4956-8f02-4cdea7078248', status='OK'}.
2015-07-08 17:57:44,458 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (org.ovirt.thread.pool-8-thread-29) [] Correlation ID: 4f71760c, Job ID: 2a5c64aa-2c78-4beb-a2a0-17651f8fe916, Call Stack: null, Custom Event ID: -1, Message: VM Pool qq (containing 3 VMs) was created by admin@internal.
Best regards,
Jakub
8 years, 9 months
ovirt-engine related fedora 21 builds in jenkins
by Sandro Bonazzola
Hi,
while dropping fc20 builds from master as announced 2 weeks ago[1] I've seen that several packages implying ovirt-engine availability on fc21 were
still built on jenkins also if we dropped fc21 support for 3.6 in favor of fc22.
Since there's no commitment from integration team and from infrastructure / CI team to support FC21 I would have liked to drop them.
I've been stopped doing that since it seems there are developers using fc21 as development environment.
I'd like to understand why.
I would have understood having developers stuck on fedora 20 for supporting 3.5 and I totally understand developers already on fedora 22.
But being fedora 21 the only unsupported version I don't see any real reason for keep wasting CI resources on such distribution.
Is there any serious motivation for keeping fedora 21 engine related builds in jenkins?
I may understand keeping vdsm related builds since vdsm is supposed to work on fc21 also for 3.5 so i've no objection in keeping vdsm and its deps on
fc21 as long as vdsm team supports it.
Thanks,
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
8 years, 9 months
Renamed classes
by Eli Mesika
Hi
Please note that the following classes were renamed :
*DAODbFacadeImpl.java => *DaoImpl.java
VdsIdParametersBase => IdQueryableParameter
VdcBllErrors => EngineBllError
VdcBllMessages => EngineBllMessage
VdcFault => EngineFault
Thanks
Eli Mesika
8 years, 9 months
VM won't start because of -incoming flag after upgrading to alpha-2
by Christopher Pereira
This is a multi-part message in MIME format.
--------------040500060504070207030504
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Hi,
After upgrading from alpha-1 to alpha-2 and restarting services, a VM
won't start because of the following qemu error:
Domain id=5 is tainted: hook-script
2015-07-07T07:39:27.215579Z qemu-kvm: Unknown migration flags: 0
qemu: warning: error while loading state section id 2
2015-07-07T07:39:27.215681Z qemu-kvm: load of migration failed:
Invalid argument
The reason is that Engine was starting the VM with the -incoming flag
(for "incoming migrations").
1) Why did engine enable the -incoming flag?
VM was configured with "Allow manual migration only".
Maybe this ocurred because I set the host in maintenance mode before
upgrading.
2) How can I clean the -incoming flag in oVirt?
3) Note that the "domain is tainted" error was also freezing the monitor
socket between libvirt and vdsm, requiring a libvirtd + vdsmd restart.
--------------040500060504070207030504
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi,<br>
<br>
After upgrading from alpha-1 to alpha-2 and restarting services, a
VM won't start because of the following qemu error:<br>
<blockquote>Domain id=5 is tainted: hook-script<br>
2015-07-07T07:39:27.215579Z qemu-kvm: Unknown migration flags: 0<br>
qemu: warning: error while loading state section id 2<br>
2015-07-07T07:39:27.215681Z qemu-kvm: load of migration failed:
Invalid argument<br>
</blockquote>
The reason is that Engine was starting the VM with the -incoming
flag (for "incoming migrations").<br>
<br>
1) Why did engine enable the -incoming flag?<br>
VM was configured with "Allow manual migration only".<br>
Maybe this ocurred because I set the host in maintenance mode before
upgrading.<br>
<br>
2) How can I clean the -incoming flag in oVirt?<br>
<br>
3) Note that the "domain is tainted" error was also freezing the
monitor socket between libvirt and vdsm, requiring a libvirtd +
vdsmd restart.<br>
<br>
</body>
</html>
--------------040500060504070207030504--
8 years, 9 months
oVirt Node Weekly Meeting Minutes - 2015-07-06
by Fabian Deutsch
=================================
#ovirt: oVirt Node Weekly Meeting
=================================
Meeting started by fabiand at 14:04:04 UTC. The full logs are available
at http://ovirt.org/meetings/ovirt/2015/ovirt.2015-07-06-14.04.log.html
.
Meeting summary
---------------
* Agenda (fabiand, 14:06:04)
* Jenkins status (fabiand, 14:06:12)
* Other Items (fabiand, 14:06:16)
* Jenkins status (fabiand, 14:06:21)
* we now have all of our jobs (ovirt-node and the plugins) yamlized
(fabiand, 14:08:07)
* ACTION: tlitovsk to let us know the status of the publishers
(fabiand, 14:10:00)
* All master publishers are done (fabiand, 14:11:42)
* ACTION: tlitovsk to modify the builds to let the rpms include the
git hashes (fabiand, 14:13:57)
* ACTION: rbarry to modify the jobs to extract the rpm manifest from
the iso (fabiand, 14:14:16)
Meeting ended at 14:16:47 UTC.
Action Items
------------
* tlitovsk to let us know the status of the publishers
* tlitovsk to modify the builds to let the rpms include the git hashes
* rbarry to modify the jobs to extract the rpm manifest from the iso
Action Items, by person
-----------------------
* rbarry
* rbarry to modify the jobs to extract the rpm manifest from the iso
* tlitovsk
* tlitovsk to let us know the status of the publishers
* tlitovsk to modify the builds to let the rpms include the git hashes
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* fabiand (47)
* tlitovsk (7)
* rbarry (5)
* dougsland (2)
* ovirtbot (2)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
8 years, 9 months
Shared gluster storage domain for templates
by Christopher Pereira
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.
8 years, 9 months
