It is highly 'super duper' not recommended to do that.
Also, consider using thinLVM (requirement for gluster snapshots) for a brick of
the separate gluster volume.
I'm using the 3rd partirion of my OS SSD to host my gluster's volume and I have
no issues so far.
Best Regards,
Strahil NikolovOn Nov 28, 2019 01:05, Joseph Goldman <[email protected]>
wrote:
>
> So I can't host OTHER VM's on this gluster volume? If its already a running
> GLuser for other VMs i can't now re-reploy HE in that gluster volume?
>
> On 2019-11-28 3:27 AM, Alan G wrote:
>
> I've had to do this a couple of times and always ended up with a working
> system in the end.
>
> As a fall back option (although I've never had to use it) I have a backup
> engine VM running completely outside of oVIrt (ESXi host in my case). Then if
> the hosted_engine deploy fails for any reason you can restore onto the backup
> vm as a temp solution while you work through the hosted engine deploy issues.
>
> A few things that come to mind: -
>
> * You will need a dedicated gluster volume for hosted_storage and it needs to
> be replica+arbiter.
>>
>> * Make sure you put the cluster in global maint mode before performing the
>> engine backup, I recall having issues with the restore when I didn't do that.
>> * Migrate all other VMs off the host running Engine before doing the backup.
>> This will be the host you will restore onto.
>>
>>
>> ---- On Wed, 27 Nov 2019 09:46:23 +0000 Joseph Goldman
>> <[email protected]> wrote ----
>>
>>> Hi List,
>>>
>>> In one of my installs, I set up the first storage domain (and where
>>> the HostedEngine is) on a bigger NFS NAS - since then I have created a
>>> Gluster volume that spans the 3 hosts and I'm putting a few VM's in
>>> there for higher reliability (as SAN is single point of failure) namely
>>> I'd like to put HostedEngine in there so it stays up no matter what and
>>> can help report if issues occur (network issue to NAS, NAS dies etc etc)
>>>
>>> Looking through other posts and documentation, there's no real way to
>>> move the HostedEngine storage, is this correct? The solution I've seen
>>> is to backup the hosted engine DB, blow it away, and re-deploy it from
>>> the .backup file configuring it to the new storage domain in the deploy
>>> script - is this the only process? How likely is this to fail? Is it
>>> likely that all VM's and settings will be picked straight back up and
>>> continue to operate like normal? I dont have a test setup to play around
>>> with atm so just trying to gauge confidence in such a solution.
>>>
>>> Thanks,
>>> Joe
>>> _______________________________________________
>>> Users mailing list -- [email protected]
>>> To unsubscribe send an email to [email protected]
>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>>> oVirt Code of Conduct:
_______________________________________________
Users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]/message/7CAU5HNDB4VNZYGNKM5BWFX4LZXBSCD2/
