Description of problem: all-in-one is no longer supported as per the documentation support ended in ovirt 4.0. I have continued using all-in-one setups as these setups work nicely for single host dc, dedicated hosts. The recent changes to ovirt-imageio make it incompatible with all-in-one setups as it expects different setups for engine vs remote. ie both; /etc/ovirt-imageio/conf.d/50-engine.conf and /etc/ovirt-imageio/conf.d/50-vdsm.conf end up on the same machine, whereas the new expected behaviour is to have one per host. if this can't be fixed or is too much work to fix, then it would be wise to add a warning in the engine, when the engine host is added as a hypervisor (making an all-in-one setup), that should warn this setup is depricated and image download / upload won't work. This functionality still works in ovirt 4.3 as the imageio topology is different. Version-Release number of selected component (if applicable): broken in: ovirt-engine-4.4.1.10-1.el8.noarch ovirt-imageio-client-2.0.9-1.el8.x86_64 ovirt-imageio-daemon-2.0.9-1.el8.x86_64 ovirt-engine-setup-plugin-imageio-4.4.1.10-1.el8.noarch ovirt-imageio-debugsource-2.0.9-1.el8.x86_64 ovirt-imageio-common-2.0.9-1.el8.x86_64 working in: ovirt-engine-4.3.1.1-1.el7.noarch ovirt-imageio-common-1.5.3-0.el7.x86_64 ovirt-imageio-daemon-1.5.3-0.el7.noarch ovirt-imageio-proxy-1.5.3-0.el7.noarch ovirt-imageio-proxy-setup-1.5.3-0.el7.noarch How reproducible: 100% Steps to Reproduce: 1. Follow the alt-install steps using engine-setup 2. Add the standalone engine as a host (making an all-in-one setup) 3. Try to download/upload images Actual results: engine can't communicate with the proxy, changing remote port to 54323 and daemon to local socket gets half way there but no win. Expected results: ability to upload and download images. Additional info: I'd really like to see all-in-one supported again as this keeps hardware requirements to a minimum, this keeps ovirt available to the masses. Options I have at the moment: oVirt as a self-hosted engine = not compatible with hosting provider, and requires shared storage, not ideal for single host dedicated server. oVirt as a standalone Manager = Requires 2x host as all-in-one not supported.
The issue is not imageio architecture, but the assumption that engine is always have a proxy. In 4.3 we had both imageio proxy and server running on the same host. When transferring images from administration portal, the portal transferred the data to the imageio proxy, which sent the data to the imageio server, writing the data to storage. In all-in-one-setup engine run on the same host as vdsm, and the proxy is not needed. However engine does not detect this issue and try to use the non-existing proxy. If we want to support all-in-one setup, engine need to detect this kind of setup, and disable usage of the proxy. Changes needed when running in all-in-one setup: - Detect this mode. I think this can be easy as checking if any of the hosts is using engine FQDN or IP address. - When uploading images from the administration portal, the portal should use the daemon port (54322) instead of the proxy port (54323). - When adding and removing tickets for image transfer, engine should skip the proxy. - ImageTransfer.proxy_url should be same as ImageTransfer.transfer_url, to be compatible with application using proxy_url. - 50-vdsm.conf must specify the control section, so 50-enigne.conf do not override it. In normal installation this is not needed since this is the default, but engine overrides this. [control] transport = unix - 50-vdsm.conf should be renamed to 60-vdsm.conf, so it is clear that it should override 50-engine.conf. Currently it works because 50-vdsm.conf is sorted after 50-engine.conf, but this confusing. This is not a large change, but all-in-one setup is not supported or tested. I think we can do this 4.4.4. Sandro, what do you think?
The documentation text flag should only be set after 'doc text' field is provided. Please provide the documentation text and set the flag to '?' again.
Michael, we need to understand better the use case. You wrote: > I have continued using all-in-one setups as these setups work nicely > for single host dc, dedicated hosts. And: > oVirt as a self-hosted engine = not compatible with hosting provider, > and requires shared storage, not ideal for single host dedicated server. Why this is not compatible with the hosting provider? Why it requires shared storage? The recommended setup for all-in-one installation is hosted engine. You need only one host for this setup, and local storage should be supported. It not, you can use gluster (HCI setup) or NFS (configure NFS on this host). In this setup engine runs as a VM in the cluster, same as the other VMs that you are going to run in this setup. If you can run other VMs, there is no reason why engine VM cannot run. This requires little more memory, since the memory you give to the hosted engine VM cannot be used by other VMs, but for a small setup engine runs fine with 4 GiB of memory, so the difference is only 1-2 GiB of memory. Can you explain why you cannot use this on your dedicated host?
More info on fixing this in engine: This creates the proxy URL used by the administration portal: 1270 public static String getProxyUri() { 1271 String scheme = Config.<Boolean> getValue(ConfigValues.ImageProxySSLEnabled)? HTTPS_SCHEME : HTTP_SCHEME; 1272 return scheme + EngineLocalConfig.getInstance().getHost() + ":" + PROXY_DATA_PORT; 1273 } If engine is running in all-in-one setup, we can return here: return getImageDaemonUri(EngineLocalConfig.getInstance().getHost()); The scheme check is pointless since SSL is only implemented scheme. In vdsm we need this change: diff --git a/static/etc/ovirt-imageio/conf.d/50-vdsm.conf b/static/etc/ovirt-imageio/conf.d/50-vdsm.conf index 7440d92fe..5d187fd7e 100644 --- a/static/etc/ovirt-imageio/conf.d/50-vdsm.conf +++ b/static/etc/ovirt-imageio/conf.d/50-vdsm.conf @@ -30,3 +30,8 @@ ca_file = /etc/pki/vdsm/certs/cacert.pem # rules on the host, and changing this value in engine configuration. vdsm # assumes this port, don't change it. port = 54322 + +[control] +# Required to work in all-in-one setup, when both engine configuration and vdsm +# configuration are installed. +transport = unix With these changes upload and download from the admin portal should work.
(In reply to Nir Soffer from comment #3) > Michael, we need to understand better the use case. You wrote: > > > I have continued using all-in-one setups as these setups work nicely > > for single host dc, dedicated hosts. > > And: > > > oVirt as a self-hosted engine = not compatible with hosting provider, > > and requires shared storage, not ideal for single host dedicated server. > > Why this is not compatible with the hosting provider? The biggest blocker for OVH (single dedicated server) and self-hosted engine is the ip requirements. With this dedicated server I have to work entirely with public ip, installers will only work with physical online nics. a box will come with for example; IP: 200.0.0.10 GW: 200.0.0.254 however, I need an IP for both; - engine - host so... I can register a block of public ip... but now I need the ip in the same subnet (installer restriction); say i'm provided 100.0.0.240/28, although I can change the primary IP of the host (without alias, had to disable OVH's ping test for this otherwise they take the server down), I can't change the GW, this is a restriction from OVH, ie I can have; Host IP: 100.0.0.240 VM IP: 100.0.0.241 GW:200.0.0.254 but, i can't have; Host IP: 100.0.0.240 VM IP: 100.0.0.241 GW:100.0.0.254 OVH, just won't route this, this leaves me with the GW on a different subnet which fails the installer. > > Why it requires shared storage? > > The recommended setup for all-in-one installation is hosted engine. > You need only one host for this setup, and local storage should be > supported. It not, you can use gluster (HCI setup) or NFS (configure > NFS on this host). local because of the installer requirements, but I could use gluster/nfs, however this would be abit of a waste of resources on a single host. this part is not so much of a problem, i cloud use gluster/nfs if needs be... I have tested the perf of nfs in the past on ovh dedicated servers, but reverted back to local for perf. I've not yet tested gluster single node perf for vm (pretty sure local will be a smoother ride, but i could go this route). > > In this setup engine runs as a VM in the cluster, same as the > other VMs that you are going to run in this setup. If you can run > other VMs, there is no reason why engine VM cannot run. yep, 100%, it's more the installer getting in the way. > > This requires little more memory, since the memory you give to the > hosted engine VM cannot be used by other VMs, but for a small setup > engine runs fine with 4 GiB of memory, so the difference is only > 1-2 GiB of memory. > yes, i've been shrinking the xmx of the engine on these dedicated hosts back down to 4G which was an older limit. > Can you explain why you cannot use this on your dedicated host? 1. ip address blocker 2. preference over storage Even if i ipmi-kvm and use local ip during install, i'd still have the issue the GW would be on a different subnet, I can't connect to any other gateway than the original one allocated to the server.
(In reply to Michael Jones from comment #5) How are you doing to handle the VMs IP addresses? Engine IP address should work like any other VM in your setup. Are you assuming public access to engine admin portal over the web, using the host public IP address? Can you show an example of the entire deployment with all the VMs you plan to run on this setup?
(In reply to Nir Soffer from comment #6) > (In reply to Michael Jones from comment #5) > How are you doing to handle the VMs IP addresses? > > Engine IP address should work like any other VM in your setup. > > Are you assuming public access to engine admin portal over the web, > using the host public IP address? > > Can you show an example of the entire deployment with all the VMs > you plan to run on this setup? are you asking about the hosted engine setup, or the all-in-one setup? for hosted engine: [ ERROR ] The Engine VM (54.x.x.17/28) and the default gateway (158.x.x.254) will not be in the same IP subnet. the installer won't allow you to proceed if any of; - host - engine - gw are not in the same subnet. for all in one: a typical all-in-one setup that i've been using for years would example ips; HOST IP: 120.0.0.10 GW: 120.0.0.254 extra public IP: 141.0.0.32/28 I would setup/install with ovirtmgmt taking the main IP, once installed I setup vlans which are tagged, these don't route to OVH. example vlan: 10.0.0.0/24 this provides: ovirtmgmt = 120.0.0.10 vlanl1 = 10.0.0.1 on a vm where I want local access only, it gets a dhcp lease automatically from vlan; on a vm where I want public access, I assign a nic in both the vlan and ovirtmgmt network. the nic from ovirtmgmt has a custom MAC address, these custom mac address are provided by OVH, I use tools like FAI and ansible to provision / setup these vms. even on a vm with no public access I can still access the remote console as this is provided by the host. I also tend to setup a bastion node, the bastion can connect to the vms on vlan, but it also has a public ip. example vms; - haxproxy-01 - ovirtmgmt = 141.0.0.32 - vlanl1 = 10.0.0.2 - haxproxy-02 - ovirtmgmt = 141.0.0.33 - vlanl1 = 10.0.0.3 - vpn-01 - ovirtmgmt = 141.0.0.34 - vlanl1 = 10.0.0.4 - bastion-01 - ovirtmgmt = 141.0.0.35 - vlanl1 = 10.0.0.5 - zabbix-proxy-01 - ovirtmgmt = 141.0.0.36 - vlanl1 = 10.0.0.6 - db-01 - vlanl1 = 10.0.0.7 - web-01 - vlanl1 = 10.0.0.8 - squid-01 - vlanl1 = 10.0.0.9
(In reply to Michael Jones from comment #7) > example vms; > > - haxproxy-01 > - ovirtmgmt = 141.0.0.32 > - vlanl1 = 10.0.0.2 > - haxproxy-02 > - ovirtmgmt = 141.0.0.33 > - vlanl1 = 10.0.0.3 > - vpn-01 > - ovirtmgmt = 141.0.0.34 > - vlanl1 = 10.0.0.4 > - bastion-01 > - ovirtmgmt = 141.0.0.35 > - vlanl1 = 10.0.0.5 > - zabbix-proxy-01 > - ovirtmgmt = 141.0.0.36 > - vlanl1 = 10.0.0.6 > - db-01 > - vlanl1 = 10.0.0.7 > - web-01 > - vlanl1 = 10.0.0.8 > - squid-01 > - vlanl1 = 10.0.0.9 So ideally, you want your hosted engine VM to use something like: - hosted-engine - ovirtmgmt = 141.0.0.31 - vlanl1 = 10.0.0.1 Dominic, do we a have a way to configure hosted engine networking so it adapt better to such environment?
Michael, the attached patch fixes the vdsm side. It is not enough to allow image transfer from admin portal, but with this patch image transfer from the SDK should work. This is a simple configuration change that you can apply manually, but it will help if you test this change by upgrading vdsm using this repo: https://jenkins.ovirt.org/job/vdsm_standard-check-patch/23134/artifact/build-artifacts.build-py3.el8.x86_64/ After the upgrade this should work: dnf install python3-ovirt-engine-sdk4 ovirt-imageio-client python3 /usr/share/doc/python3-ovirt-engine-sdk4/examples/upload_disk.py \ --engine-url https://engine-fqdn:port/ \ --username admin@internal \ --cafile engine.pem \ --sd-name my-domain-name \ foo.iso
We have more issues - duplicate firewalld services - engine setup installs /etc/firewalld/services/ovirt-imageio.xml $ cat /etc/firewalld/services/ovirt-imageio.xml <?xml version="1.0" encoding="utf-8"?> <service> <short>ovirt-imageio</short> <description>oVirt ImageIO service</description> <port protocol="tcp" port="54323"/> </service> - vdsm (or host deply) installs # cat /usr/lib/firewalld/services/ovirt-imageio.xml <?xml version="1.0" encoding="utf-8"?> <service> <short>oVirt Image I/O</short> <description>oVirt Image I/O simplifies the workflow of introducing new oVirt images into the oVirt environment.</description> <port protocol="tcp" port="54322"/> </service> The version in /etc/ overrides the /usr/lib version: # firewall-cmd --info-service ovirt-imageio ovirt-imageio ports: 54323/tcp protocols: source-ports: modules: destination: includes: helpers: So accessing ImageTransfer.transfer_url fails with: $ curl -k https://aio:54322/images/test curl: (7) Failed to connect to aio port 54322: No route to host We need to install 2 different services: - ovirt-imageio-server - ovirt-imageio-proxy To fix this issue the xml file in /etc/ can be modifed to open port 54322.
More issues - both vdsm and engine install files in /etc/sysctl.d/ $ cat /etc/sysctl.d/vdsm.conf ... # locally reserve vdsm and ovirt-imageio ports net.ipv4.ip_local_reserved_ports=54321,54322 $ cat /etc/sysctl.d/ovirt-engine.conf # ovirt-engine configuration. net.ipv4.ip_local_reserved_ports = 54323,54324 $ sysctl net.ipv4.ip_local_reserved_ports net.ipv4.ip_local_reserved_ports = 54321-54322 So in this case vdsm wins, which is fine, but the order of the file is not clear because we don't use numbered file names. We need to rename the files to: - 50-engine.conf - 60-vdsm.conf
(In reply to Nir Soffer from comment #9) > Michael, the attached patch fixes the vdsm side. It is not enough > to allow image transfer from admin portal, but with this patch > image transfer from the SDK should work. > > This is a simple configuration change that you can apply manually, > but it will help if you test this change by upgrading vdsm using > this repo: > https://jenkins.ovirt.org/job/vdsm_standard-check-patch/23134/artifact/build- > artifacts.build-py3.el8.x86_64/ > > After the upgrade this should work: > > dnf install python3-ovirt-engine-sdk4 ovirt-imageio-client > > python3 /usr/share/doc/python3-ovirt-engine-sdk4/examples/upload_disk.py > \ > --engine-url https://engine-fqdn:port/ \ > --username admin@internal \ > --cafile engine.pem \ > --sd-name my-domain-name \ > foo.iso perhaps i've missed a step; [root@ovirt ~]# dnf config-manager --add-repo https://jenkins.ovirt.org/job/vdsm_standard-check-patch/23134/artifact/build-artifacts.build-py3.el8.x86_64/ Adding repo from: https://jenkins.ovirt.org/job/vdsm_standard-check-patch/23134/artifact/build-artifacts.build-py3.el8.x86_64/ [root@ovirt ~]# dnf --showduplicate list python3-ovirt-engine-sdk4.x86_64 ovirt-imageio-client.x86_64 created by dnf config-manager from https://jenkins.ovirt.org/job/vdsm_standard-check-patch/23134/artifact/build-artifacts.build-py3.el8.x86_64/ 12 kB/s | 19 kB 00:01 Installed Packages ovirt-imageio-client.x86_64 2.0.9-1.el8 @ovirt-4.4 python3-ovirt-engine-sdk4.x86_64 4.4.4-1.el8 @ovirt-4.4 Available Packages ovirt-imageio-client.x86_64 2.0.6-0.el8 ovirt-4.4 ovirt-imageio-client.x86_64 2.0.7-0.el8 ovirt-4.4 ovirt-imageio-client.x86_64 2.0.8-1.el8 ovirt-4.4 ovirt-imageio-client.x86_64 2.0.9-1.el8 ovirt-4.4 python3-ovirt-engine-sdk4.x86_64 4.4.2-1.el8 ovirt-4.4 python3-ovirt-engine-sdk4.x86_64 4.4.3-1.el8 ovirt-4.4 python3-ovirt-engine-sdk4.x86_64 4.4.4-1.el8 ovirt-4.4 [root@ovirt ~]# dnf install python3-ovirt-engine-sdk4 ovirt-imageio-client Last metadata expiration check: 0:00:14 ago on Mon 24 Aug 2020 11:03:08 UTC. Package python3-ovirt-engine-sdk4-4.4.4-1.el8.x86_64 is already installed. Package ovirt-imageio-client-2.0.9-1.el8.x86_64 is already installed. Dependencies resolved. Nothing to do. Complete! ------------ perhaps i was too slow and missed my chance the only artifacts i see now are vdsm-*, no python3-ovirt-* or ovirt-imageio-*
(In reply to Michael Jones from comment #12) > perhaps i've missed a step; I forgot to mention that you need to upgrade vdsm, I thought it is obvious since this is a vdsm build, but it is probably not :-) dnf update vdsm\* This should pull vdsm with the fix from jenkins repo.
perhaps i'm missing a 2nd new repo? - nothing provides ovirt-imageio-common >= 2.0.10-1 needed by vdsm-4.40.26-20.git72e398768.el8.x86_64
ovirt-imageio >= 2.0.10-1 should be available in ovirt repos. Are you using latest ovirt-release44.rpm? It is available in this repo: https://jenkins.ovirt.org/job/ovirt-imageio_standard-on-merge/817/artifact/build-artifacts.py3.el8.x86_64/
ovirt-imageio 2.0.10-1 is also available in the 4.4 pre repo: https://resources.ovirt.org/pub/ovirt-4.4-pre/rpm/el8/x86_64/ If you upgrade to 4.4.2 you will get this package. https://www.ovirt.org/release/4.4.2/ You have to enable the 4.4 pre repo: dnf install http://resources.ovirt.org/pub/yum-repo/ovirt-release44-pre.rpm But if you want to keep your setup more stable, you can keep 4.4.1 and update only the components needed to fix this issue.
(In reply to Nir Soffer from comment #16) > ovirt-imageio 2.0.10-1 is also available in the 4.4 pre repo: > > https://resources.ovirt.org/pub/ovirt-4.4-pre/rpm/el8/x86_64/ > > If you upgrade to 4.4.2 you will get this package. > https://www.ovirt.org/release/4.4.2/ > > You have to enable the 4.4 pre repo: > > dnf install > http://resources.ovirt.org/pub/yum-repo/ovirt-release44-pre.rpm > > But if you want to keep your setup more stable, you can keep 4.4.1 and update > only the components needed to fix this issue. I have a test machine at home with a couple of spare drives, i'll give it a whirl later today using; - https://jenkins.ovirt.org/job/ovirt-imageio_standard-on-merge/817/artifact/build-artifacts.py3.el8.x86_64/ - https://jenkins.ovirt.org/job/vdsm_standard-check-patch/23134/artifact/build-artifacts.build-py3.el8.x86_64/ and 4.4.2 if i have further issues. the machine i was testing on was Version 4.4.1.10-1.el8. Thanks, Mike
I have a test machine up and running; 4.4 all-in-one install = - 50-engine.conf - 50-vdsm.conf update vdsm = - 50-engine.conf - 60-vdsm.conf but i'm doing something wrong, ovirtsdk4.Error: The response content type 'text/plain; charset=UTF-8' isn't the expected JSON i'll try to work out, first guess would be wrong port number used as it's got the wrong data back... i'll update shortly.
yep, it's working i had the wrong port in the script; [root@test-ovirt bin]# ./test-upload-iso.sh Checking image... Image format: raw Disk format: raw Disk content type: iso Disk provisioned size: 1718616064 Disk initial size: 1718616064 Disk name: foo.raw Disk backup: False Connecting... Password: Creating disk... Disk ID: 63c56960-bf79-40ce-b744-e15f481e1915 Creating image transfer... Transfer ID: b5af9f26-a40f-45a5-a3cc-b6121b270673 Transfer host name: test-ovirt Uploading image... ^Z 15.62% ] 256.00 MiB, 8.51 seconds, 30.07 MiB/s I'll have a play and see if that resolves vprotect, probably no... (suspect vprotect is dependant on proxy as per email chain, but i'll double check / test)
(In reply to Michael Jones from comment #18) > but i'm doing something wrong, > > ovirtsdk4.Error: The response content type 'text/plain; charset=UTF-8' > isn't the expected JSON Where do you get this error? Can you share complete command run, including the entire outpt showing this error? Note that you also have to fix firewalld configuration, see comment 10.
Regarding vprotect, it will not help. We need to teach engine to skip the proxy. The change is easy, but I don't see a good way to detect this case yet. Maybe we can start with simple configuration like: engine-config -s "EnableImageioProxy=false" This will allow manual configuration until we have a better way, and since this configuration is not officially supported, maybe this is good enough?
(In reply to Nir Soffer from comment #20) > (In reply to Michael Jones from comment #18) > > but i'm doing something wrong, > > > > ovirtsdk4.Error: The response content type 'text/plain; charset=UTF-8' > > isn't the expected JSON > > Where do you get this error? Can you share complete command run, including > the entire outpt showing this error? > > Note that you also have to fix firewalld configuration, see comment 10. was; OVIRT_IMAGEIO_PORT="54322" python3 /usr/share/doc/python3-ovirt-engine-sdk4/examples/upload_disk.py \ --engine-url https://$OVIRT_IMAGEIO_HOST:$OVIRT_IMAGEIO_PORT \ --username admin@internal \ --cafile "$OVIRT_IMAGEIO_CA" \ --sd-name $OVIRT_DOMAIN \ --debug \ $1 my bad, and was changed to; OVIRT_IMAGEIO_PORT="443" which works fine, i've now uploaded images, thanks. (In reply to Nir Soffer from comment #21) > Regarding vprotect, it will not help. We need to teach engine to skip > the proxy. The change is easy, but I don't see a good way to detect > this case yet. > > Maybe we can start with simple configuration like: > > engine-config -s "EnableImageioProxy=false" > > This will allow manual configuration until we have a better way, and since > this configuration is not officially supported, maybe this is good enough? that would work fine for my usage.
(In reply to Michael Jones from comment #22) > python3 /usr/share/doc/python3-ovirt-engine-sdk4/examples/upload_disk.py \ > --engine-url https://$OVIRT_IMAGEIO_HOST:$OVIRT_IMAGEIO_PORT \ > --username admin@internal \ > --cafile "$OVIRT_IMAGEIO_CA" \ > --sd-name $OVIRT_DOMAIN \ > --debug \ This is going to confuse people later, better call all these OVIRT_ENGINE_XXX ovirt-imagio uses ports 54322 and 54323. > my bad, and was changed to; > > OVIRT_IMAGEIO_PORT="443" Since this is default https port you don't need to specify it. > > Maybe we can start with simple configuration like: > > > > engine-config -s "EnableImageioProxy=false" > > > > This will allow manual configuration until we have a better way, and since > > this configuration is not officially supported, maybe this is good enough? > > that would work fine for my usage. I think that something like: engine-config -s "AllInOneDeployment=true" Would be better. We may have other issues related to this deployment regardless of imageio issues.
(In reply to Nir Soffer from comment #23) > (In reply to Michael Jones from comment #22) > > python3 /usr/share/doc/python3-ovirt-engine-sdk4/examples/upload_disk.py \ > > --engine-url https://$OVIRT_IMAGEIO_HOST:$OVIRT_IMAGEIO_PORT \ > > --username admin@internal \ > > --cafile "$OVIRT_IMAGEIO_CA" \ > > --sd-name $OVIRT_DOMAIN \ > > --debug \ > > This is going to confuse people later, better call all these > > OVIRT_ENGINE_XXX > > ovirt-imagio uses ports 54322 and 54323. sorry, was just a quick test script had pulled all the possibilities from config in imageio; #OVIRT_IMAGEIO_CA="/etc/pki/vdsm/certs/cacert.pem" #OVIRT_IMAGEIO_CA="/etc/pki/ovirt-engine/apache-ca.pem" OVIRT_IMAGEIO_CA="/etc/pki/ovirt-engine/ca.pem" script with names cleaned up; #!/bin/bash #transfer URL (e.g. https://engine_fqdn:port) OVIRT_ENGINE_HOST="test-ovirt.blah.uk" OVIRT_ENGINE_PORT="443" #username of engine API OVIRT_ENGINE_USERNAME="admin@internal" # path to oVirt engine certificate for verifying server. OVIRT_ENGINE_CA="/etc/pki/ovirt-engine/ca.pem" # name of the storage domain OVIRT_ENGINE_STORAGE_DOMAIN="ovirt_local_data" # path to image (e.g. /path/to/image.raw) Supported formats: raw, qcow2, iso if [ -z "$1" ]; then echo "usage: ./test-upload-iso.sh filename.iso" exit 1 fi # other opts... # --password-file : file containing password of the specified by user (if file is not specified, read from standard input) # --disk-format choices=("raw", "qcow2") : format of the created disk (default image format) # --disk-sparse action="store_true" : create sparse disk. Cannot be used with raw format on block storage. # --enable-backup action="store_true" : creates a disk that can be used for incremental backup. Allowed for disk with qcow2 format only # --insecure default=False : do not verify server certificates and host name (not recommended). # --use-proxy dest="use_proxy default=False : upload via proxy on the engine host (less efficient) # --max-workers : Maximum number of workers to use for upload. The default (4) improves performance when uploading a single disk. You may want to use lower number if you upload many disks in the same time. # --debug : log debug level messages to example.log python3 /usr/share/doc/python3-ovirt-engine-sdk4/examples/upload_disk.py \ --engine-url https://$OVIRT_ENGINE_HOST:$OVIRT_ENGINE_PORT \ --username "$OVIRT_ENGINE_USERNAME" \ --cafile "$OVIRT_ENGINE_CA" \ --sd-name $OVIRT_DOMAIN \ --debug \ $1 (descriptions from /usr/share/doc/python3-ovirt-engine-sdk4/examples/upload_disk.py) > > > my bad, and was changed to; > > > > OVIRT_IMAGEIO_PORT="443" > > Since this is default https port you don't need to specify it. > > > > Maybe we can start with simple configuration like: > > > > > > engine-config -s "EnableImageioProxy=false" > > > > > > This will allow manual configuration until we have a better way, and since > > > this configuration is not officially supported, maybe this is good enough? > > > > that would work fine for my usage. > > I think that something like: > > engine-config -s "AllInOneDeployment=true" > > Would be better. We may have other issues related to this deployment > regardless of imageio issues. I was thinking to suggest this, but i didn't know if you wanted a flag descriptive of what it does, or more generic to cover future issues with all-in-one. Either way works well for me. Many Thanks, Mike
Mike, you can test this build: https://jenkins.ovirt.org/job/ovirt-engine_standard-check-patch/7477/artifact/build-artifacts.el8.x86_64/ Note that this change is still in review, so things may change, but early testing can help us. Add a repo with this baseurl, and: dnf update engine-setup --accept-defaults After that imageio port (54322) should be open, so image transfer from SDK will work. To make image transfers work from the administration portal, you need to disable the proxy: engine-config -s ImageTransferProxyEnabled=false systemctl restart ovirt-engine Test that connecting to ovirt-imageio service works in the browser: Storage > Disks > Upload > Test Connection And try uploads and download disks. There is one limit, if you add another host, you will not be able to transfer images to this host from the administration portal. But if you have another host, you can remove engine host, add the other host, and enable back the proxy. With this you will have standard and fully supported installation.
(In reply to Nir Soffer from comment #25) > Mike, you can test this build: > > > https://jenkins.ovirt.org/job/ovirt-engine_standard-check-patch/7477/ > artifact/build-artifacts.el8.x86_64/ > > Note that this change is still in review, so things may change, but early > testing can help us. > > Add a repo with this baseurl, and: > > dnf update > engine-setup --accept-defaults > > After that imageio port (54322) should be open, so image transfer from SDK > will work. > > To make image transfers work from the administration portal, you need to > disable the proxy: > > engine-config -s ImageTransferProxyEnabled=false > systemctl restart ovirt-engine > > Test that connecting to ovirt-imageio service works in the browser: > > Storage > Disks > Upload > Test Connection > > And try uploads and download disks. > > There is one limit, if you add another host, you will not be able to > transfer images to this host from the administration portal. > > But if you have another host, you can remove engine host, add the > other host, and enable back the proxy. With this you will have standard > and fully supported installation. adding extra repo, and testing: [root@test-ovirt yum.repos.d]# engine-config -s ImageTransferProxyEnabled=false Error setting ImageTransferProxyEnabled's value. No such entry. must have something from another repo, so i've disabled the 4.2 repo and other testing ones, leaving just the new one; - nothing provides ovirt-provider-ovn >= 1.2.1 needed by ovirt-engine-4.4.2.3-0.0.master.20200826103437.gitde5c0a12d61.el8.noarch - nothing provides ansible-runner-service >= 1.0.4 needed by ovirt-engine-4.4.2.3-0.0.master.20200826103437.gitde5c0a12d61.el8.noarch - nothing provides apache-sshd >= 2.5.0 needed by ovirt-engine-4.4.2.3-0.0.master.20200826103437.gitde5c0a12d61.el8.noarch - nothing provides openstack-java-cinder-client >= 3.2.9 needed by ovirt-engine-4.4.2.3-0.0.master.20200826103437.gitde5c0a12d61.el8.noarch ... I've removed too much... added back 4.4 repo; I have; ovirt-engine-4.4.2.3-1.el8.noarch not; ovirt-engine-4.4.2.3-0.0.master.20200826103437.gitde5c0a12d61.el8.noarch dnf install ovirt-engine-4.4.2.3-0.0.master.20200826103437.gitde5c0a12d61.el8.noarch errors on db stuff, so engine-cleanup, engine-setup... [ INFO ] Checking for product updates... Setup needs to install or update the following packages: [erase] 0:ovirt-engine-4.4.2.3-0.0.master.20200826103437.gitde5c0a12d61.el8.noarch [install] 0:ovirt-engine-4.4.2.3-1.el8.noarch will be installed [erase] 0:ovirt-engine-backend-4.4.2.3-0.0.master.20200826103437.gitde5c0a12d61.el8.noarch [install] 0:ovirt-engine-backend-4.4.2.3-1.el8.noarch will be installed [erase] 0:ovirt-engine-dbscripts-4.4.2.3-0.0.master.20200826103437.gitde5c0a12d61.el8.noarch [install] 0:ovirt-engine-dbscripts-4.4.2.3-1.el8.noarch will be installed engine-setup --offline [root@test-ovirt yum.repos.d]# engine-config -s ImageTransferProxyEnabled=false [root@test-ovirt yum.repos.d]# Connection to ovirt-imageio service has failed. Ensure that ovirt-engine certificate is registered as a valid CA in the browser. (yep it's trusted CA)... checking imageio; [root@test-ovirt conf.d]# ls 50-engine.conf 60-vdsm.conf (might be messed up from all my removing/adding repos maybe) added back; jenkins.ovirt.org_job_vdsm_standard-check-patch_23134_artifact_build-artifacts.build-py3.el8.x86_64_.repo no updates pending; [root@test-ovirt yum.repos.d]# netstat -tlnp | grep 5432 tcp 0 0 0.0.0.0:5432 0.0.0.0:* LISTEN 45684/postmaster tcp6 0 0 :::54321 :::* LISTEN 8007/python3 tcp6 0 0 :::54322 :::* LISTEN 48183/platform-pyth tcp6 0 0 :::5432 :::* LISTEN 45684/postmaster testing the python still works: Creating disk... Disk ID: 382ac666-467f-432d-9f9e-253e191300b4 Creating image transfer... Transfer ID: 1d557f1b-e929-4db4-bd8b-a9417adc04f1 Transfer host name: ovirt-test Uploading image... [ 100.00% ] 1.60 GiB, 17.64 seconds, 92.91 MiB/s Finalizing image transfer... Upload completed successfully Clicking on "Download" button on this uploaded image does change the status to "Transferring", on a host where this is broken this just goes to "Finalizing failure" so there is progress, but something is not quite right yet. on this system after "Transferring" a timeout comes; Download was canceled by system. Reason: timeout due to transfer inactivity.
daemon log; 2020-08-26 21:50:54,717 INFO (Thread-24) [http] OPEN connection=24 client=local 2020-08-26 21:50:54,718 INFO (Thread-24) [tickets] [local] ADD ticket={'dirty': False, 'ops': ['read'], 'filename': 'CentOS-8.2.2004-x86_64-minimal.raw.raw', 'size': 1718616064, 'sparse': False, 'transfer_id': '856a43db-2c8b-4e3d-9469-f9925eddd771', 'uuid': '91c57ef4-ecf5-44af-be09-4bd6edc19c43', 'timeout': 300, 'url': 'file:///rhev/data-center/mnt/_var_local_ovirt__local__data/31dd2cd5-6fb6-4cb4-bb37-bbc670ba92d0/images/382ac666-467f-432d-9f9e-253e191300b4/f336e347-5458-4009-993a-4cd83a6ef03a'} 2020-08-26 21:50:54,718 INFO (Thread-24) [http] CLOSE connection=24 client=local [connection 1 ops, 0.000601 s] [dispatch 1 ops, 0.000219 s] 2020-08-26 21:50:55,621 INFO (Thread-25) [http] OPEN connection=25 client=local 2020-08-26 21:50:55,621 INFO (Thread-25) [http] CLOSE connection=25 client=local [connection 1 ops, 0.000570 s] [dispatch 1 ops, 0.000160 s] 2020-08-26 21:50:57,630 INFO (Thread-26) [http] OPEN connection=26 client=local 2020-08-26 21:50:57,630 INFO (Thread-26) [http] CLOSE connection=26 client=local [connection 1 ops, 0.000567 s] [dispatch 1 ops, 0.000148 s] 2020-08-26 21:51:01,639 INFO (Thread-27) [http] OPEN connection=27 client=local 2020-08-26 21:51:01,640 INFO (Thread-27) [http] CLOSE connection=27 client=local [connection 1 ops, 0.000550 s] [dispatch 1 ops, 0.000148 s]
firewall... all working yey [root@test-ovirt ovirt-imageio]# firewall-cmd --add-port=54322/tcp thankyou :)
also tested with vprotect, that's also working.
Mike, the issue with missing packages is fixed by using ovirt-release-master.rpm instead of ovirt-releae44.rpm. I don't know which local changes were on your test host, but doing a clean install or upgrading from older installation without modification should work without further changes. If you want to test clean install, you should install: dnf install dnf install http://resources.ovirt.org/pub/yum-repo/ovirt-release-master.rpm With this you will have access to latest packages that will be shipped in the next release. To install engine and vdsm with the fix, use these repos: https://jenkins.ovirt.org/job/vdsm_standard-check-patch/23194/artifact/build-artifacts.build-py3.el8.x86_64/ https://jenkins.ovirt.org/job/ovirt-engine_standard-check-patch/7477/artifact/build-artifacts.el8.x86_64/ With this setup "dnf install ovirt-enigne" for clean install or "dnf update" for exiting installation should work.
all wiped; dnf install http://resources.ovirt.org/pub/yum-repo/ovirt-release-master.rpm dnf config-manager --add-repo https://jenkins.ovirt.org/job/vdsm_standard-check-patch/23194/artifact/build-artifacts.build-py3.el8.x86_64/ dnf config-manager --add-repo https://jenkins.ovirt.org/job/ovirt-engine_standard-check-patch/7477/artifact/build-artifacts.el8.x86_64/ engine-setup [root@test-ovirt ~]# engine-config -s ImageTransferProxyEnabled=false Error setting ImageTransferProxyEnabled's value. No such entry. hmm... was from; 4.4.3.1-0.0.master.20200829170101.git804af35bfa6.el8 [root@test-ovirt ~]# dnf --showduplicates list ovirt-engine Last metadata expiration check: 0:11:23 ago on Sun 30 Aug 2020 22:38:26 BST. Installed Packages ovirt-engine.noarch 4.4.3.1-0.0.master.20200829170101.git804af35bfa6.el8 @ovirt-master-snapshot Available Packages ovirt-engine.noarch 4.4.2.3-0.0.master.20200826103437.gitde5c0a12d61.el8 jenkins.ovirt.org_job_ovirt-engine_standard-check-patch_7477_artifact_build-artifacts.el8.x86_64_ ovirt-engine.src 4.4.2.3-0.0.master.20200826103437.gitde5c0a12d61.el8 jenkins.ovirt.org_job_ovirt-engine_standard-check-patch_7477_artifact_build-artifacts.el8.x86_64_ ovirt-engine.noarch 4.4.3.1-0.0.master.20200826162550.git8203fad23f1.el8 ovirt-master-snapshot ovirt-engine.noarch 4.4.3.1-0.0.master.20200829170101.git804af35bfa6.el8 ovirt-master-snapshot guessing if i grab the 4.4.2 it will work again.
same again, but this time with; dnf install ovirt-engine-4.4.2.3-0.0.master.20200826103437.gitde5c0a12d61.el8 engine-config --accept-defaults --offline [root@test-ovirt ~]# engine-config -s ImageTransferProxyEnabled=false [root@test-ovirt ~]# and engine works but the upload is failing, checking vdsm packages it seems i have too newer ones... (not from the repo https://jenkins.ovirt.org/job/vdsm_standard-check-patch/23194/artifact/build-artifacts.build-py3.el8.x86_64/) [root@test-ovirt conf.d]# dnf --showduplicates list vdsm Last metadata expiration check: 1:04:00 ago on Sun 30 Aug 2020 23:07:57 BST. Installed Packages vdsm.x86_64 4.40.27-2.gita77a9377a.el8 @ovirt-master-snapshot Available Packages vdsm.ppc64le 4.40.27-1.git67f6b14f3.el8 ovirt-master-snapshot vdsm.x86_64 4.40.27-1.git67f6b14f3.el8 ovirt-master-snapshot vdsm.src 4.40.27-2.gita6fab5c6d.el8 jenkins.ovirt.org_job_vdsm_standard-check-patch_23194_artifact_build-artifacts.build-py3.el8.x86_64_ vdsm.x86_64 4.40.27-2.gita6fab5c6d.el8 jenkins.ovirt.org_job_vdsm_standard-check-patch_23194_artifact_build-artifacts.build-py3.el8.x86_64_ vdsm.ppc64le 4.40.27-2.gita77a9377a.el8 ovirt-master-snapshot vdsm.x86_64 4.40.27-2.gita77a9377a.el8 ovirt-master-snapshot dnf install vdsm-4.40.27-2.gita6fab5c6d.el8 all works.
summary; dnf install http://resources.ovirt.org/pub/yum-repo/ovirt-release-master.rpm dnf config-manager --add-repo https://jenkins.ovirt.org/job/vdsm_standard-check-patch/23194/artifact/build-artifacts.build-py3.el8.x86_64/ dnf config-manager --add-repo https://jenkins.ovirt.org/job/ovirt-engine_standard-check-patch/7477/artifact/build-artifacts.el8.x86_64/ dnf install ovirt-engine-4.4.2.3-0.0.master.20200826103437.gitde5c0a12d61.el8 dnf install vdsm-4.40.27-2.gita6fab5c6d.el8 engine-config --accept-defaults --offline engine-config -s ImageTransferProxyEnabled=false and it all works.
Yes, consuming changes from mater is tricky, it changes every day, so you need to install the specific version from the right repos. Thanks for testing this!
Nir, can we close this bug?
(In reply to Eyal Shenitzky from comment #35) > Nir, can we close this bug? After the patches are merged.
The vdsm side was merged, engine patches are ready since last week. So this can be included in 4.4.3.
The fix is available in ovirt-engine-4.4.3.2. Can be tested with this build: https://jenkins.ovirt.org/job/ovirt-engine_standard-check-patch/7835/ Using latest vdsm (vdsm-4.40.28).
(In reply to Nir Soffer from comment #8) > (In reply to Michael Jones from comment #7) > > example vms; > > > > - haxproxy-01 > > - ovirtmgmt = 141.0.0.32 > > - vlanl1 = 10.0.0.2 > > - haxproxy-02 > > - ovirtmgmt = 141.0.0.33 > > - vlanl1 = 10.0.0.3 > > - vpn-01 > > - ovirtmgmt = 141.0.0.34 > > - vlanl1 = 10.0.0.4 > > - bastion-01 > > - ovirtmgmt = 141.0.0.35 > > - vlanl1 = 10.0.0.5 > > - zabbix-proxy-01 > > - ovirtmgmt = 141.0.0.36 > > - vlanl1 = 10.0.0.6 > > - db-01 > > - vlanl1 = 10.0.0.7 > > - web-01 > > - vlanl1 = 10.0.0.8 > > - squid-01 > > - vlanl1 = 10.0.0.9 > > So ideally, you want your hosted engine VM to use something like: > > - hosted-engine > - ovirtmgmt = 141.0.0.31 > - vlanl1 = 10.0.0.1 > > Dominic, do we a have a way to configure hosted engine networking > so it adapt better to such environment? Tracked in bug 1887500.
This bugzilla is included in oVirt 4.4.3 release, published on November 10th 2020. Since the problem described in this bug report should be resolved in oVirt 4.4.3 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.
Dropping needinfo on me, assuming that being this bug fixed you don't need my input anymore.