how to setup image-io-proxy after initially disabling it
Hello, I'm on oVirt 4.1.7, the latest in 4.1 right now. Initially in engine-setup when prompted I set Image I/O Proxy to false. Configure Image I/O Proxy : False Now instead I would like to enable it, but if I run engine-setup I can't find a way to do it. I can only confirm the settings in a whole or exit the setup... How can I do? Currently I have these packages already installed on the system ovirt-imageio-proxy-setup-1.0.0-0.201701151456.git89ae3b4.el7.centos.noarch ovirt-imageio-proxy-1.0.0-0.201701151456.git89ae3b4.el7.centos.noarch and [root@ovirt ~]# systemctl status ovirt-imageio-proxy ● ovirt-imageio-proxy.service - oVirt ImageIO Proxy Loaded: loaded (/usr/lib/systemd/system/ovirt-imageio-proxy.service; disabled; vendor preset: disabled) Active: inactive (dead) [root@ovirt ~]# Can I simply and manually enable/start the service through systemctl commands? The same question arises in case I had not / had enabled VMConsole Proxy and/or WebSocket Proxy during install and in a second time I want to enable / diable them. Thanks, Gianluca
On Tue, Dec 5, 2017 at 10:22 PM, Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
Hello, I'm on oVirt 4.1.7, the latest in 4.1 right now. Initially in engine-setup when prompted I set Image I/O Proxy to false.
Configure Image I/O Proxy : False
Now instead I would like to enable it, but if I run engine-setup I can't find a way to do it. I can only confirm the settings in a whole or exit the setup... How can I do?
Currently I have these packages already installed on the system
ovirt-imageio-proxy-setup-1.0.0-0.201701151456.git89ae3b4.el 7.centos.noarch ovirt-imageio-proxy-1.0.0-0.201701151456.git89ae3b4.el7.centos.noarch and [root@ovirt ~]# systemctl status ovirt-imageio-proxy ● ovirt-imageio-proxy.service - oVirt ImageIO Proxy Loaded: loaded (/usr/lib/systemd/system/ovirt-imageio-proxy.service; disabled; vendor preset: disabled) Active: inactive (dead) [root@ovirt ~]#
Can I simply and manually enable/start the service through systemctl commands?
The same question arises in case I had not / had enabled VMConsole Proxy and/or WebSocket Proxy during install and in a second time I want to enable / diable them.
Thanks, Gianluca
After reading the help page for engine-setup and discovering that the option "--reconfigure-optional-components" has no effect in 4.1 for Image I/O Proxy, I used the workaround offered throughout this bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1486753 Now it seems all ok, but the upload fails after going into pause just at the beginning with the message " Unable to upload image to disk de28015a-39e9-44e4-acb2-2d2e3b9cdc7f due to a network error. Make sure ovirt-imageio-proxy service is installed and configured, and ovirt-engine's certificate is registered as a valid CA in the browser. The certificate can be fetched from https:// <engine_url>/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA " I already fetched into firefox the certificate and selected all 3 check boxes when configuring... Any other thing to check? On engine: [root@ovirt ~]# firewall-cmd --list-all public (active) target: default icmp-block-inversion: no interfaces: eth0 sources: services: ovirt-websocket-proxy ovirt-vmconsole-proxy ovirt-http dhcpv6-client ovirt-https ssh ovirt-postgres ovirt-fence-kdump-listener ovirt-imageio-proxy ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: [root@ovirt ~]# [root@ovirt ~]# systemctl status ovirt-imageio-proxy.service -l ● ovirt-imageio-proxy.service - oVirt ImageIO Proxy Loaded: loaded (/usr/lib/systemd/system/ovirt-imageio-proxy.service; enabled; vendor preset: disabled) Active: active (running) since Wed 2017-12-06 00:07:48 CET; 7h ago Main PID: 9402 (ovirt-imageio-p) CGroup: /system.slice/ovirt-imageio-proxy.service └─9402 /usr/bin/python /usr/bin/ovirt-imageio-proxy Dec 06 00:07:47 ovirt systemd[1]: Starting oVirt ImageIO Proxy... Dec 06 00:07:48 ovirt systemd[1]: Started oVirt ImageIO Proxy. [root@ovirt ~]# In /var/log/ovirt-imageio-proxy/image-proxy.log (MainThread) INFO 2017-12-06 00:07:48,460 image_proxy:26:root:(main) Server started, successfully notified systemd In engine.log 2017-12-06 00:10:07,534+01 INFO [org.ovirt.engine.core.bll.storage.disk.image.ImageTransferUpdater] (DefaultQuartzScheduler1) [cefb309e-1127-4811-b69b-a7d83c3f7df6] Updating image upload 208cc8c5-66ae-40aa-9748-04ee90c022a6 (image bad43962-dcc4-4f16-8b8e-dafc26573e2c) phase to Transferring (message: 'Initiating new upload') 2017-12-06 00:10:07,537+01 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferDiskImageCommand] (DefaultQuartzScheduler1) [cefb309e-1127-4811-b69b-a7d83c3f7df6] Returning from proceedCommandExecution after starting transfer session for image transfer command '208cc8c5-66ae-40aa-9748-04ee90c022a6' 2017-12-06 00:10:10,506+01 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferImageStatusCommand] (default task-1) [dae9a850-5db2-40be-92ca-a6fff0d54aac] Running command: TransferImageStatusCommand internal: false. Entities affected : ID: aaa00000-0000-0000-0000-123456789aaa Type: SystemAction group CREATE_DISK with role type USER 2017-12-06 00:10:14,512+01 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferImageStatusCommand] (default task-15) [ca329503-0916-43f4-99a7-e285775d5ffd] Running command: TransferImageStatusCommand internal: false. Entities affected : ID: aaa00000-0000-0000-0000-123456789aaa Type: SystemAction group CREATE_DISK with role type USER 2017-12-06 00:10:18,512+01 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferImageStatusCommand] (default task-3) [66f4e540-670e-4e20-8003-4e740ee8c3b6] Running command: TransferImageStatusCommand internal: false. Entities affected : ID: aaa00000-0000-0000-0000-123456789aaa Type: SystemAction group CREATE_DISK with role type USER 2017-12-06 00:10:20,442+01 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferImageStatusCommand] (default task-16) [403dd7c1-9f2b-4d26-8fae-f179ca1922e1] Running command: TransferImageStatusCommand internal: false. Entities affected : ID: aaa00000-0000-0000-0000-123456789aaa Type: SystemAction group CREATE_DISK with role type USER 2017-12-06 00:10:20,443+01 INFO [org.ovirt.engine.core.bll.storage.disk.image.ImageTransferUpdater] (default task-16) [403dd7c1-9f2b-4d26-8fae-f179ca1922e1] Updating image upload 208cc8c5-66ae-40aa-9748-04ee90c022a6 (image bad43962-dcc4-4f16-8b8e-dafc26573e2c) phase to Paused by System (message: 'Sent 0MB') 2017-12-06 00:10:20,461+01 WARN [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-16) [403dd7c1-9f2b-4d26-8fae-f179ca1922e1] EVENT_ID: UPLOAD_IMAGE_NETWORK_ERROR(1,038), Correlation ID: 403dd7c1-9f2b-4d26-8fae-f179ca1922e1, Call Stack: null, Custom ID: null, Custom Event ID: -1, Message: Unable to upload image to disk bad43962-dcc4-4f16-8b8e-dafc26573e2c due to a network error. Make sure ovirt-imageio-proxy service is installed and configured, and ovirt-engine's certificate is registered as a valid CA in the browser. The certificate can be fetched from https:// <engine_url>/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA Thanks, Gianluca
This is a multi-part message in MIME format. --------------772D44D2DCDB102AD9D92653 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Gianluca, if you execute "engine-config --get ImageProxyAddress" the value of that attribute is your engine's fqdn? I had a similar issue in the past with my setup and in my case the problem was the wrong value of the attribute ImageProxyAddress, I hope this could be useful also for you. Greetings, Paolo Il 06/12/2017 07:22, Gianluca Cecchi ha scritto:
On Tue, Dec 5, 2017 at 10:22 PM, Gianluca Cecchi <gianluca.cecchi@gmail.com <mailto:gianluca.cecchi@gmail.com>> wrote:
Hello, I'm on oVirt 4.1.7, the latest in 4.1 right now. Initially in engine-setup when prompted I set Image I/O Proxy to false.
Configure Image I/O Proxy : False
Now instead I would like to enable it, but if I run engine-setup I can't find a way to do it. I can only confirm the settings in a whole or exit the setup... How can I do?
Currently I have these packages already installed on the system
ovirt-imageio-proxy-setup-1.0.0-0.201701151456.git89ae3b4.el7.centos.noarch ovirt-imageio-proxy-1.0.0-0.201701151456.git89ae3b4.el7.centos.noarch and [root@ovirt ~]# systemctl status ovirt-imageio-proxy ● ovirt-imageio-proxy.service - oVirt ImageIO Proxy Loaded: loaded (/usr/lib/systemd/system/ovirt-imageio-proxy.service; disabled; vendor preset: disabled) Active: inactive (dead) [root@ovirt ~]#
Can I simply and manually enable/start the service through systemctl commands?
The same question arises in case I had not / had enabled VMConsole Proxy and/or WebSocket Proxy during install and in a second time I want to enable / diable them.
Thanks, Gianluca
After reading the help page for engine-setup and discovering that the option "--reconfigure-optional-components" has no effect in 4.1 for Image I/O Proxy, I used the workaround offered throughout this bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1486753 <https://bugzilla.redhat.com/show_bug.cgi?id=1486753>
Now it seems all ok, but the upload fails after going into pause just at the beginning with the message
" Unable to upload image to disk de28015a-39e9-44e4-acb2-2d2e3b9cdc7f due to a network error. Make sure ovirt-imageio-proxy service is installed and configured, and ovirt-engine's certificate is registered as a valid CA in the browser. The certificate can be fetched from https://<engine_url>/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA "
I already fetched into firefox the certificate and selected all 3 check boxes when configuring...
Any other thing to check?
On engine:
[root@ovirt ~]# firewall-cmd --list-all public (active) target: default icmp-block-inversion: no interfaces: eth0 sources: services: ovirt-websocket-proxy ovirt-vmconsole-proxy ovirt-http dhcpv6-client ovirt-https ssh ovirt-postgres ovirt-fence-kdump-listener ovirt-imageio-proxy ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: [root@ovirt ~]#
[root@ovirt ~]# systemctl status ovirt-imageio-proxy.service -l ● ovirt-imageio-proxy.service - oVirt ImageIO Proxy Loaded: loaded (/usr/lib/systemd/system/ovirt-imageio-proxy.service; enabled; vendor preset: disabled) Active: active (running) since Wed 2017-12-06 00:07:48 CET; 7h ago Main PID: 9402 (ovirt-imageio-p) CGroup: /system.slice/ovirt-imageio-proxy.service └─9402 /usr/bin/python /usr/bin/ovirt-imageio-proxy
Dec 06 00:07:47 ovirt systemd[1]: Starting oVirt ImageIO Proxy... Dec 06 00:07:48 ovirt systemd[1]: Started oVirt ImageIO Proxy. [root@ovirt ~]#
In /var/log/ovirt-imageio-proxy/image-proxy.log
(MainThread) INFO 2017-12-06 00:07:48,460 image_proxy:26:root:(main) Server started, successfully notified systemd
In engine.log
2017-12-06 00:10:07,534+01 INFO [org.ovirt.engine.core.bll.storage.disk.image.ImageTransferUpdater] (DefaultQuartzScheduler1) [cefb309e-1127-4811-b69b-a7d83c3f7df6] Updating image upload 208cc8c5-66ae-40aa-9748-04ee90c022a6 (image bad43962-dcc4-4f16-8b8e-dafc26573e2c) phase to Transferring (message: 'Initiating new upload') 2017-12-06 00:10:07,537+01 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferDiskImageCommand] (DefaultQuartzScheduler1) [cefb309e-1127-4811-b69b-a7d83c3f7df6] Returning from proceedCommandExecution after starting transfer session for image transfer command '208cc8c5-66ae-40aa-9748-04ee90c022a6' 2017-12-06 00:10:10,506+01 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferImageStatusCommand] (default task-1) [dae9a850-5db2-40be-92ca-a6fff0d54aac] Running command: TransferImageStatusCommand internal: false. Entities affected : ID: aaa00000-0000-0000-0000-123456789aaa Type: SystemAction group CREATE_DISK with role type USER 2017-12-06 00:10:14,512+01 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferImageStatusCommand] (default task-15) [ca329503-0916-43f4-99a7-e285775d5ffd] Running command: TransferImageStatusCommand internal: false. Entities affected : ID: aaa00000-0000-0000-0000-123456789aaa Type: SystemAction group CREATE_DISK with role type USER 2017-12-06 00:10:18,512+01 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferImageStatusCommand] (default task-3) [66f4e540-670e-4e20-8003-4e740ee8c3b6] Running command: TransferImageStatusCommand internal: false. Entities affected : ID: aaa00000-0000-0000-0000-123456789aaa Type: SystemAction group CREATE_DISK with role type USER 2017-12-06 00:10:20,442+01 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferImageStatusCommand] (default task-16) [403dd7c1-9f2b-4d26-8fae-f179ca1922e1] Running command: TransferImageStatusCommand internal: false. Entities affected : ID: aaa00000-0000-0000-0000-123456789aaa Type: SystemAction group CREATE_DISK with role type USER 2017-12-06 00:10:20,443+01 INFO [org.ovirt.engine.core.bll.storage.disk.image.ImageTransferUpdater] (default task-16) [403dd7c1-9f2b-4d26-8fae-f179ca1922e1] Updating image upload 208cc8c5-66ae-40aa-9748-04ee90c022a6 (image bad43962-dcc4-4f16-8b8e-dafc26573e2c) phase to Paused by System (message: 'Sent 0MB') 2017-12-06 00:10:20,461+01 WARN [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-16) [403dd7c1-9f2b-4d26-8fae-f179ca1922e1] EVENT_ID: UPLOAD_IMAGE_NETWORK_ERROR(1,038), Correlation ID: 403dd7c1-9f2b-4d26-8fae-f179ca1922e1, Call Stack: null, Custom ID: null, Custom Event ID: -1, Message: Unable to upload image to disk bad43962-dcc4-4f16-8b8e-dafc26573e2c due to a network error. Make sure ovirt-imageio-proxy service is installed and configured, and ovirt-engine's certificate is registered as a valid CA in the browser. The certificate can be fetched from https://<engine_url>/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA
Thanks, Gianluca
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
--------------772D44D2DCDB102AD9D92653 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> Hi Gianluca,<br> <br> if you execute "engine-config --get ImageProxyAddress" the value of that attribute is your engine's fqdn?<br> <br> I had a similar issue in the past with my setup and in my case the problem was the wrong value of the attribute ImageProxyAddress, I hope this could be useful also for you.<br> <br> Greetings,<br> <br> Paolo<br> <br> <div class="moz-cite-prefix">Il 06/12/2017 07:22, Gianluca Cecchi ha scritto:<br> </div> <blockquote type="cite" cite="mid:CAG2kNCwUTfCcaGhQvCmi+3XbVnhCkkADkW0+gbSx5ccB9H-kgg@mail.gmail.com"> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote">On Tue, Dec 5, 2017 at 10:22 PM, Gianluca Cecchi <span dir="ltr"><<a href="mailto:gianluca.cecchi@gmail.com" target="_blank" moz-do-not-send="true">gianluca.cecchi@gmail.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr">Hello, <div>I'm on oVirt 4.1.7, the latest in 4.1 right now.</div> <div>Initially in engine-setup when prompted I set Image I/O Proxy to false.</div> <div><br> </div> <div> <div> Configure Image I/O Proxy : False</div> </div> <div><br> </div> <div>Now instead I would like to enable it, but if I run engine-setup I can't find a way to do it. I can only confirm the settings in a whole or exit the setup...</div> <div>How can I do?</div> <div><br> </div> <div>Currently I have these packages already installed on the system</div> <div><br> </div> <div>ovirt-imageio-proxy-setup-1.0.<wbr>0-0.201701151456.git89ae3b4.el<wbr>7.centos.noarch<br> </div> <div>ovirt-imageio-proxy-1.0.0-0.20<wbr>1701151456.git89ae3b4.el7.cent<wbr>os.noarch<br> </div> <div>and</div> <div> <div>[root@ovirt ~]# systemctl status ovirt-imageio-proxy</div> <div>● ovirt-imageio-proxy.service - oVirt ImageIO Proxy</div> <div> Loaded: loaded (/usr/lib/systemd/system/ovirt<wbr>-imageio-proxy.service; disabled; vendor preset: disabled)</div> <div> Active: inactive (dead)</div> <div>[root@ovirt ~]#</div> </div> <div><br> </div> <div>Can I simply and manually enable/start the service through systemctl commands?</div> <div><br> </div> <div>The same question arises in case I had not / had enabled VMConsole Proxy and/or WebSocket Proxy during install and in a second time I want to enable / diable them.</div> <div><br> </div> <div>Thanks,</div> <div>Gianluca</div> <div><br> </div> </div> </blockquote> </div> <br> </div> <div class="gmail_extra">After reading the help page for engine-setup and discovering that the option "--reconfigure-optional-components" has no effect in 4.1 for Image I/O Proxy, I used the workaround offered throughout this bugzilla: <br> </div> <div class="gmail_extra"><a href="https://bugzilla.redhat.com/show_bug.cgi?id=1486753" target="_blank" moz-do-not-send="true">https://bugzilla.redhat.com/<wbr>show_bug.cgi?id=1486753</a></div> <div class="gmail_extra"><br> </div> <div class="gmail_extra">Now it seems all ok, but the upload fails after going into pause just at the beginning with the message<br> </div> <div class="gmail_extra"><br> </div> <div class="gmail_extra">"<br> </div> <div class="gmail_extra">Unable to upload image to disk de28015a-39e9-44e4-acb2-2d2e3b9cdc7f due to a network error. Make sure ovirt-imageio-proxy service is installed and configured, and ovirt-engine's certificate is registered as a valid CA in the browser. The certificate can be fetched from <a class="moz-txt-link-freetext" href="https://">https://</a><engine_url>/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA</div> <div class="gmail_extra">"</div> <div class="gmail_extra"><br> </div> <div class="gmail_extra">I already fetched into firefox the certificate and selected all 3 check boxes when configuring...</div> <div class="gmail_extra"><br> </div> <div class="gmail_extra">Any other thing to check?</div> <div class="gmail_extra"><br> </div> <div class="gmail_extra">On engine:</div> <div class="gmail_extra"><br> </div> <div class="gmail_extra">[root@ovirt ~]# firewall-cmd --list-all<br> public (active)<br> target: default<br> icmp-block-inversion: no<br> interfaces: eth0<br> sources: <br> services: ovirt-websocket-proxy ovirt-vmconsole-proxy ovirt-http dhcpv6-client ovirt-https ssh ovirt-postgres ovirt-fence-kdump-listener ovirt-imageio-proxy<br> ports: <br> protocols: <br> masquerade: no<br> forward-ports: <br> source-ports: <br> icmp-blocks: <br> rich rules: <br> <br> [root@ovirt ~]# </div> <div class="gmail_extra"><br> </div> <div class="gmail_extra">[root@ovirt ~]# systemctl status ovirt-imageio-proxy.service -l<br> ● ovirt-imageio-proxy.service - oVirt ImageIO Proxy<br> Loaded: loaded (/usr/lib/systemd/system/ovirt-imageio-proxy.service; enabled; vendor preset: disabled)<br> Active: active (running) since Wed 2017-12-06 00:07:48 CET; 7h ago<br> Main PID: 9402 (ovirt-imageio-p)<br> CGroup: /system.slice/ovirt-imageio-proxy.service<br> └─9402 /usr/bin/python /usr/bin/ovirt-imageio-proxy<br> <br> Dec 06 00:07:47 ovirt systemd[1]: Starting oVirt ImageIO Proxy...<br> Dec 06 00:07:48 ovirt systemd[1]: Started oVirt ImageIO Proxy.<br> [root@ovirt ~]# <br> </div> <div class="gmail_extra"><br> </div> <div class="gmail_extra">In /var/log/ovirt-imageio-proxy/image-proxy.log</div> <div class="gmail_extra"><br> </div> <div class="gmail_extra">(MainThread) INFO 2017-12-06 00:07:48,460 image_proxy:26:root:(main) Server started, successfully notified systemd</div> <div class="gmail_extra"><br> </div> <div class="gmail_extra">In engine.log</div> <div class="gmail_extra"><br> </div> <div class="gmail_extra">2017-12-06 00:10:07,534+01 INFO [org.ovirt.engine.core.bll.storage.disk.image.ImageTransferUpdater] (DefaultQuartzScheduler1) [cefb309e-1127-4811-b69b-a7d83c3f7df6] Updating image upload 208cc8c5-66ae-40aa-9748-04ee90c022a6 (image bad43962-dcc4-4f16-8b8e-dafc26573e2c) phase to Transferring (message: 'Initiating new upload')<br> 2017-12-06 00:10:07,537+01 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferDiskImageCommand] (DefaultQuartzScheduler1) [cefb309e-1127-4811-b69b-a7d83c3f7df6] Returning from proceedCommandExecution after starting transfer session for image transfer command '208cc8c5-66ae-40aa-9748-04ee90c022a6'<br> 2017-12-06 00:10:10,506+01 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferImageStatusCommand] (default task-1) [dae9a850-5db2-40be-92ca-a6fff0d54aac] Running command: TransferImageStatusCommand internal: false. Entities affected : ID: aaa00000-0000-0000-0000-123456789aaa Type: SystemAction group CREATE_DISK with role type USER<br> 2017-12-06 00:10:14,512+01 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferImageStatusCommand] (default task-15) [ca329503-0916-43f4-99a7-e285775d5ffd] Running command: TransferImageStatusCommand internal: false. Entities affected : ID: aaa00000-0000-0000-0000-123456789aaa Type: SystemAction group CREATE_DISK with role type USER<br> 2017-12-06 00:10:18,512+01 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferImageStatusCommand] (default task-3) [66f4e540-670e-4e20-8003-4e740ee8c3b6] Running command: TransferImageStatusCommand internal: false. Entities affected : ID: aaa00000-0000-0000-0000-123456789aaa Type: SystemAction group CREATE_DISK with role type USER<br> 2017-12-06 00:10:20,442+01 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferImageStatusCommand] (default task-16) [403dd7c1-9f2b-4d26-8fae-f179ca1922e1] Running command: TransferImageStatusCommand internal: false. Entities affected : ID: aaa00000-0000-0000-0000-123456789aaa Type: SystemAction group CREATE_DISK with role type USER<br> 2017-12-06 00:10:20,443+01 INFO [org.ovirt.engine.core.bll.storage.disk.image.ImageTransferUpdater] (default task-16) [403dd7c1-9f2b-4d26-8fae-f179ca1922e1] Updating image upload 208cc8c5-66ae-40aa-9748-04ee90c022a6 (image bad43962-dcc4-4f16-8b8e-dafc26573e2c) phase to Paused by System (message: 'Sent 0MB')<br> 2017-12-06 00:10:20,461+01 WARN [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-16) [403dd7c1-9f2b-4d26-8fae-f179ca1922e1] EVENT_ID: UPLOAD_IMAGE_NETWORK_ERROR(1,038), Correlation ID: 403dd7c1-9f2b-4d26-8fae-f179ca1922e1, Call Stack: null, Custom ID: null, Custom Event ID: -1, Message: Unable to upload image to disk bad43962-dcc4-4f16-8b8e-dafc26573e2c due to a network error. Make sure ovirt-imageio-proxy service is installed and configured, and ovirt-engine's certificate is registered as a valid CA in the browser. The certificate can be fetched from <a class="moz-txt-link-freetext" href="https://">https://</a><engine_url>/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA<br> <br> </div> <div class="gmail_extra"><br> </div> <div class="gmail_extra"><br> </div> <div class="gmail_extra">Thanks,</div> <div class="gmail_extra">Gianluca<br> </div> </div> <br> <fieldset class="mimeAttachmentHeader"></fieldset> <br> <pre wrap="">_______________________________________________ Users mailing list <a class="moz-txt-link-abbreviated" href="mailto:Users@ovirt.org">Users@ovirt.org</a> <a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/users">http://lists.ovirt.org/mailman/listinfo/users</a> </pre> </blockquote> </body> </html> --------------772D44D2DCDB102AD9D92653--
On Wed, Dec 6, 2017 at 9:03 AM, Paolo Margara <paolo.margara@polito.it> wrote:
Hi Gianluca,
if you execute "engine-config --get ImageProxyAddress" the value of that attribute is your engine's fqdn?
I had a similar issue in the past with my setup and in my case the problem was the wrong value of the attribute ImageProxyAddress, I hope this could be useful also for you.
Greetings,
Paolo
Oh, yes... I remember in the past something like this.... I forgot ... Indeed [root@ovirt ovirt-engine]# engine-config --get ImageProxyAddress ImageProxyAddress: localhost:54323 version: general [root@ovirt ovirt-engine]# So after executing: engine-config -s ImageProxyAddress=ovirt:54323 where "ovirt" is the hostname of my engine, engine service restart and ovirt-imageio-proxy service restart I was able to upload an image Thanks! Gianluca
Thanks for sharing the solutions. Maybe we need to mention this in the documentation? On Wed, Dec 6, 2017 at 1:27 PM Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
On Wed, Dec 6, 2017 at 9:03 AM, Paolo Margara <paolo.margara@polito.it> wrote:
Hi Gianluca,
if you execute "engine-config --get ImageProxyAddress" the value of that attribute is your engine's fqdn?
I had a similar issue in the past with my setup and in my case the problem was the wrong value of the attribute ImageProxyAddress, I hope this could be useful also for you.
Greetings,
Paolo
Oh, yes... I remember in the past something like this.... I forgot ...
Indeed [root@ovirt ovirt-engine]# engine-config --get ImageProxyAddress ImageProxyAddress: localhost:54323 version: general [root@ovirt ovirt-engine]#
So after executing:
engine-config -s ImageProxyAddress=ovirt:54323
where "ovirt" is the hostname of my engine, engine service restart and ovirt-imageio-proxy service restart I was able to upload an image Thanks! Gianluca
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
This is a multi-part message in MIME format. --------------D03371A731C3A952DFF82FC7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit I think that it could be useful. Greetings, Paolo Il 06/12/2017 13:22, Nir Soffer ha scritto:
Thanks for sharing the solutions.
Maybe we need to mention this in the documentation?
On Wed, Dec 6, 2017 at 1:27 PM Gianluca Cecchi <gianluca.cecchi@gmail.com <mailto:gianluca.cecchi@gmail.com>> wrote:
On Wed, Dec 6, 2017 at 9:03 AM, Paolo Margara <paolo.margara@polito.it <mailto:paolo.margara@polito.it>> wrote:
Hi Gianluca,
if you execute "engine-config --get ImageProxyAddress" the value of that attribute is your engine's fqdn?
I had a similar issue in the past with my setup and in my case the problem was the wrong value of the attribute ImageProxyAddress, I hope this could be useful also for you.
Greetings,
Paolo
Oh, yes... I remember in the past something like this.... I forgot ...
Indeed [root@ovirt ovirt-engine]# engine-config --get ImageProxyAddress ImageProxyAddress: localhost:54323 version: general [root@ovirt ovirt-engine]#
So after executing:
engine-config -s ImageProxyAddress=ovirt:54323
where "ovirt" is the hostname of my engine, engine service restart and ovirt-imageio-proxy service restart I was able to upload an image Thanks! Gianluca
_______________________________________________ Users mailing list Users@ovirt.org <mailto:Users@ovirt.org> http://lists.ovirt.org/mailman/listinfo/users
--------------D03371A731C3A952DFF82FC7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <p>I think that it could be useful.</p> <p><br> </p> <p>Greetings,</p> <p> Paolo<br> </p> <br> <div class="moz-cite-prefix">Il 06/12/2017 13:22, Nir Soffer ha scritto:<br> </div> <blockquote type="cite" cite="mid:CAMRbyyu4hOi79UU_g-50+6nFt--6JhkGFzKAmxZtueaQE=B49Q@mail.gmail.com"> <div dir="ltr">Thanks for sharing the solutions. <div><br> </div> <div>Maybe we need to mention this in the documentation?</div> </div> <br> <div class="gmail_quote"> <div dir="ltr">On Wed, Dec 6, 2017 at 1:27 PM Gianluca Cecchi <<a href="mailto:gianluca.cecchi@gmail.com" moz-do-not-send="true">gianluca.cecchi@gmail.com</a>> wrote:<br> </div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote">On Wed, Dec 6, 2017 at 9:03 AM, Paolo Margara <span dir="ltr"><<a href="mailto:paolo.margara@polito.it" target="_blank" moz-do-not-send="true">paolo.margara@polito.it</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div bgcolor="#FFFFFF"> Hi Gianluca,<br> <br> if you execute "engine-config --get ImageProxyAddress" the value of that attribute is your engine's fqdn?<br> <br> I had a similar issue in the past with my setup and in my case the problem was the wrong value of the attribute ImageProxyAddress, I hope this could be useful also for you.<br> <br> Greetings,<br> <br> Paolo <div> <div class="m_2547785755848581686gmail-h5"><br> </div> </div> </div> </blockquote> <div><br> </div> <div><br> </div> </div> </div> </div> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote"> <div>Oh, yes... I remember in the past something like this.... I forgot ...</div> <div><br> </div> <div>Indeed</div> <div>[root@ovirt ovirt-engine]# engine-config --get ImageProxyAddress</div> <div>ImageProxyAddress: localhost:54323 version: general</div> <div>[root@ovirt ovirt-engine]# </div> <div><br> </div> <div>So after executing:</div> <div><br> </div> <div>engine-config -s ImageProxyAddress=ovirt:54323<br> </div> <div><br> </div> <div>where "ovirt" is the hostname of my engine, engine service restart and ovirt-imageio-proxy service restart I was able to upload an image</div> <div>Thanks!</div> </div> </div> </div> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote"> <div>Gianluca</div> <div><br> </div> </div> </div> </div> _______________________________________________<br> Users mailing list<br> <a href="mailto:Users@ovirt.org" target="_blank" moz-do-not-send="true">Users@ovirt.org</a><br> <a href="http://lists.ovirt.org/mailman/listinfo/users" rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.ovirt.org/mailman/listinfo/users</a><br> </blockquote> </div> </blockquote> </body> </html> --------------D03371A731C3A952DFF82FC7--
On Wed, Dec 6, 2017 at 5:23 PM, Paolo Margara <paolo.margara@polito.it> wrote:
I think that it could be useful.
Greetings,
Paolo
+1 BTW: I notice that the disk seems preallocated even if original qcow2 is thin... is this expected? This obviously also impacts the time to upload (20Gb virtual disk with actual 1.2Gb occupied needs the time equivalent for full 20Gb...) On source (created from virt-manager in Fedora 26): # qemu-img info c7lab1.qcow2 image: c7lab1.qcow2 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 1.2G cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: true refcount bits: 16 corrupt: false After uploading on NFS storage domain: [root@ovirt01 251063f6-5570-4bdc-b28f-21e82aa5e185]# qemu-img info 77aacfb3-9e67-4ad2-96f6-242b5ba4d9e0 image: 77aacfb3-9e67-4ad2-96f6-242b5ba4d9e0 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 20G cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: true refcount bits: 16 corrupt: false [root@ovirt01 251063f6-5570-4bdc-b28f-21e82aa5e185]# Thanks, Gianluca
On Thu, Dec 7, 2017 at 12:33 AM Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
On Wed, Dec 6, 2017 at 5:23 PM, Paolo Margara <paolo.margara@polito.it> wrote:
I think that it could be useful.
Greetings,
Paolo
+1
BTW: I notice that the disk seems preallocated even if original qcow2 is thin... is this expected? This obviously also impacts the time to upload (20Gb virtual disk with actual 1.2Gb occupied needs the time equivalent for full 20Gb...)
We upload exactly the file you provided, there is no way we can upload 20G from 1.2G file :-) But maybe we created the file in the wrong format? Can you share vdsm logs from the spm, showing how the disk was created?
On source (created from virt-manager in Fedora 26):
# qemu-img info c7lab1.qcow2 image: c7lab1.qcow2 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 1.2G cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: true refcount bits: 16 corrupt: false
After uploading on NFS storage domain:
NFS version?
[root@ovirt01 251063f6-5570-4bdc-b28f-21e82aa5e185]# qemu-img info 77aacfb3-9e67-4ad2-96f6-242b5ba4d9e0 image: 77aacfb3-9e67-4ad2-96f6-242b5ba4d9e0 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 20G cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: true refcount bits: 16 corrupt: false [root@ovirt01 251063f6-5570-4bdc-b28f-21e82aa5e185]#
Thanks, Gianluca
On Wed, Dec 6, 2017 at 11:42 PM, Nir Soffer <nsoffer@redhat.com> wrote:
BTW: I notice that the disk seems preallocated even if original qcow2 is thin... is this expected? This obviously also impacts the time to upload (20Gb virtual disk with actual 1.2Gb occupied needs the time equivalent for full 20Gb...)
We upload exactly the file you provided, there is no way we can upload 20G from 1.2G file :-)
But the upload process at a medium rate of 40-50MB/s has last about 9 minutes that confirms the 20Gb size The disk at source has been created as virtio type and format qcow2 from virt-manager and then only installed a CentOS 7.2 OS with infrastructure server configuration. Apart from qemu-img also ls: # ls -lhs c7lab1.qcow2 1.3G -rw------- 1 root root 21G Dec 6 23:05 c7lab1.qcow2 On target after upload: [root@ovirt01 251063f6-5570-4bdc-b28f-21e82aa5e185]# ls -lhs 77aacfb3-9e67-4ad2-96f6-242b5ba4d9e0 21G -rw-rw----. 1 vdsm kvm 21G Dec 6 23:44 77aacfb3-9e67-4ad2-96f6-242b5ba4d9e0 [root@ovirt01 251063f6-5570-4bdc-b28f-21e82aa5e185]#
But maybe we created the file in the wrong format?
Can you share vdsm logs from the spm, showing how the disk was created?
First message at beginning of upload:
2017-12-06 23:09:50,183+0100 INFO (jsonrpc/4) [vdsm.api] START createVolume(sdUUID=u'572eabe7-15d0-42c2-8fa9-0bd773e22e2e', spUUID=u'00000001-0001-0001-0001-000000000343', imgUUID=u'251063f6-5570-4bdc-b28f-21e82aa5e185', size=u'22548578304', volFormat=4, preallocate=2, diskType=2, volUUID=u'77aacfb3-9e67-4ad2-96f6-242b5ba4d9e0', desc=u'{"DiskAlias":"c7lab1","DiskDescription":""}', srcImgUUID=u'00000000-0000-0000-0000-000000000000', srcVolUUID=u'00000000-0000-0000-0000-000000000000', initialSize=None) from=192.168.1.212,56846, flow_id=18c6bd3b-76ab-45f9-b8c7-09c727f44c91, task_id=e7cc67e6-4b61-4bb3-81b1-6bc687ea5ee9 (api:46) Last message that corresponds to completion of upload: 2017-12-06 23:21:03,914+0100 INFO (jsonrpc/4) [storage.VolumeManifest] 572eabe7-15d0-42c2-8fa9-0bd773e22e2e/251063f6-5570-4bdc-b28f-21e82aa5e185/77aacfb3-9e67-4ad2-96f6-242b5ba4d9e0 info is {'status': 'OK', 'domain': '572eabe7-15d0-42c2-8fa9-0bd773e22e2e', 'voltype': 'LEAF', 'description': '{"DiskAlias":"c7lab1","DiskDescription":""}', 'parent': '00000000-0000-0000-0000-000000000000', 'format': 'COW', 'generation': 0, 'image': '251063f6-5570-4bdc-b28f-21e82aa5e185', 'ctime': '1512598190', 'disktype': '2', 'legality': 'LEGAL', 'mtime': '0', 'apparentsize': '21496266752', 'children': [], 'pool': '', 'capacity': '22548578304', 'uuid': u'77aacfb3-9e67-4ad2-96f6-242b5ba4d9e0', 'truesize': '21496602624', 'type': 'SPARSE', 'lease': {'owners': [], 'version': None}} (volume:272) 2017-12-06 23:21:03,915+0100 INFO (jsonrpc/4) [vdsm.api] FINISH getVolumeInfo return={'info': {'status': 'OK', 'domain': '572eabe7-15d0-42c2-8fa9-0bd773e22e2e', 'voltype': 'LEAF', 'description': '{"DiskAlias":"c7lab1","DiskDescription":""}', 'parent': '00000000-0000-0000-0000-000000000000', 'format': 'COW', 'generation': 0, 'image': '251063f6-5570-4bdc-b28f-21e82aa5e185', 'ctime': '1512598190', 'disktype': '2', 'legality': 'LEGAL', 'mtime': '0', 'apparentsize': '21496266752', 'children': [], 'pool': '', 'capacity': '22548578304', 'uuid': u'77aacfb3-9e67-4ad2-96f6-242b5ba4d9e0', 'truesize': '21496602624', 'type': 'SPARSE', 'lease': {'owners': [], 'version': None}}} from=192.168.1.212,56840, flow_id=18c6bd3b-76ab-45f9-b8c7-09c727f44c91, task_id=6b268651-4a7f-4366-9d01-829deaa16bfd (api:52) Full vdsm.log.gz in between here: https://drive.google.com/file/d/1IZIKDXyNN3bc6035C5Rc5WiI_UZ_g0ZV/view?usp=s...
NFS version?
The mount done from the host is this: [root@ovirt01 /] # mount | grep NFS_DOMAIN ovirt01:/NFS_DOMAIN on /rhev/data-center/mnt/ovirt01:_NFS__DOMAIN type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,soft,nosharecache,proto=tcp,timeo=600,retrans=6,sec=sys,mountaddr=192.168.1.211,mountvers=3,mountport=20048,mountproto=udp,local_lock=none,addr=192.168.1.211) This is a test system so that I only have one host and the NFS mount is done over an XFS local filesystem exported by itself, but I think this should not be relevant for this particular test... Another note: it seems that in events there is no message related to image upload completion. I only see: Dec 6, 2017 11:09:51 PM Add-Disk operation of 'c7lab1' was initiated by the system. Dec 6, 2017 11:09:49 PM Image Upload with disk c7lab1 was initiated by admin@internal-authz. and no message around 23:21 when the upload completes. Thanks, Gianluca
On Thu, Dec 7, 2017 at 1:22 AM Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
On Wed, Dec 6, 2017 at 11:42 PM, Nir Soffer <nsoffer@redhat.com> wrote:
BTW: I notice that the disk seems preallocated even if original qcow2 is thin... is this expected? This obviously also impacts the time to upload (20Gb virtual disk with actual 1.2Gb occupied needs the time equivalent for full 20Gb...)
We upload exactly the file you provided, there is no way we can upload 20G from 1.2G file :-)
But the upload process at a medium rate of 40-50MB/s has last about 9 minutes that confirms the 20Gb size The disk at source has been created as virtio type and format qcow2 from virt-manager and then only installed a CentOS 7.2 OS with infrastructure server configuration. Apart from qemu-img also ls: # ls -lhs c7lab1.qcow2 1.3G -rw------- 1 root root 21G Dec 6 23:05 c7lab1.qcow2
The fiile size is 21G - matching what you see. This is the size we upload. 1.3G is the used size on the file system, we cannot upload only used blocks. qemu-img info "Disk size" is not the file size the the used size, not useful for upload. Maybe this file was crated with preallocation=full? To optimize this file for upload, you can do: qemu convert -p -f qcow2 -O qcow2 c7lab1.qcow2 c7lab1-opt.qcow2 I think the output file size will be shrink. You can also compress it: qemu convert -p -c -f qcow2 -O qcow2 c7lab1.qcow2 c7lab1-compressed.qcow2 Please share the results.
On target after upload:
[root@ovirt01 251063f6-5570-4bdc-b28f-21e82aa5e185]# ls -lhs 77aacfb3-9e67-4ad2-96f6-242b5ba4d9e0 21G -rw-rw----. 1 vdsm kvm 21G Dec 6 23:44 77aacfb3-9e67-4ad2-96f6-242b5ba4d9e0 [root@ovirt01 251063f6-5570-4bdc-b28f-21e82aa5e185]#
But maybe we created the file in the wrong format?
Can you share vdsm logs from the spm, showing how the disk was created?
First message at beginning of upload:
2017-12-06 23:09:50,183+0100 INFO (jsonrpc/4) [vdsm.api] START createVolume(sdUUID=u'572eabe7-15d0-42c2-8fa9-0bd773e22e2e', spUUID=u'00000001-0001-0001-0001-000000000343', imgUUID=u'251063f6-5570-4bdc-b28f-21e82aa5e185', size=u'22548578304', volFormat=4, preallocate=2, diskType=2, volUUID=u'77aacfb3-9e67-4ad2-96f6-242b5ba4d9e0', desc=u'{"DiskAlias":"c7lab1","DiskDescription":""}', srcImgUUID=u'00000000-0000-0000-0000-000000000000', srcVolUUID=u'00000000-0000-0000-0000-000000000000', initialSize=None) from=192.168.1.212,56846, flow_id=18c6bd3b-76ab-45f9-b8c7-09c727f44c91, task_id=e7cc67e6-4b61-4bb3-81b1-6bc687ea5ee9 (api:46)
Last message that corresponds to completion of upload:
2017-12-06 23:21:03,914+0100 INFO (jsonrpc/4) [storage.VolumeManifest] 572eabe7-15d0-42c2-8fa9-0bd773e22e2e/251063f6-5570-4bdc-b28f-21e82aa5e185/77aacfb3-9e67-4ad2-96f6-242b5ba4d9e0 info is {'status': 'OK', 'domain': '572eabe7-15d0-42c2-8fa9-0bd773e22e2e', 'voltype': 'LEAF', 'description': '{"DiskAlias":"c7lab1","DiskDescription":""}', 'parent': '00000000-0000-0000-0000-000000000000', 'format': 'COW', 'generation': 0, 'image': '251063f6-5570-4bdc-b28f-21e82aa5e185', 'ctime': '1512598190', 'disktype': '2', 'legality': 'LEGAL', 'mtime': '0', 'apparentsize': '21496266752', 'children': [], 'pool': '', 'capacity': '22548578304', 'uuid': u'77aacfb3-9e67-4ad2-96f6-242b5ba4d9e0', 'truesize': '21496602624', 'type': 'SPARSE', 'lease': {'owners': [], 'version': None}} (volume:272) 2017-12-06 23:21:03,915+0100 INFO (jsonrpc/4) [vdsm.api] FINISH getVolumeInfo return={'info': {'status': 'OK', 'domain': '572eabe7-15d0-42c2-8fa9-0bd773e22e2e', 'voltype': 'LEAF', 'description': '{"DiskAlias":"c7lab1","DiskDescription":""}', 'parent': '00000000-0000-0000-0000-000000000000', 'format': 'COW', 'generation': 0, 'image': '251063f6-5570-4bdc-b28f-21e82aa5e185', 'ctime': '1512598190', 'disktype': '2', 'legality': 'LEGAL', 'mtime': '0', 'apparentsize': '21496266752', 'children': [], 'pool': '', 'capacity': '22548578304', 'uuid': u'77aacfb3-9e67-4ad2-96f6-242b5ba4d9e0', 'truesize': '21496602624', 'type': 'SPARSE', 'lease': {'owners': [], 'version': None}}} from=192.168.1.212,56840, flow_id=18c6bd3b-76ab-45f9-b8c7-09c727f44c91, task_id=6b268651-4a7f-4366-9d01-829deaa16bfd (api:52)
Full vdsm.log.gz in between here:
https://drive.google.com/file/d/1IZIKDXyNN3bc6035C5Rc5WiI_UZ_g0ZV/view?usp=s...
NFS version?
The mount done from the host is this:
[root@ovirt01 /] # mount | grep NFS_DOMAIN ovirt01:/NFS_DOMAIN on /rhev/data-center/mnt/ovirt01:_NFS__DOMAIN type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,soft,nosharecache,proto=tcp,timeo=600,retrans=6,sec=sys,mountaddr=192.168.1.211,mountvers=3,mountport=20048,mountproto=udp,local_lock=none,addr=192.168.1.211)
This is a test system so that I only have one host and the NFS mount is done over an XFS local filesystem exported by itself, but I think this should not be relevant for this particular test...
Another note: it seems that in events there is no message related to image upload completion. I only see:
Dec 6, 2017 11:09:51 PM Add-Disk operation of 'c7lab1' was initiated by the system. Dec 6, 2017 11:09:49 PM Image Upload with disk c7lab1 was initiated by admin@internal-authz.
and no message around 23:21 when the upload completes. Thanks, Gianluca
participants (3)
-
Gianluca Cecchi -
Nir Soffer -
Paolo Margara