[ovirt-users] Re: VM backup issue on oVirt 4.4.7

2023-01-17 Thread Sandro Bonazzola
Il giorno mar 17 gen 2023 alle ore 23:10 Don Dupuis  ha
scritto:

> Hello,
> I am having an issue backing up vms using the backup_vm.py example script.
> The error I get is below:
>
> [   0.0 ] Starting full backup for VM
> 'c656db00-065c-4fd0-b8b9-74a86dc864fc'
> Traceback (most recent call last):
>   File "/opt/riva-config/backup_vm.py", line 547, in 
> main()
>   File "/opt/riva-config/backup_vm.py", line 146, in main
> args.command(args)
>   File "/opt/riva-config/backup_vm.py", line 160, in cmd_full
> backup = start_backup(connection, args)
>   File "/opt/riva-config/backup_vm.py", line 348, in start_backup
> description=args.description
>   File "/usr/lib64/python3.6/site-packages/ovirtsdk4/services.py", line
> 34151, in add
> return self._internal_add(backup, headers, query, wait)
>   File "/usr/lib64/python3.6/site-packages/ovirtsdk4/service.py", line
> 232, in _internal_add
> return future.wait() if wait else future
>   File "/usr/lib64/python3.6/site-packages/ovirtsdk4/service.py", line 55,
> in wait
> return self._code(response)
>   File "/usr/lib64/python3.6/site-packages/ovirtsdk4/service.py", line
> 229, in callback
> self._check_fault(response)
>   File "/usr/lib64/python3.6/site-packages/ovirtsdk4/service.py", line
> 132, in _check_fault
> self._raise_error(response, body)
>   File "/usr/lib64/python3.6/site-packages/ovirtsdk4/service.py", line
> 118, in _raise_error
> raise error
> ovirtsdk4.Error: Fault reason is "Operation Failed". Fault detail is
> "[Cannot backup VM. Host (vsh001) is running on a version lower than 4.4.5.
> Please upgrade the host in order to use incremental backup.]". HTTP
> response code is 409.
>
> The strange this is that I am running oVirt 4.4.7. What component is it
> complaining about that is not  up to version needed? Any help on this would
> be appreciated. oVirt rpm is ovirt-host-4.4.7-1.el8.x86_64. I plan on
> upgrading to version 4.4.10 but want to get this fixed first. I also can't
> got to 4.5.x because I have problems with Windows 10 vms and vGPUs.
>

@Albert Esteve  can you help here?
Don, is the GPU problem on Windows 10 VMs tracked somewhere? Is there a
ticket open?



>
> Thanks
> Don
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/ZAGKUOIQLT6CKRQ7F4OWRFUXHSAXTR62/
>


-- 

Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING - Red Hat In-Vehicle Operating System

Red Hat EMEA 

sbona...@redhat.com


*Red Hat respects your work life balance. Therefore there is no need to
answer this email out of your office hours.*
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/OH2FHTMHH63QBGNZCLXCUQBLOMAFTYIQ/


[ovirt-users] Re: Bug in the engine-backup script when no attached TTY -- Easy fix

2023-01-17 Thread Yedidyah Bar David
On Wed, Jan 18, 2023 at 9:09 AM  wrote:
>
> That is very useful.  You are right; I was assuming a non-attached TTY; 
> however, it could very well be a closed/re-directed stdout.  The NetBackup 
> client does fun things with stdout/stderr for logging and data transfer.  I 
> will run some tests tomorrow to check.
>
> The scenario is quite simple.  The NetBackup client runs a pre-script on 
> backup.  I use this pre-script with dump-able databases (oVirt, MythTV, 
> Unifi, etc..) like this to create the backup file, then the backup program 
> scoops up the generated file(s), and finally the post script cleans up.  The 
> pre-script is just calling:
>
> /usr/bin/engine-backup --mode=backup --file=$outf --log=$outl --scope=all
>
> You are right about output being run earlier, so yes it should have caused 
> problems earlier?  I only tested at the very end.  From the code:
>
> do${MODE}
> ec="$?"
> log "EC: ${ec}"
>
> output "Done."
>
> ec="$?"
> log "EC: ${ec}"
>
> The exit code was 0 in the first one, but flipped to 1 after the output line. 
>  What I didn't test was what it looks like right after the earlier output 
> lines.  It could be the case that it gets set to 1, but then gets reset to 0 
> by the actual backup, before anything tests for it again (or it's time to 
> exit).
>
> And I had tried a "2>&1 >/dev/null" wrap before, and tried to run it from 
> cron -- none of which I could get to work either.  I will play around some 
> more.

Good luck!

No idea if this is relevant, but see this excerpt from the bash(1) man page:

   Note that the order of redirections is significant.  For  example,  the
   command

  ls > dirlist 2>&1

   directs  both  standard  output and standard error to the file dirlist,
   while the command

  ls 2>&1 > dirlist

   directs only the standard output to file dirlist, because the  standard
   error  was duplicated from the standard output before the standard out‐
   put was redirected to dirlist.

Best regards,
-- 
Didi
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/LBHVNOWY3VE3VP6TGBCETRBPC3RTC2J7/


[ovirt-users] Re: Bug in the engine-backup script when no attached TTY -- Easy fix

2023-01-17 Thread eshwayri
That is very useful.  You are right; I was assuming a non-attached TTY; 
however, it could very well be a closed/re-directed stdout.  The NetBackup 
client does fun things with stdout/stderr for logging and data transfer.  I 
will run some tests tomorrow to check.  

The scenario is quite simple.  The NetBackup client runs a pre-script on 
backup.  I use this pre-script with dump-able databases (oVirt, MythTV, Unifi, 
etc..) like this to create the backup file, then the backup program scoops up 
the generated file(s), and finally the post script cleans up.  The pre-script 
is just calling:

/usr/bin/engine-backup --mode=backup --file=$outf --log=$outl --scope=all

You are right about output being run earlier, so yes it should have caused 
problems earlier?  I only tested at the very end.  From the code:

do${MODE}
ec="$?"
log "EC: ${ec}"

output "Done."

ec="$?"
log "EC: ${ec}"

The exit code was 0 in the first one, but flipped to 1 after the output line.  
What I didn't test was what it looks like right after the earlier output lines. 
 It could be the case that it gets set to 1, but then gets reset to 0 by the 
actual backup, before anything tests for it again (or it's time to exit).

And I had tried a "2>&1 >/dev/null" wrap before, and tried to run it from cron 
-- none of which I could get to work either.  I will play around some more.

-Edmond
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/YBBIWTAWDALPVYS2TBVEGWHFWPVGM7FB/


[ovirt-users] Re: Bug in the engine-backup script when no attached TTY -- Easy fix

2023-01-17 Thread Yedidyah Bar David
On Tue, Jan 17, 2023 at 11:37 PM  wrote:
>
> The output() function.  This line:
>
> printf "%s\n" "${m}"
>
> It will fail if there is no attached TTY,

Are you sure it requires an attached _TTY_? Not merely stdout?

It indeed requires a TTY in certain cases (see readdbpassword) but not
in the common ones.

> which will set the exit code to 1, which in turn will trigger the cleanup() 
> function notifying the engine that the backup failed.
>  This ironically happens when it should be writing "Done."

Doesn't it use 'output' much earlier, thus failing much earlier? E.g. here:

output "Start of engine-backup with mode '${MODE}'"

> and exiting after a successful backup.  Fix I used was to change it to:
>
> printf "%s\n" "${m}" >> "${LOG}"

This is redundant - 'output' already writes to the log.

>
> You can't assume attached TTY

Well, if we want to be able to input passwords safely, we need a tty.

For common cases, we indeed do not, and do not assume it.

We do indeed assume stdout. Almost all 'normal' programs do. E.g.:

$ date >&-
date: write error: Bad file descriptor
$ echo $?
1

When needing to run such programs without stdout, you usually wrap them, e.g.:

$ (date > /dev/null) >&-
$ echo $?
0

> since a lot of people like me want to run this as part of a pre/post script 
> to an automated backup program.

Please clarify your case. If it's a shell script that's calling
engine-backup, can't this script redirect the output? E.g. to
/dev/null, if you never look at it?

If you provide this script directly to some backup program that does
not provide an stdout (meaning, executes it with FD 1 closed), you
indeed have to handle this somehow. I'd personally do this by creating
a trivial one-line wrapper script and point the backup program to the
wrapper.

That said, I'd consider such behavior a bug in the calling backup
program. I'd expect such a program to provide an stdout to the
pre-/post- programs it calls, keep the output sent there, and log it
to its own logs. When things fail, it will be so much easier for the
user to investigate stuff if you can see the engine-backup output in
the caller's log.

(But admit that when I was a sysadmin and used such programs, I always
wrote my own wrappers around them, and not vice-versa. I realize this
isn't always the best choice or even possible).

Hope this helps. If you still think there is a real bug, please
provide more details.

Thanks and best regards,
-- 
Didi
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/DO6O4C5RJGW2O3DKQ5AY2WYGYZTS53XE/


[ovirt-users] VM backup issue on oVirt 4.4.7

2023-01-17 Thread Don Dupuis
Hello,
I am having an issue backing up vms using the backup_vm.py example script.
The error I get is below:

[   0.0 ] Starting full backup for VM 'c656db00-065c-4fd0-b8b9-74a86dc864fc'
Traceback (most recent call last):
  File "/opt/riva-config/backup_vm.py", line 547, in 
main()
  File "/opt/riva-config/backup_vm.py", line 146, in main
args.command(args)
  File "/opt/riva-config/backup_vm.py", line 160, in cmd_full
backup = start_backup(connection, args)
  File "/opt/riva-config/backup_vm.py", line 348, in start_backup
description=args.description
  File "/usr/lib64/python3.6/site-packages/ovirtsdk4/services.py", line
34151, in add
return self._internal_add(backup, headers, query, wait)
  File "/usr/lib64/python3.6/site-packages/ovirtsdk4/service.py", line 232,
in _internal_add
return future.wait() if wait else future
  File "/usr/lib64/python3.6/site-packages/ovirtsdk4/service.py", line 55,
in wait
return self._code(response)
  File "/usr/lib64/python3.6/site-packages/ovirtsdk4/service.py", line 229,
in callback
self._check_fault(response)
  File "/usr/lib64/python3.6/site-packages/ovirtsdk4/service.py", line 132,
in _check_fault
self._raise_error(response, body)
  File "/usr/lib64/python3.6/site-packages/ovirtsdk4/service.py", line 118,
in _raise_error
raise error
ovirtsdk4.Error: Fault reason is "Operation Failed". Fault detail is
"[Cannot backup VM. Host (vsh001) is running on a version lower than 4.4.5.
Please upgrade the host in order to use incremental backup.]". HTTP
response code is 409.

The strange this is that I am running oVirt 4.4.7. What component is it
complaining about that is not  up to version needed? Any help on this would
be appreciated. oVirt rpm is ovirt-host-4.4.7-1.el8.x86_64. I plan on
upgrading to version 4.4.10 but want to get this fixed first. I also can't
got to 4.5.x because I have problems with Windows 10 vms and vGPUs.

Thanks
Don
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/ZAGKUOIQLT6CKRQ7F4OWRFUXHSAXTR62/


[ovirt-users] Bug in the engine-backup script when no attached TTY -- Easy fix

2023-01-17 Thread eshwayri
The output() function.  This line:

printf "%s\n" "${m}"

It will fail if there is no attached TTY, which will set the exit code to 1, 
which in turn will trigger the cleanup() function notifying the engine that the 
backup failed.  This ironically happens when it should be writing "Done." and 
exiting after a successful backup.  Fix I used was to change it to:

printf "%s\n" "${m}" >> "${LOG}"

You can't assume attached TTY since a lot of people like me want to run this as 
part of a pre/post script to an automated backup program.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/RKWW2O3XFCG6F3BZUOO264QXDFY4J4YJ/


[ovirt-users] Re: 4.5.4 Hosted-Engine: change hosted-engine storage

2023-01-17 Thread Diego Ercolani
Thank you, I'm currently trying to accomplish what you reported. But I'm 
currently stuck:
I launched this:
hosted-engine --deploy --4 
--restore-from-file=/root/deploy_hosted_engine_230117/230117-scopeall-backup.tar.gz
 
--config-append=/root/deploy_hosted_engine_230117/hosted_engine_deploy.answer.conf
 --ansible-extra-vars=Debug=99 --ansible-extra-vars=pauseonRestore=true 
--ansible-extra-vars=he_pause_before_engine_setup=true 
--otopi-environment="OVESETUP_CONFIG/keycloakEnable=bool:False"

I can install correctly the ovirt-engine locally, it launch the engine-setup 
with the restore of the database but it fails invalidating: 
OVESETUP_OVN/ovirtProviderOvnSecret as is possible to see in the engine under 
/ver/log/ovirt-engine/setup/
[...]
2023-01-17 15:58:05,667+ DEBUG otopi.context context._executeMethod:127 
Stage misc METHOD 
otopi.plugins.ovirt_engine_setup.ovirt_engine.network.ovirtproviderovn.Plugin._misc_configure_provider
2023-01-17 15:58:05,667+ DEBUG otopi.context context._executeMethod:145 
method exception
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/otopi/context.py", line 132, in 
_executeMethod
method['method']()
  File 
"/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/network/ovirtproviderovn.py",
 line 1124, in _misc_configure_provider
self._configure_ovirt_provider_ovn()
  File 
"/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/network/ovirtproviderovn.py",
 line 807, in _configure_ovirt_provider_ovn
content = self._create_config_content()
  File 
"/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/network/ovirtproviderovn.py",
 line 772, in _create_config_content
OvnEnv.OVIRT_PROVIDER_OVN_SECRET
KeyError: 'OVESETUP_OVN/ovirtProviderOvnSecret'
2023-01-17 15:58:05,669+ ERROR otopi.context context._executeMethod:154 
Failed to execute stage 'Misc configuration': 
'OVESETUP_OVN/ovirtProviderOvnSecret'
2023-01-17 15:58:05,669+ DEBUG otopi.transaction transaction.abort:124 
aborting 'DNF Transaction'
[...]
And also I have a problem because it seem the keycloak is enabled even if I 
disable and also ovn I tried to disable it and in the engine under 
/etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf I have:
[...]
20-setup-ovirt-post.conf:OVESETUP_OVN/ovirtProviderOvn=bool:True
20-setup-ovirt-post.conf:OVESETUP_OVN/ovirtProviderOvnId=str:e6b92384-b112-40e0-8d6f-2c6e4536cd1a
[...]
but it doesn't appear any ovirtProviderOvnSecret

by the way I don't use keycloak (I don't have any keycloak table in the engine 
dump) and even OVN.

I will try to set OVESETUP_OVN/ovirtProviderOvn=bool:True to False before 
ansible launch engine-setup

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/AW5PWNJRLCC4MUAFQZTPJZ5YIE6GTDEB/


[ovirt-users] Re: 4.5.4 Hosted-Engine: change hosted-engine storage

2023-01-17 Thread Volenbovskyi, Konstantin
Hi,
Check out https://access.redhat.com/solutions/6529691.
I would say that you have done a few hacks that are in 'vicinity' of correct 
approach, but the correct approach is a bit simpler than you what you tried to 
come up with.
The idea of procedure is that you should 'forget' about the original eg. image 
files and to a significant extent
The procedure is "launch a brand new hosted-engine, but actually use a database 
backup "
Your answerfile should correspond to what you need (or you just not provide it 
and answer questions interactively) - obviously you should not use glusterfs as 
domainType but instead
OVEHOSTED_STORAGE/domainType=str:nfs
and also the essential thing
OVEHOSTED_STORAGE/storageDomainConnection=str::/

Maybe the owner/group of NFS directory was not changed to vdsm/kvm, the 
solution above contains reference to that.

BR,
Konstantin




On 17.01.23, 09:48, "Diego Ercolani" mailto:diego.ercol...@ssis.sm>> wrote:


ovirt-engine-appliance-4.5-20221206133948
Hello,
I have some trouble with my Gluster instance where there is hosted-engine. I 
would like to copy data from that hosted engine and reverse to another 
hosted-engine storage (I will try NFS).
I think the main method is to put ovirt in global-management mode, stop the 
hosted-engine instance, unmount the hosted-engine storage
systemctl stop {vdsmd;supervdsmd;ovirt-ha-broker;ovirt-ha-agent};
hosted-engine --disconnect-storage
umount /rhev/data-center/mnt/glusterSD/localhost:_glen/
and then redeploy the hosted engine with the current backup:
method 1: [doesn't work; it fail the ansible script after the pause]
ovirt-hosted-engine-setup --4 
--config-append=/var/lib/ovirt-hosted-engine-setup/answers/answers-20230116184834.conf
 --restore-from-file=230116-backup.tar.gz 
--ansible-extra-vars=he_pause_before_engine_setup=true
but it doesn't work


method 2: [I cannot find the glitch]
I saw in every node there is a configuration under 
/etc/ovirt-hosted-engine/hosted-engine.conf where there are some interessant 
entry:
vm_disk_id=0a1a501c-fc45-430f-bfd3-076172cec406
vm_disk_vol_id=f65dab86-67f1-46fa-87c0-f9076f479741
storage=localhost:/glen
domainType=glusterfs
metadata_volume_UUID=4e64e155-ee11-4fdc-b9a0-a7cbee5e4181
metadata_image_UUID=20234090-ea40-4614-ae95-8f91b339ba3e
lockspace_volume_UUID=6a975f46-4126-4c2a-b444-6e5a34872cf6
lockspace_image_UUID=893a1fc1-9a1d-44fc-a02f-8fdac19afc18
conf_volume_UUID=206e505f-1bb8-4cc4-abd9-942654c47612
conf_image_UUID=9871a483-8e7b-4f52-bf71-a6a8adc2309b


so, the conf_volume under conf_image dir is a TAR archive:
/rhev/data-center/mnt/glusterSD/localhost:_glen/3577c21e-f757-4405-97d1-0f827c9b4e22/images/9871a483-8e7b-4f52-bf71-a6a8adc2309b/206e505f-1bb8-4cc4-abd9-942654c47612:
 POSIX tar archive (GNU)


That I think is the common configuration. I copied the structure (from 
3577c21e-f757-4405-97d1-0f827c9b4e22 directory) in the new storage (nfs), 
changed the entries under local configuration and "shared configuration":
from storage=localhost:/glen to storage=:/directory (writable by vdsm 
user and kvm group)
from domainType=glusterfs to domainType=nfs
and issued:
1. hosted-engine --connect-storage <- work
2. hosted-engine --vm-start <- doesn't work because there is a complain about 
the not-starting ovirt-ha-agent


What can I do?
Is there any documentation somewhere?


Diego
___
Users mailing list -- users@ovirt.org 
To unsubscribe send an email to users-le...@ovirt.org 

Privacy Statement: https://www.ovirt.org/privacy-policy.html 

oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/ 

List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org 
/message/QOJYO43SVOMCX6NHDP2N6PF3EIXDTRLP/



___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/BVP7V6PGPBXPJM4ZXUKB7YJYZSTILKRA/


[ovirt-users] 4.5.4 Hosted-Engine: change hosted-engine storage

2023-01-17 Thread Diego Ercolani
ovirt-engine-appliance-4.5-20221206133948
Hello,
I have some trouble with my Gluster instance where there is hosted-engine. I 
would like to copy data from that hosted engine and reverse to another 
hosted-engine storage (I will try NFS).
I think the main method is to put ovirt in global-management mode, stop the 
hosted-engine instance, unmount the hosted-engine storage 
systemctl stop {vdsmd;supervdsmd;ovirt-ha-broker;ovirt-ha-agent};
hosted-engine --disconnect-storage
umount /rhev/data-center/mnt/glusterSD/localhost:_glen/
and then redeploy the hosted engine with the current backup:
method 1: [doesn't work; it fail the ansible script after the pause]
ovirt-hosted-engine-setup --4 
--config-append=/var/lib/ovirt-hosted-engine-setup/answers/answers-20230116184834.conf
 --restore-from-file=230116-backup.tar.gz 
--ansible-extra-vars=he_pause_before_engine_setup=true
but it doesn't work

method 2: [I cannot find the glitch]
I saw in every node there is a configuration under 
/etc/ovirt-hosted-engine/hosted-engine.conf where there are some interessant 
entry:
vm_disk_id=0a1a501c-fc45-430f-bfd3-076172cec406
vm_disk_vol_id=f65dab86-67f1-46fa-87c0-f9076f479741
storage=localhost:/glen
domainType=glusterfs
metadata_volume_UUID=4e64e155-ee11-4fdc-b9a0-a7cbee5e4181
metadata_image_UUID=20234090-ea40-4614-ae95-8f91b339ba3e
lockspace_volume_UUID=6a975f46-4126-4c2a-b444-6e5a34872cf6
lockspace_image_UUID=893a1fc1-9a1d-44fc-a02f-8fdac19afc18
conf_volume_UUID=206e505f-1bb8-4cc4-abd9-942654c47612
conf_image_UUID=9871a483-8e7b-4f52-bf71-a6a8adc2309b

so, the conf_volume under conf_image dir is a TAR archive:
/rhev/data-center/mnt/glusterSD/localhost:_glen/3577c21e-f757-4405-97d1-0f827c9b4e22/images/9871a483-8e7b-4f52-bf71-a6a8adc2309b/206e505f-1bb8-4cc4-abd9-942654c47612:
 POSIX tar archive (GNU)

That I think is the common configuration. I copied the structure (from 
3577c21e-f757-4405-97d1-0f827c9b4e22 directory)  in the new storage (nfs), 
changed the entries under local configuration and "shared configuration":
from storage=localhost:/glen to storage=:/directory (writable by vdsm 
user and kvm group)
from domainType=glusterfs to domainType=nfs
and issued:
1. hosted-engine --connect-storage <- work
2. hosted-engine --vm-start <- doesn't work because there is a complain about 
the not-starting ovirt-ha-agent

What can I do?
Is there any documentation somewhere?

Diego
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/QOJYO43SVOMCX6NHDP2N6PF3EIXDTRLP/