Run Once install -> reboot loop

Hello all, I’m running overt 3.6.0 on Centos 7.[1] I’ve been working on getting Ovirt to slot in to our environment, and almost have a setup that works. I can now build isos on demand for automated installs (I’m working around some local networking choices without modifying them for now, which is why this isn’t a PXE boot) and create my guests, pointing them to the iso form which to install via Run Once. This all works. The problem is that after the install, the guest reboots, but (best I can tell) Ovirt doesn’t detect it, the iso is still mounted, and the install happens all over again. Rinse, repeat. Has anyone seen this? Or better, does anyone know how to fix this? Thanks, -j [1] # yum list installed |grep ovirt ebay-cors-filter.noarch 1.0.1-0.1.ovirt.el7 @ovirt-3.6 gperftools-libs.x86_64 2.4-7.el7 @ovirt-3.6 ipxe-bootimgs.noarch 20130517-7.gitc4bce43.el7 @ovirt-3.6 ipxe-roms.noarch 20130517-7.gitc4bce43.el7 @ovirt-3.6 ipxe-roms-qemu.noarch 20130517-7.gitc4bce43.el7 @ovirt-3.6 jasperreports-server.noarch 6.0.1-1.el7 @ovirt-3.6 libcacard-ev.x86_64 10:2.3.0-29.1.el7 @ovirt-3.6 libgovirt.x86_64 0.3.1-3.el7 @base otopi.noarch 1.4.0-1.el7.centos @ovirt-3.6 otopi-java.noarch 1.4.0-1.el7.centos @ovirt-3.6 ovirt-engine.noarch 3.6.0.3-1.el7.centos @ovirt-3.6 ovirt-engine-backend.noarch 3.6.0.3-1.el7.centos @ovirt-3.6 ovirt-engine-cli.noarch 3.6.0.1-1.el7.centos @ovirt-3.6 ovirt-engine-dbscripts.noarch 3.6.0.3-1.el7.centos @ovirt-3.6 ovirt-engine-extension-aaa-jdbc.noarch 1.0.1-1.el7 @ovirt-3.6 ovirt-engine-extension-aaa-ldap.noarch 1.1.2-1.el7.centos @ovirt-3.6 ovirt-engine-extension-aaa-ldap-setup.noarch 1.1.2-1.el7.centos @ovirt-3.6 ovirt-engine-extensions-api-impl.noarch 3.6.0.3-1.el7.centos @ovirt-3.6 ovirt-engine-jboss-as.x86_64 7.1.1-1.el7.centos @ovirt-3.6 ovirt-engine-lib.noarch 3.6.0.3-1.el7.centos @ovirt-3.6 ovirt-engine-restapi.noarch 3.6.0.3-1.el7.centos @ovirt-3.6 ovirt-engine-sdk-python.noarch 3.6.0.3-1.el7.centos @ovirt-3.6 ovirt-engine-setup.noarch 3.6.0.3-1.el7.centos @ovirt-3.6 ovirt-engine-setup-base.noarch 3.6.0.3-1.el7.centos @ovirt-3.6 ovirt-engine-setup-plugin-ovirt-engine.noarch 3.6.0.3-1.el7.centos @ovirt-3.6 ovirt-engine-setup-plugin-ovirt-engine-common.noarch 3.6.0.3-1.el7.centos @ovirt-3.6 ovirt-engine-setup-plugin-vmconsole-proxy-helper.noarch 3.6.0.3-1.el7.centos @ovirt-3.6 ovirt-engine-setup-plugin-websocket-proxy.noarch 3.6.0.3-1.el7.centos @ovirt-3.6 ovirt-engine-tools.noarch 3.6.0.3-1.el7.centos @ovirt-3.6 ovirt-engine-userportal.noarch 3.6.0.3-1.el7.centos @ovirt-3.6 ovirt-engine-vmconsole-proxy-helper.noarch 3.6.0.3-1.el7.centos @ovirt-3.6 ovirt-engine-webadmin-portal.noarch 3.6.0.3-1.el7.centos @ovirt-3.6 ovirt-engine-websocket-proxy.noarch 3.6.0.3-1.el7.centos @ovirt-3.6 ovirt-engine-wildfly.x86_64 8.2.0-1.el7 @ovirt-3.6 ovirt-engine-wildfly-overlay.noarch 001-2.el7 @ovirt-3.6 ovirt-host-deploy.noarch 1.4.0-1.el7.centos @ovirt-3.6 ovirt-host-deploy-java.noarch 1.4.0-1.el7.centos @ovirt-3.6 ovirt-host-deploy-offline.x86_64 1.4.0-1.el7.centos @ovirt-3.6 ovirt-hosted-engine-ha.noarch 1.3.2.1-1.el7.centos @ovirt-3.6 ovirt-hosted-engine-setup.noarch 1.3.0-1.el7.centos @ovirt-3.6 ovirt-image-uploader.noarch 3.6.0-1.el7.centos @ovirt-3.6 ovirt-iso-uploader.noarch 3.6.0-1.el7.centos @ovirt-3.6 ovirt-setup-lib.noarch 1.0.0-1.el7.centos @ovirt-3.6 ovirt-vmconsole.noarch 1.0.0-1.el7.centos @ovirt-3.6 ovirt-vmconsole-host.noarch 1.0.0-1.el7.centos @ovirt-3.6 ovirt-vmconsole-proxy.noarch 1.0.0-1.el7.centos @ovirt-3.6 patternfly1.noarch 1.3.0-1.el7.centos @ovirt-3.6-patternfly1-noarch-epel python-gluster.noarch 3.7.6-1.el7 @ovirt-3.6-glusterfs-noarch-epel qemu-img-ev.x86_64 10:2.3.0-29.1.el7 @ovirt-3.6 qemu-kvm-common-ev.x86_64 10:2.3.0-29.1.el7 @ovirt-3.6 qemu-kvm-ev.x86_64 10:2.3.0-29.1.el7 @ovirt-3.6 qemu-kvm-tools-ev.x86_64 10:2.3.0-29.1.el7 @ovirt-3.6 seabios-bin.noarch 1.7.5-11.el7 @ovirt-3.6 seavgabios-bin.noarch 1.7.5-11.el7 @ovirt-3.6 spice-qxl.noarch 0.1-21.1 @ovirt-3.6 unboundid-ldapsdk.noarch 3.0.0-1.el7 @ovirt-3.6 vdsm.noarch 4.17.10.1-0.el7.centos @ovirt-3.6 vdsm-cli.noarch 4.17.10.1-0.el7.centos @ovirt-3.6 vdsm-gluster.noarch 4.17.10.1-0.el7.centos @ovirt-3.6 vdsm-hook-fileinject.noarch 4.17.10.1-0.el7.centos @ovirt-3.6 vdsm-infra.noarch 4.17.10.1-0.el7.centos @ovirt-3.6 vdsm-jsonrpc.noarch 4.17.10.1-0.el7.centos @ovirt-3.6 vdsm-jsonrpc-java.noarch 1.1.5-1.el7.centos @ovirt-3.6 vdsm-python.noarch 4.17.10.1-0.el7.centos @ovirt-3.6 vdsm-xmlrpc.noarch 4.17.10.1-0.el7.centos @ovirt-3.6 vdsm-yajsonrpc.noarch 4.17.10.1-0.el7.centos @ovirt-3.6

Hello all,
I=E2=80=99m running overt 3.6.0 on Centos 7.[1]
I=E2=80=99ve been working on getting Ovirt to slot in to our environmen= t, and almost have a setup that works. I can now build isos on demand for= automated installs (I=E2=80=99m working around some local networking cho= ices without modifying them for now, which is why this isn=E2=80=99t a PX= E boot) and create my guests, pointing them to the iso form which to inst= all via Run Once. This all works.
The problem is that after the install, the guest reboots, but (best I c= an tell) Ovirt doesn=E2=80=99t detect it, the iso is still mounted, and t= he install happens all over again. Rinse, repeat.
Has anyone seen this? Or better, does anyone know how to fix this?
Thanks,
-j
[1] # yum list installed |grep ovirt ebay-cors-filter.noarch 1.0.1-0.1.ovirt.el7 @= ovirt-3.6 gperftools-libs.x86_64 2.4-7.el7 @= ovirt-3.6 ipxe-bootimgs.noarch 20130517-7.gitc4bce43.el7 @= ovirt-3.6 ipxe-roms.noarch 20130517-7.gitc4bce43.el7 @= ovirt-3.6 ipxe-roms-qemu.noarch 20130517-7.gitc4bce43.el7 @= ovirt-3.6 jasperreports-server.noarch 6.0.1-1.el7 @= ovirt-3.6 libcacard-ev.x86_64 10:2.3.0-29.1.el7 @= ovirt-3.6 libgovirt.x86_64 0.3.1-3.el7 @=
This is a cryptographically signed message in MIME format. --------------ms040003090303030404010901 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Jamie, That reason for this is, that the iso will be mounted as long as you're=20 in run once mode. You can fix this by powering off your vm after the installation and run=20 it again in "normal" mode. As you don't want to run the vm in run once=20 mode forever, you have to shut it down anyway. Regards, Ren=C3=A9 On 02/19/2016 01:19 AM, Jamie Lawrence wrote: base
otopi.noarch 1.4.0-1.el7.centos @= ovirt-3.6 otopi-java.noarch 1.4.0-1.el7.centos @= ovirt-3.6 ovirt-engine.noarch 3.6.0.3-1.el7.centos @= ovirt-3.6 ovirt-engine-backend.noarch 3.6.0.3-1.el7.centos @= ovirt-3.6 ovirt-engine-cli.noarch 3.6.0.1-1.el7.centos @= ovirt-3.6 ovirt-engine-dbscripts.noarch 3.6.0.3-1.el7.centos @= ovirt-3.6 ovirt-engine-extension-aaa-jdbc.noarch 1.0.1-1.el7 @= ovirt-3.6 ovirt-engine-extension-aaa-ldap.noarch 1.1.2-1.el7.centos @= ovirt-3.6 ovirt-engine-extension-aaa-ldap-setup.noarch 1.1.2-1.el7.centos = @ovirt-3.6 ovirt-engine-extensions-api-impl.noarch 3.6.0.3-1.el7.centos = @ovirt-3.6 ovirt-engine-jboss-as.x86_64 7.1.1-1.el7.centos @= ovirt-3.6 ovirt-engine-lib.noarch 3.6.0.3-1.el7.centos @= ovirt-3.6 ovirt-engine-restapi.noarch 3.6.0.3-1.el7.centos @= ovirt-3.6 ovirt-engine-sdk-python.noarch 3.6.0.3-1.el7.centos @= ovirt-3.6 ovirt-engine-setup.noarch 3.6.0.3-1.el7.centos @= ovirt-3.6 ovirt-engine-setup-base.noarch 3.6.0.3-1.el7.centos @= ovirt-3.6 ovirt-engine-setup-plugin-ovirt-engine.noarch 3.6.0.3-1.el7.centos = @ovirt-3.6 ovirt-engine-setup-plugin-ovirt-engine-common.noarch 3.6.0.3-1.el7.centos = @ovirt-3.6 ovirt-engine-setup-plugin-vmconsole-proxy-helper.noarch 3.6.0.3-1.el7.centos = @ovirt-3.6 ovirt-engine-setup-plugin-websocket-proxy.noarch 3.6.0.3-1.el7.centos = @ovirt-3.6 ovirt-engine-tools.noarch 3.6.0.3-1.el7.centos @= ovirt-3.6 ovirt-engine-userportal.noarch 3.6.0.3-1.el7.centos @= ovirt-3.6 ovirt-engine-vmconsole-proxy-helper.noarch 3.6.0.3-1.el7.centos = @ovirt-3.6 ovirt-engine-webadmin-portal.noarch 3.6.0.3-1.el7.centos @= ovirt-3.6 ovirt-engine-websocket-proxy.noarch 3.6.0.3-1.el7.centos @= ovirt-3.6 ovirt-engine-wildfly.x86_64 8.2.0-1.el7 @= ovirt-3.6 ovirt-engine-wildfly-overlay.noarch 001-2.el7 @= ovirt-3.6 ovirt-host-deploy.noarch 1.4.0-1.el7.centos @= ovirt-3.6 ovirt-host-deploy-java.noarch 1.4.0-1.el7.centos @= ovirt-3.6 ovirt-host-deploy-offline.x86_64 1.4.0-1.el7.centos @= ovirt-3.6 ovirt-hosted-engine-ha.noarch 1.3.2.1-1.el7.centos @= ovirt-3.6 ovirt-hosted-engine-setup.noarch 1.3.0-1.el7.centos @= ovirt-3.6 ovirt-image-uploader.noarch 3.6.0-1.el7.centos @= ovirt-3.6 ovirt-iso-uploader.noarch 3.6.0-1.el7.centos @= ovirt-3.6 ovirt-setup-lib.noarch 1.0.0-1.el7.centos @= ovirt-3.6 ovirt-vmconsole.noarch 1.0.0-1.el7.centos @= ovirt-3.6 ovirt-vmconsole-host.noarch 1.0.0-1.el7.centos @= ovirt-3.6 ovirt-vmconsole-proxy.noarch 1.0.0-1.el7.centos @= ovirt-3.6 patternfly1.noarch 1.3.0-1.el7.centos @= ovirt-3.6-patternfly1-noarch-epel python-gluster.noarch 3.7.6-1.el7 @= ovirt-3.6-glusterfs-noarch-epel qemu-img-ev.x86_64 10:2.3.0-29.1.el7 @= ovirt-3.6 qemu-kvm-common-ev.x86_64 10:2.3.0-29.1.el7 @= ovirt-3.6 qemu-kvm-ev.x86_64 10:2.3.0-29.1.el7 @= ovirt-3.6 qemu-kvm-tools-ev.x86_64 10:2.3.0-29.1.el7 @= ovirt-3.6 seabios-bin.noarch 1.7.5-11.el7 @= ovirt-3.6 seavgabios-bin.noarch 1.7.5-11.el7 @= ovirt-3.6 spice-qxl.noarch 0.1-21.1 @= ovirt-3.6 unboundid-ldapsdk.noarch 3.0.0-1.el7 @= ovirt-3.6 vdsm.noarch 4.17.10.1-0.el7.centos @= ovirt-3.6 vdsm-cli.noarch 4.17.10.1-0.el7.centos @= ovirt-3.6 vdsm-gluster.noarch 4.17.10.1-0.el7.centos @= ovirt-3.6 vdsm-hook-fileinject.noarch 4.17.10.1-0.el7.centos @= ovirt-3.6 vdsm-infra.noarch 4.17.10.1-0.el7.centos @= ovirt-3.6 vdsm-jsonrpc.noarch 4.17.10.1-0.el7.centos @= ovirt-3.6 vdsm-jsonrpc-java.noarch 1.1.5-1.el7.centos @= ovirt-3.6 vdsm-python.noarch 4.17.10.1-0.el7.centos @= ovirt-3.6 vdsm-xmlrpc.noarch 4.17.10.1-0.el7.centos @= ovirt-3.6 vdsm-yajsonrpc.noarch 4.17.10.1-0.el7.centos @= ovirt-3.6 _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
--------------ms040003090303030404010901 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC C/kwggXZMIIDwaADAgECAgcWZ1TjwnBRMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYTAklM MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTAeFw0wNzEwMTQyMTAxNTVaFw0yMjEwMTQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPM zi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0t svVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpb fuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKk DiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggFMMIIBSDASBgNV HRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ ljVO8tS4UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwaQYIKwYBBQUHAQEE XTBbMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwMAYIKwYBBQUH MAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAyBgNVHR8EKzApMCeg JaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwQwYDVR0gBDwwOjA4BgRV HSAAMDAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw DQYJKoZIhvcNAQELBQADggIBAHQKh/oy3viYt+qvMyyQhqWiIb9kP1KRhqWHGFMID7OAbofo UgDKVUJ7UsiBnPmleGa2pUwvf2B67qPqc2e9Ge9/kBvJtV8rSES3z+/KVrx6UwlX8VyWnkRN GV0PLvCD+34cIOqhF3Tjmt4jpfYSTjkXcOpa7F4RGZbmu0+j1HO46XAYypOisgXD3XWecqqX zEMimZVrF3DlsMYTYMmFtzRYAeaDh2BxczJlV4HeBs8gw7d4USUoDWHckMR4QK0zLVVmQ1F6 6irltWWsJ9CFKVyz9ZTBspi3FDJCT93XfR4OrOUHB+I5P18lTWHDD1p/9dX7Zh8bdwlOSKdE fsKvzaxVZbKkuXXo7FMG2v6LQ2Jmv6Gc4jJ8jSyjatpy86llJJT2R3tJFPRGlfPcZ1ge3Ad/ qXDZKPI4pN8D5so89WUPAJ7z9ZeDqSFdGTWaynTZaCRPAIC/e35VtTyNuIam+n6nuaZFgccp ACw51vkgFUij6AKxByq7CNgB1Zn/FRX15qZA9bu2ZI8QTHJT/8zM3njXAgV6AsFOf682t14q sYSBz0jpef8kU0q15uV9oZSGjy1ph/0ysQD+342MIh3PQlKp62dj3eWWP3MBF7gtQTbERX1P mMzfTIsyMbjq+pv9P4iKROw0+8MNp0PUNtilMG2fKLBRoczLiZ7hMLjyedCXMIIGGDCCBQCg AwIBAgIDDmx8MA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwHhcNMTUwNjE4MDQwNTE2WhcNMTYwNjE4MDAxODU0WjA4MRcwFQYDVQQDDA5ya29j aEByay1pdC5hdDEdMBsGCSqGSIb3DQEJARYOcmtvY2hAcmstaXQuYXQwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC+9dGpO90CAw648QlL90EX3nwpK8n4R1HloyhGFPo2uYmt G4GnsVgr1B0luOwvlbMr8jqcX4CvlCxexKrRhP8qOrrZJfgRAkkye18MUJUE5YFqi/xXZuEp EzzS6pF4lYn07MXTQFaWg6tDV9pbTHSeJTJ+1e1qqlAT06bNMJ5qKteB58gDjf8CoJX8d8GX gewkhsjx37TcJghDf+cNtahwbE69qmMPVYA4uM4E2x/4RuImoZe6Al51GYdqu0VhntBH34rl 8GK2P5U6ysmofvKs6uP+CNQEsmCjkzgAXbjCjjg3HY2G1hpYZu9pk0MAsv+e5WPJdcM/gzkF HoygAwb9AgMBAAGjggLUMIIC0DAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAU BggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMgv5KUDcED1P2lBst9Bm4mL+fFwMB8G A1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMBkGA1UdEQQSMBCBDnJrb2NoQHJrLWl0 LmF0MIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEW Imh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcW IFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmlj YXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVx dWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9y IHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFy dHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6 Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2 aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0 MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOC AQEAhzctU3ikQEX6m/3trtNit5+BznSRQvaWhymyjXIe6yhLPbKvXrJMj1hiFHqv7hi4I/hO iy4w3TGMaKf2hNONkrlQ1OzYayv71BLhrrXD3zKYQVWf/Rw4Mhqu7K/PXz/hx1kQrMZ/aQS/ FyEG/ddX8d59YPGMdeWpdwuHEuwoW33v/PYXcKH4nCdpfq8AZZJGzKz/k2/jqUaHu0IEV77S M+Ul2JzON7j6iV8xMzojYgv4mzSJgVVsP48Nym/R2/MZMu0Fk80g9qqZUIZMS/Nr6rdpl5Fo qRqwioIm0xvZiDrRlcLniTu5GXBC7lmz3xEv66s4WZRDh3/WP4xdi8JF9TGCApowggKWAgEB MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAw5sfDANBglghkgBZQME AgEFAKCB1zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAy MTkwNzQ1MDZaMC8GCSqGSIb3DQEJBDEiBCBc5J39i/D+TXtY9UTPlTjrcSPlrWlawdUV6RUD Vy91PzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMA0GCSqGSIb3DQEBAQUABIIBALuXnWOfy+7t+rZj+js8ZHLFQsdkLgBd/gul59pe YmeCWSwfeZOHyIVRiKgFS6QPL+8YLP53iFQs9W7fn+26arckvhZoQbFjZYPR8I7XO6RXnIrY qZ3Yddr/h7Dy9QbwmAOhnclziriy3wLRP31hOkzJYo1wm7ZLvFcw4s4bBjJj3+hXudkF955e lkNDeF+fV/AKchVkMgx1qinBCONArcFGmcUdfkqDZzc69B3tcIJ8Qvt9TnYJuC49S3B1CWnB /CNEL5boaQUMlL7P1Usefsf0Vg39BCYfiFjhnOr17rb1ZJ9J75G7gB4lBom1uS36yn0X7uEs 6tV4d7fnzp1LpsgAAAAAAAA= --------------ms040003090303030404010901--

On Feb 18, 2016, at 11:45 PM, René Koch <rkoch@rk-it.at> wrote:
Hi Jamie,
That reason for this is, that the iso will be mounted as long as you're in run once mode.
You can fix this by powering off your vm after the installation and run it again in "normal" mode. As you don't want to run the vm in run once mode forever, you have to shut it down anyway.
But it seems that this has worked for me in the past, when I was creating these through the GUI. In other words, after the OS installer reboots, it would correctly reboot in “normal” mode. Am I hallucinating that? In any case, I’m sure there’s a power-off API method, but I’m not sure how to reliably detect when to call it. I could do something hacky like call my own API endpoint as the last action of the installer somehow (I know how to with Debian, and I’m sure the RH family can do it as well), but that seems fragile. Maybe hack the installer to power power off instead of reboot, and detect that? I hate the idea of having to fork/maintain my own installer patches... What do other people do for automating this situation? -j

On Friday, February 19, 2016 10:23:02 AM Jamie Lawrence wrote:
On Feb 18, 2016, at 11:45 PM, René Koch <rkoch@rk-it.at> wrote:
Hi Jamie,
That reason for this is, that the iso will be mounted as long as you're in run once mode.
You can fix this by powering off your vm after the installation and run it again in "normal" mode. As you don't want to run the vm in run once mode forever, you have to shut it down anyway. But it seems that this has worked for me in the past, when I was creating these through the GUI. In other words, after the OS installer reboots, it would correctly reboot in “normal” mode. Am I hallucinating that?
It works in the UI because the HD is the first boot device and the CDROM is lower in the order. When you boot, it sees the HD doesn't have a boot record and continues to the next one. Once installed the reboot will have given the HD a boot record and it will start from there. Make sure that in your case the CDROM is NOT the first device and I think you should be alright.
In any case, I’m sure there’s a power-off API method, but I’m not sure how to reliably detect when to call it. I could do something hacky like call my own API endpoint as the last action of the installer somehow (I know how to with Debian, and I’m sure the RH family can do it as well), but that seems fragile.
Maybe hack the installer to power power off instead of reboot, and detect that? I hate the idea of having to fork/maintain my own installer patches...
What do other people do for automating this situation?
-j _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
participants (3)
-
Alexander Wels
-
Jamie Lawrence
-
René Koch