<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 23, 2014 at 9:04 AM, Jiri Moskovcak <span dir="ltr"><<a href="mailto:jmoskovc@redhat.com" target="_blank">jmoskovc@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 10/22/2014 03:52 PM, Gianluca Cecchi wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<br>
now with oVirt 3.5 there is also iSCSI with NFS as backed storage for<br>
Hosted Engine.<br>
What is the limitation about the storage domain? The integration in<br>
setup scripts or due to storage type itself in engine mgmt?<br>
</blockquote>
<br></span>
Both ;) The storage is managed via vdsm so whatever vdsm supports HE should support, but it requires some work in setup and the agent code.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
What I mean is: if in some way one initially configures the engine on an<br>
external server (physical or virtual), could then be feasible migrating<br>
it "manually" in the oVirt environment (with backup/restore steps)?<br>
<br>
</blockquote>
<br></span>
- yes</blockquote><div><br></div><div>Sorry,</div><div>do you mean that I can have a Gluster storage domain, with an external engine and then backup/restore the egine inside a vm on this Gluster environment as a self hosted engine?</div><div><br></div><div>Thanks</div><div>Gianluca</div></div></div></div>