Re: [Users] [ovirt-test-day-2] Possible bug while testing vm-init-persistent feature
- Original Message - From: Shahar Havivi shah...@redhat.com To: Vojtech Szocs vsz...@redhat.com Cc: users users@ovirt.org, Einav Cohen eco...@redhat.com Sent: Thursday, February 13, 2014 7:28:11 PM Subject: Re: [ovirt-test-day-2] Possible bug while testing vm-init-persistent feature On 13.02.14 12:35, Vojtech Szocs wrote: Thank you, Shahar. I suspected that NPE would be due to empty domain :P (I forgot to mention that in my email) However, for me, even Run Once without Sysprep didn't work, I got an exception that seems to come from VDS broker backend component. Now I realize that I might have been using bad libvirt version. On my Fedora 19 host I have: # rpm -qa libvirt* libvirt-daemon-driver-qemu-1.1.3.2-1.fc19.x86_64 libvirt-daemon-driver-nodedev-1.1.3.2-1.fc19.x86_64 libvirt-daemon-driver-storage-1.1.3.2-1.fc19.x86_64 libvirt-daemon-kvm-1.1.3.2-1.fc19.x86_64 libvirt-client-1.1.3.2-1.fc19.x86_64 libvirt-daemon-driver-network-1.1.3.2-1.fc19.x86_64 libvirt-daemon-driver-nwfilter-1.1.3.2-1.fc19.x86_64 libvirt-daemon-driver-interface-1.1.3.2-1.fc19.x86_64 libvirt-lock-sanlock-1.1.3.2-1.fc19.x86_64 libvirt-python-1.1.3.2-1.fc19.x86_64 libvirt-daemon-1.1.3.2-1.fc19.x86_64 libvirt-daemon-driver-secret-1.1.3.2-1.fc19.x86_64 libvirt-daemon-config-nwfilter-1.1.3.2-1.fc19.x86_64 libvirt-daemon-qemu-1.1.3.2-1.fc19.x86_64 I'll try to test Sysprep some more in future. Thanks, Vojtech Please note that I push few hours ago a 7 patches related to VmInit that fix some bugs including the one that you reported. Thanks Shahar! Thank you for your help, Shahar. - Original Message - From: Shahar Havivi shah...@redhat.com To: Vojtech Szocs vsz...@redhat.com Cc: users users@ovirt.org, Einav Cohen eco...@redhat.com Sent: Wednesday, February 12, 2014 1:17:08 PM Subject: Re: [ovirt-test-day-2] Possible bug while testing vm-init-persistent feature Thanks Vojtech, There is a bug (and a fix) here: https://bugzilla.redhat.com/1063883 Shahar. On 11.02.14 18:20, Vojtech Szocs wrote: Hello, I think I found a possible bug while testing Shahar's vm-init-persistent feature, not sure if related to vm-init-persistent or Engine vs. vdsm RPC issue. Followed steps in [1,2] to install ovirt-engine on F19, then used it to setup another F19 node as host via WebAdmin GUI. [1] http://www.ovirt.org/OVirt_3.4_TestDay#Installation_notes [2] http://www.ovirt.org/OVirt_3.4.0_release_notes#SECOND_BETA_RELEASE On engine: # rpm -qa ovirt-engine* ovirt-engine-setup-base-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-webadmin-portal-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-websocket-proxy-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-dbscripts-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-setup-plugin-websocket-proxy-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-setup-plugin-ovirt-engine-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-tools-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-cli-3.4.0.3-1.fc19.noarch ovirt-engine-setup-plugin-ovirt-engine-common-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-setup-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-backend-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-setup-plugin-allinone-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-sdk-python-3.4.0.3-1.fc19.noarch ovirt-engine-restapi-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-lib-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-userportal-3.4.0-0.7.beta2.fc19.noarch On host: # rpm -qa vdsm* vdsm-python-zombiereaper-4.14.2-0.fc19.noarch vdsm-xmlrpc-4.14.2-0.fc19.noarch vdsm-4.14.2-0.fc19.x86_64 vdsm-cli-4.14.2-0.fc19.noarch vdsm-python-4.14.2-0.fc19.x86_64 Using default 3.4 DataCenter/Cluster, created WinXP VM via WebAdmin GUI *without* Sysprep enabled. Trying to Run Once with WinXP ISO attached, I get: Error while executing action Run VM once: Network error during communication with the Host. Relevant log part attached as XmlRpcExtensionException-part.log Command org.ovirt.engine.core.bll.RunVmOnceCommand throw Vdc Bll exception. With error message VdcBLLException: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException: org.apache.xmlrpc.common.XmlRpcExtensionException: Null values aren't supported, if isEnabledForExtensions() == false (Failed with error VDS_NETWORK_ERROR and code 5022) Second try, created WinXP VM via WebAdmin GUI *with* Sysprep enabled. On Initial Run tab, checked Configure Time Zone and providing VM OS specific timezone override, whose value is different than in System tab's (general) Time Zone field. Trying to Run Once with Sysprep enabled WinXP ISO attached, I get: Cannot run VM. VM is running. Relevant
Re: [Users] [ovirt-test-day-2] Possible bug while testing vm-init-persistent feature
Thank you, Shahar. I suspected that NPE would be due to empty domain :P (I forgot to mention that in my email) However, for me, even Run Once without Sysprep didn't work, I got an exception that seems to come from VDS broker backend component. Now I realize that I might have been using bad libvirt version. On my Fedora 19 host I have: # rpm -qa libvirt* libvirt-daemon-driver-qemu-1.1.3.2-1.fc19.x86_64 libvirt-daemon-driver-nodedev-1.1.3.2-1.fc19.x86_64 libvirt-daemon-driver-storage-1.1.3.2-1.fc19.x86_64 libvirt-daemon-kvm-1.1.3.2-1.fc19.x86_64 libvirt-client-1.1.3.2-1.fc19.x86_64 libvirt-daemon-driver-network-1.1.3.2-1.fc19.x86_64 libvirt-daemon-driver-nwfilter-1.1.3.2-1.fc19.x86_64 libvirt-daemon-driver-interface-1.1.3.2-1.fc19.x86_64 libvirt-lock-sanlock-1.1.3.2-1.fc19.x86_64 libvirt-python-1.1.3.2-1.fc19.x86_64 libvirt-daemon-1.1.3.2-1.fc19.x86_64 libvirt-daemon-driver-secret-1.1.3.2-1.fc19.x86_64 libvirt-daemon-config-nwfilter-1.1.3.2-1.fc19.x86_64 libvirt-daemon-qemu-1.1.3.2-1.fc19.x86_64 I'll try to test Sysprep some more in future. Thanks, Vojtech - Original Message - From: Shahar Havivi shah...@redhat.com To: Vojtech Szocs vsz...@redhat.com Cc: users users@ovirt.org, Einav Cohen eco...@redhat.com Sent: Wednesday, February 12, 2014 1:17:08 PM Subject: Re: [ovirt-test-day-2] Possible bug while testing vm-init-persistent feature Thanks Vojtech, There is a bug (and a fix) here: https://bugzilla.redhat.com/1063883 Shahar. On 11.02.14 18:20, Vojtech Szocs wrote: Hello, I think I found a possible bug while testing Shahar's vm-init-persistent feature, not sure if related to vm-init-persistent or Engine vs. vdsm RPC issue. Followed steps in [1,2] to install ovirt-engine on F19, then used it to setup another F19 node as host via WebAdmin GUI. [1] http://www.ovirt.org/OVirt_3.4_TestDay#Installation_notes [2] http://www.ovirt.org/OVirt_3.4.0_release_notes#SECOND_BETA_RELEASE On engine: # rpm -qa ovirt-engine* ovirt-engine-setup-base-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-webadmin-portal-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-websocket-proxy-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-dbscripts-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-setup-plugin-websocket-proxy-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-setup-plugin-ovirt-engine-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-tools-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-cli-3.4.0.3-1.fc19.noarch ovirt-engine-setup-plugin-ovirt-engine-common-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-setup-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-backend-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-setup-plugin-allinone-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-sdk-python-3.4.0.3-1.fc19.noarch ovirt-engine-restapi-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-lib-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-userportal-3.4.0-0.7.beta2.fc19.noarch On host: # rpm -qa vdsm* vdsm-python-zombiereaper-4.14.2-0.fc19.noarch vdsm-xmlrpc-4.14.2-0.fc19.noarch vdsm-4.14.2-0.fc19.x86_64 vdsm-cli-4.14.2-0.fc19.noarch vdsm-python-4.14.2-0.fc19.x86_64 Using default 3.4 DataCenter/Cluster, created WinXP VM via WebAdmin GUI *without* Sysprep enabled. Trying to Run Once with WinXP ISO attached, I get: Error while executing action Run VM once: Network error during communication with the Host. Relevant log part attached as XmlRpcExtensionException-part.log Command org.ovirt.engine.core.bll.RunVmOnceCommand throw Vdc Bll exception. With error message VdcBLLException: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException: org.apache.xmlrpc.common.XmlRpcExtensionException: Null values aren't supported, if isEnabledForExtensions() == false (Failed with error VDS_NETWORK_ERROR and code 5022) Second try, created WinXP VM via WebAdmin GUI *with* Sysprep enabled. On Initial Run tab, checked Configure Time Zone and providing VM OS specific timezone override, whose value is different than in System tab's (general) Time Zone field. Trying to Run Once with Sysprep enabled WinXP ISO attached, I get: Cannot run VM. VM is running. Relevant log part attached as VmIsRunning-part.log Command CreateVmVDSCommand(HostName = f19-host-34beta2, HostId = 02a21a1a-47d6-4d90-8059-a69f0724feff, vmId=cd3722b0-3139-4d23-8ad4-f01875e85a63, vm=VM [winxp-foo]) execution failed. Exception: RuntimeException: java.lang.NullPointerException .. CanDoAction of action RunVmOnce failed. Reasons:VAR__ACTION__RUN,VAR__TYPE__VM,VAR__ACTION__RUN,VAR__TYPE__VM,ACTION_TYPE_FAILED_VM_IS_RUNNING Checking if VM is really running on host (it's not): # vdsClient -s 0 list table (no results) Full engine.log + vdsm.log attached. I can provide WebAdmin GUI link and more details if needed. It's possible that there's something wrong with my engine/host, but I'm clueless as
Re: [Users] [ovirt-test-day-2] Possible bug while testing vm-init-persistent feature
On 13.02.14 12:35, Vojtech Szocs wrote: Thank you, Shahar. I suspected that NPE would be due to empty domain :P (I forgot to mention that in my email) However, for me, even Run Once without Sysprep didn't work, I got an exception that seems to come from VDS broker backend component. Now I realize that I might have been using bad libvirt version. On my Fedora 19 host I have: # rpm -qa libvirt* libvirt-daemon-driver-qemu-1.1.3.2-1.fc19.x86_64 libvirt-daemon-driver-nodedev-1.1.3.2-1.fc19.x86_64 libvirt-daemon-driver-storage-1.1.3.2-1.fc19.x86_64 libvirt-daemon-kvm-1.1.3.2-1.fc19.x86_64 libvirt-client-1.1.3.2-1.fc19.x86_64 libvirt-daemon-driver-network-1.1.3.2-1.fc19.x86_64 libvirt-daemon-driver-nwfilter-1.1.3.2-1.fc19.x86_64 libvirt-daemon-driver-interface-1.1.3.2-1.fc19.x86_64 libvirt-lock-sanlock-1.1.3.2-1.fc19.x86_64 libvirt-python-1.1.3.2-1.fc19.x86_64 libvirt-daemon-1.1.3.2-1.fc19.x86_64 libvirt-daemon-driver-secret-1.1.3.2-1.fc19.x86_64 libvirt-daemon-config-nwfilter-1.1.3.2-1.fc19.x86_64 libvirt-daemon-qemu-1.1.3.2-1.fc19.x86_64 I'll try to test Sysprep some more in future. Thanks, Vojtech Please note that I push few hours ago a 7 patches related to VmInit that fix some bugs including the one that you reported. Thank you for your help, Shahar. - Original Message - From: Shahar Havivi shah...@redhat.com To: Vojtech Szocs vsz...@redhat.com Cc: users users@ovirt.org, Einav Cohen eco...@redhat.com Sent: Wednesday, February 12, 2014 1:17:08 PM Subject: Re: [ovirt-test-day-2] Possible bug while testing vm-init-persistent feature Thanks Vojtech, There is a bug (and a fix) here: https://bugzilla.redhat.com/1063883 Shahar. On 11.02.14 18:20, Vojtech Szocs wrote: Hello, I think I found a possible bug while testing Shahar's vm-init-persistent feature, not sure if related to vm-init-persistent or Engine vs. vdsm RPC issue. Followed steps in [1,2] to install ovirt-engine on F19, then used it to setup another F19 node as host via WebAdmin GUI. [1] http://www.ovirt.org/OVirt_3.4_TestDay#Installation_notes [2] http://www.ovirt.org/OVirt_3.4.0_release_notes#SECOND_BETA_RELEASE On engine: # rpm -qa ovirt-engine* ovirt-engine-setup-base-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-webadmin-portal-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-websocket-proxy-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-dbscripts-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-setup-plugin-websocket-proxy-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-setup-plugin-ovirt-engine-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-tools-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-cli-3.4.0.3-1.fc19.noarch ovirt-engine-setup-plugin-ovirt-engine-common-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-setup-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-backend-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-setup-plugin-allinone-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-sdk-python-3.4.0.3-1.fc19.noarch ovirt-engine-restapi-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-lib-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-userportal-3.4.0-0.7.beta2.fc19.noarch On host: # rpm -qa vdsm* vdsm-python-zombiereaper-4.14.2-0.fc19.noarch vdsm-xmlrpc-4.14.2-0.fc19.noarch vdsm-4.14.2-0.fc19.x86_64 vdsm-cli-4.14.2-0.fc19.noarch vdsm-python-4.14.2-0.fc19.x86_64 Using default 3.4 DataCenter/Cluster, created WinXP VM via WebAdmin GUI *without* Sysprep enabled. Trying to Run Once with WinXP ISO attached, I get: Error while executing action Run VM once: Network error during communication with the Host. Relevant log part attached as XmlRpcExtensionException-part.log Command org.ovirt.engine.core.bll.RunVmOnceCommand throw Vdc Bll exception. With error message VdcBLLException: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException: org.apache.xmlrpc.common.XmlRpcExtensionException: Null values aren't supported, if isEnabledForExtensions() == false (Failed with error VDS_NETWORK_ERROR and code 5022) Second try, created WinXP VM via WebAdmin GUI *with* Sysprep enabled. On Initial Run tab, checked Configure Time Zone and providing VM OS specific timezone override, whose value is different than in System tab's (general) Time Zone field. Trying to Run Once with Sysprep enabled WinXP ISO attached, I get: Cannot run VM. VM is running. Relevant log part attached as VmIsRunning-part.log Command CreateVmVDSCommand(HostName = f19-host-34beta2, HostId = 02a21a1a-47d6-4d90-8059-a69f0724feff, vmId=cd3722b0-3139-4d23-8ad4-f01875e85a63, vm=VM [winxp-foo]) execution failed. Exception: RuntimeException: java.lang.NullPointerException .. CanDoAction of action RunVmOnce failed.
Re: [Users] [ovirt-test-day-2] Possible bug while testing vm-init-persistent feature
Thank you very much Vojtech I will look to this very soon Shahar Havivi. On 11.02.14 18:20, Vojtech Szocs wrote: Hello, I think I found a possible bug while testing Shahar's vm-init-persistent feature, not sure if related to vm-init-persistent or Engine vs. vdsm RPC issue. Followed steps in [1,2] to install ovirt-engine on F19, then used it to setup another F19 node as host via WebAdmin GUI. [1] http://www.ovirt.org/OVirt_3.4_TestDay#Installation_notes [2] http://www.ovirt.org/OVirt_3.4.0_release_notes#SECOND_BETA_RELEASE On engine: # rpm -qa ovirt-engine* ovirt-engine-setup-base-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-webadmin-portal-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-websocket-proxy-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-dbscripts-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-setup-plugin-websocket-proxy-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-setup-plugin-ovirt-engine-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-tools-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-cli-3.4.0.3-1.fc19.noarch ovirt-engine-setup-plugin-ovirt-engine-common-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-setup-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-backend-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-setup-plugin-allinone-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-sdk-python-3.4.0.3-1.fc19.noarch ovirt-engine-restapi-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-lib-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-userportal-3.4.0-0.7.beta2.fc19.noarch On host: # rpm -qa vdsm* vdsm-python-zombiereaper-4.14.2-0.fc19.noarch vdsm-xmlrpc-4.14.2-0.fc19.noarch vdsm-4.14.2-0.fc19.x86_64 vdsm-cli-4.14.2-0.fc19.noarch vdsm-python-4.14.2-0.fc19.x86_64 Using default 3.4 DataCenter/Cluster, created WinXP VM via WebAdmin GUI *without* Sysprep enabled. Trying to Run Once with WinXP ISO attached, I get: Error while executing action Run VM once: Network error during communication with the Host. Relevant log part attached as XmlRpcExtensionException-part.log Command org.ovirt.engine.core.bll.RunVmOnceCommand throw Vdc Bll exception. With error message VdcBLLException: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException: org.apache.xmlrpc.common.XmlRpcExtensionException: Null values aren't supported, if isEnabledForExtensions() == false (Failed with error VDS_NETWORK_ERROR and code 5022) Second try, created WinXP VM via WebAdmin GUI *with* Sysprep enabled. On Initial Run tab, checked Configure Time Zone and providing VM OS specific timezone override, whose value is different than in System tab's (general) Time Zone field. Trying to Run Once with Sysprep enabled WinXP ISO attached, I get: Cannot run VM. VM is running. Relevant log part attached as VmIsRunning-part.log Command CreateVmVDSCommand(HostName = f19-host-34beta2, HostId = 02a21a1a-47d6-4d90-8059-a69f0724feff, vmId=cd3722b0-3139-4d23-8ad4-f01875e85a63, vm=VM [winxp-foo]) execution failed. Exception: RuntimeException: java.lang.NullPointerException .. CanDoAction of action RunVmOnce failed. Reasons:VAR__ACTION__RUN,VAR__TYPE__VM,VAR__ACTION__RUN,VAR__TYPE__VM,ACTION_TYPE_FAILED_VM_IS_RUNNING Checking if VM is really running on host (it's not): # vdsClient -s 0 list table (no results) Full engine.log + vdsm.log attached. I can provide WebAdmin GUI link and more details if needed. It's possible that there's something wrong with my engine/host, but I'm clueless as how to fix above issues.. Thanks, Vojtech 2014-02-12 00:07:02,041 INFO [org.ovirt.engine.core.vdsbroker.IsVmDuringInitiatingVDSCommand] (ajp--127.0.0.1-8702-5) [1891c562] START, IsVmDuringInitiatingVDSCommand( vmId = cd3722b0-3139-4d23-8ad4-f01875e85a63), log id: 536a0258 2014-02-12 00:07:02,042 INFO [org.ovirt.engine.core.vdsbroker.IsVmDuringInitiatingVDSCommand] (ajp--127.0.0.1-8702-5) [1891c562] FINISH, IsVmDuringInitiatingVDSCommand, return: false, log id: 536a0258 2014-02-12 00:07:02,052 INFO [org.ovirt.engine.core.bll.RunVmOnceCommand] (ajp--127.0.0.1-8702-5) [1891c562] Running command: RunVmOnceCommand internal: false. Entities affected : ID: cd3722b0-3139-4d23-8ad4-f01875e85a63 Type: VM 2014-02-12 00:07:02,068 INFO [org.ovirt.engine.core.bll.RunVmCommand] (ajp--127.0.0.1-8702-5) [1891c562] Running VM with attached cd en_windows_xp_professional_with_service_pack_3_x86_cd_vl_x14-73974.iso 2014-02-12 00:07:02,071 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.IsoPrefixVDSCommand] (ajp--127.0.0.1-8702-5) [1891c562] START, IsoPrefixVDSCommand(HostName = f19-host-34beta2, HostId = 02a21a1a-47d6-4d90-8059-a69f0724feff, storagePoolId=0002-0002-0002-0002-0002), log id: 160a4058 2014-02-12 00:07:02,080 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.IsoPrefixVDSCommand] (ajp--127.0.0.1-8702-5) [1891c562] FINISH, IsoPrefixVDSCommand, return:
Re: [Users] [ovirt-test-day-2] Testing all-in-one feature on f19
- Original Message - From: Karli Sjöberg karli.sjob...@slu.se To: d...@redhat.com Cc: ih...@redhat.com, users@ovirt.org Sent: Wednesday, February 12, 2014 9:56:52 AM Subject: Re: [Users] [ovirt-test-day-2] Testing all-in-one feature on f19 On Wed, 2014-02-12 at 02:51 -0500, Yedidyah Bar David wrote: - Original Message - From: Karli Sjöberg karli.sjob...@slu.se To: ih...@redhat.com Cc: users@ovirt.org Sent: Wednesday, February 12, 2014 9:37:14 AM Subject: Re: [Users] [ovirt-test-day-2] Testing all-in-one feature on f19 On Tue, 2014-02-11 at 18:40 +0200, Itamar Heim wrote: On 02/11/2014 06:19 PM, Alexander Wels wrote: Same issue for me, I did a minimum fedora 19 install added the appropriate repositories. Completed almost successfully, host didn't come up with vdsm compatibility error message. The vdsm on the host is: vdsm-4.13.3-3.fc19.x86_64 I tried the same 3.3 dc/cluster and the host came up immediately. Alexander On Tuesday, February 11, 2014 11:02:37 AM Moti Asayag wrote: Hi, In the 3.4 ovirt-test-day-2 I've tested the all-in-one feature. I installed the all-in-one setup on a vm. The installation ended almost successfully, except of the vdsm service, where the the host didn't become operational due to lack of support in clusterLevel = 3.4: Feb 11 15:51:52 localhost vdsm root ERROR VIR_MIGRATE_ABORT_ON_ERROR not found in libvirt, support for clusterLevel = 3.4 is disabled. For Fedora 19 users, please consider upgrading libvirt from the virt-preview repository Once I created a new 3.3 DC and configured a local storage, the local host become operational and I was able to create a vm and to run it. Thanks, Moti ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users no one tested on .el6? ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users Was stuck on watch duty first half of the day so was short on time and had to continue the rest of the testing today. It might be worth noting on the wiki page[1] that if you´re a tester (like we are) that does change the contents of the '(el6| fedora)'-ovirt.repo (like enabling ovirt-3.4.0-prerelease e.g.), that when you later update the ovirt-release-'(el6|fedora)' rpm, the repo file gets saved as an .rpmnew instead. Was just luck we saw that in yum and move-replaced our el6-ovirt.repo with the el6-ovirt.repo.rpmnew before continuing with the rest of the instructions. Perhaps something simple like: Note: When done with your testing, please remember to change enabled back to 0 to avoid having duplicate repo files As for the upgrade, it was actually done first from 3.3.3-RC to 3.3.3-GA, and then up to 3.4.0-beta2. Both of which went through without major issues. Minor issue going up to 3.4.0 was that engine-setup still changed the access rights to the predefined ISO domain in /etc/exports to None (empty python variable?), Indeed. It's mentioned in known issues. Will hopefully be fixed in a few days. Ah, cool. but other than that, it went smoothly by. Tested making a live snapshot on a VM that failed, big surprise. Logs are attached. Will continue testing the new power-saving policy as soon as we can manage to find another Host to incorporate into the cluster. Oh, and we tried using the ovirt-log-collector to compile the logs but it failed when trying to gather hypervisor data, just after we typed in the password for admin@internal. Even when executing with the option --no-hypervisors it still tried to do that?! I think it should work. Can you send logs please? Does the log-collector log it´s own logging?:) Or what logs are you referring to? Sorry for being unclear. Output of the command, preferably with --verbose (--log-file does write to a log, btw...). Thanks. -- Didi ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] [ovirt-test-day-2] Testing all-in-one feature on f19
On Wed, 2014-02-12 at 03:35 -0500, Yedidyah Bar David wrote: - Original Message - From: Karli Sjöberg karli.sjob...@slu.se To: d...@redhat.com Cc: ih...@redhat.com, users@ovirt.org Sent: Wednesday, February 12, 2014 9:56:52 AM Subject: Re: [Users] [ovirt-test-day-2] Testing all-in-one feature on f19 On Wed, 2014-02-12 at 02:51 -0500, Yedidyah Bar David wrote: - Original Message - From: Karli Sjöberg karli.sjob...@slu.se To: ih...@redhat.com Cc: users@ovirt.org Sent: Wednesday, February 12, 2014 9:37:14 AM Subject: Re: [Users] [ovirt-test-day-2] Testing all-in-one feature on f19 On Tue, 2014-02-11 at 18:40 +0200, Itamar Heim wrote: On 02/11/2014 06:19 PM, Alexander Wels wrote: Same issue for me, I did a minimum fedora 19 install added the appropriate repositories. Completed almost successfully, host didn't come up with vdsm compatibility error message. The vdsm on the host is: vdsm-4.13.3-3.fc19.x86_64 I tried the same 3.3 dc/cluster and the host came up immediately. Alexander On Tuesday, February 11, 2014 11:02:37 AM Moti Asayag wrote: Hi, In the 3.4 ovirt-test-day-2 I've tested the all-in-one feature. I installed the all-in-one setup on a vm. The installation ended almost successfully, except of the vdsm service, where the the host didn't become operational due to lack of support in clusterLevel = 3.4: Feb 11 15:51:52 localhost vdsm root ERROR VIR_MIGRATE_ABORT_ON_ERROR not found in libvirt, support for clusterLevel = 3.4 is disabled. For Fedora 19 users, please consider upgrading libvirt from the virt-preview repository Once I created a new 3.3 DC and configured a local storage, the local host become operational and I was able to create a vm and to run it. Thanks, Moti ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users no one tested on .el6? ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users Was stuck on watch duty first half of the day so was short on time and had to continue the rest of the testing today. It might be worth noting on the wiki page[1] that if you´re a tester (like we are) that does change the contents of the '(el6| fedora)'-ovirt.repo (like enabling ovirt-3.4.0-prerelease e.g.), that when you later update the ovirt-release-'(el6|fedora)' rpm, the repo file gets saved as an .rpmnew instead. Was just luck we saw that in yum and move-replaced our el6-ovirt.repo with the el6-ovirt.repo.rpmnew before continuing with the rest of the instructions. Perhaps something simple like: Note: When done with your testing, please remember to change enabled back to 0 to avoid having duplicate repo files As for the upgrade, it was actually done first from 3.3.3-RC to 3.3.3-GA, and then up to 3.4.0-beta2. Both of which went through without major issues. Minor issue going up to 3.4.0 was that engine-setup still changed the access rights to the predefined ISO domain in /etc/exports to None (empty python variable?), Indeed. It's mentioned in known issues. Will hopefully be fixed in a few days. Ah, cool. but other than that, it went smoothly by. Tested making a live snapshot on a VM that failed, big surprise. Logs are attached. Will continue testing the new power-saving policy as soon as we can manage to find another Host to incorporate into the cluster. Oh, and we tried using the ovirt-log-collector to compile the logs but it failed when trying to gather hypervisor data, just after we typed in the password for admin@internal. Even when executing with the option --no-hypervisors it still tried to do that?! I think it should work. Can you send logs please? Does the log-collector log it´s own logging?:) Or what logs are you referring to? Sorry for being unclear. Output of the command, preferably with --verbose (--log-file does write to a log, btw...). Thanks. -- Didi Here you are: http://pastebin.com/Hwya90LF -- Med Vänliga Hälsningar --- Karli Sjöberg Swedish University of Agricultural Sciences Box 7079 (Visiting Address Kronåsvägen 8) S-750 07 Uppsala, Sweden Phone: +46-(0)18-67 15 66 karli.sjob...@slu.se ___ Users
Re: [Users] [ovirt-test-day-2] Testing all-in-one feature on f19
- Original Message - From: Karli Sjöberg karli.sjob...@slu.se To: d...@redhat.com Cc: ih...@redhat.com, users@ovirt.org Sent: Wednesday, February 12, 2014 11:52:55 AM Subject: Re: [Users] [ovirt-test-day-2] Testing all-in-one feature on f19 Oh, and we tried using the ovirt-log-collector to compile the logs but it failed when trying to gather hypervisor data, just after we typed in the password for admin@internal. Even when executing with the option --no-hypervisors it still tried to do that?! I think it should work. Can you send logs please? Does the log-collector log it´s own logging?:) Or what logs are you referring to? Sorry for being unclear. Output of the command, preferably with --verbose (--log-file does write to a log, btw...). Thanks. -- Didi Here you are: http://pastebin.com/Hwya90LF Sorry, I meant with '--no-hypervisors'... The actual bug you encountered seems to be solved by [1]. [1] http://gerrit.ovirt.org/23488 -- Didi ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] [ovirt-test-day-2] Testing all-in-one feature on f19
On Wed, 2014-02-12 at 05:09 -0500, Yedidyah Bar David wrote: - Original Message - From: Karli Sjöberg karli.sjob...@slu.se To: d...@redhat.com Cc: ih...@redhat.com, users@ovirt.org Sent: Wednesday, February 12, 2014 11:52:55 AM Subject: Re: [Users] [ovirt-test-day-2] Testing all-in-one feature on f19 Oh, and we tried using the ovirt-log-collector to compile the logs but it failed when trying to gather hypervisor data, just after we typed in the password for admin@internal. Even when executing with the option --no-hypervisors it still tried to do that?! I think it should work. Can you send logs please? Does the log-collector log it´s own logging?:) Or what logs are you referring to? Sorry for being unclear. Output of the command, preferably with --verbose (--log-file does write to a log, btw...). Thanks. -- Didi Here you are: http://pastebin.com/Hwya90LF Sorry, I meant with '--no-hypervisors'... The actual bug you encountered seems to be solved by [1]. [1] http://gerrit.ovirt.org/23488 -- Didi Huh, that´s so strange, it worked this time with --no-hypervisors: http://pastebin.com/2RSjsT2i This time it outputs correctly and also running without --verbose produces an expected output. But the first time we ran it, even with --no-hypervisors, both me and my colleague remember it like it bombed out and didn´t print out the last lines about where it collected and placed the archive and such. Definitely not something you´d take for successful at least. But now it works, tested a couple of times just to be sure... False alarm... -- Med Vänliga Hälsningar --- Karli Sjöberg Swedish University of Agricultural Sciences Box 7079 (Visiting Address Kronåsvägen 8) S-750 07 Uppsala, Sweden Phone: +46-(0)18-67 15 66 karli.sjob...@slu.se ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] [ovirt-test-day-2] Testing all-in-one feature on f19
- Original Message - From: Karli Sjöberg karli.sjob...@slu.se To: d...@redhat.com Cc: ih...@redhat.com, users@ovirt.org Sent: Wednesday, February 12, 2014 12:34:18 PM Subject: Re: [Users] [ovirt-test-day-2] Testing all-in-one feature on f19 On Wed, 2014-02-12 at 05:09 -0500, Yedidyah Bar David wrote: - Original Message - From: Karli Sjöberg karli.sjob...@slu.se To: d...@redhat.com Cc: ih...@redhat.com, users@ovirt.org Sent: Wednesday, February 12, 2014 11:52:55 AM Subject: Re: [Users] [ovirt-test-day-2] Testing all-in-one feature on f19 Oh, and we tried using the ovirt-log-collector to compile the logs but it failed when trying to gather hypervisor data, just after we typed in the password for admin@internal. Even when executing with the option --no-hypervisors it still tried to do that?! I think it should work. Can you send logs please? Does the log-collector log it´s own logging?:) Or what logs are you referring to? Sorry for being unclear. Output of the command, preferably with --verbose (--log-file does write to a log, btw...). Thanks. -- Didi Here you are: http://pastebin.com/Hwya90LF Sorry, I meant with '--no-hypervisors'... The actual bug you encountered seems to be solved by [1]. [1] http://gerrit.ovirt.org/23488 -- Didi Huh, that´s so strange, it worked this time with --no-hypervisors: http://pastebin.com/2RSjsT2i This time it outputs correctly and also running without --verbose produces an expected output. But the first time we ran it, even with --no-hypervisors, both me and my colleague remember it like it bombed out and didn´t print out the last lines about where it collected and placed the archive and such. Definitely not something you´d take for successful at least. OK, but did it fail during trying to connect to the engine to get the list of hypervisors? Perhaps there was some other problem? But now it works, tested a couple of times just to be sure... False alarm... OK... Thanks for the report! -- Didi ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] [ovirt-test-day-2] Possible bug while testing vm-init-persistent feature
Thanks Vojtech, There is a bug (and a fix) here: https://bugzilla.redhat.com/1063883 Shahar. On 11.02.14 18:20, Vojtech Szocs wrote: Hello, I think I found a possible bug while testing Shahar's vm-init-persistent feature, not sure if related to vm-init-persistent or Engine vs. vdsm RPC issue. Followed steps in [1,2] to install ovirt-engine on F19, then used it to setup another F19 node as host via WebAdmin GUI. [1] http://www.ovirt.org/OVirt_3.4_TestDay#Installation_notes [2] http://www.ovirt.org/OVirt_3.4.0_release_notes#SECOND_BETA_RELEASE On engine: # rpm -qa ovirt-engine* ovirt-engine-setup-base-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-webadmin-portal-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-websocket-proxy-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-dbscripts-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-setup-plugin-websocket-proxy-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-setup-plugin-ovirt-engine-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-tools-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-cli-3.4.0.3-1.fc19.noarch ovirt-engine-setup-plugin-ovirt-engine-common-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-setup-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-backend-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-setup-plugin-allinone-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-sdk-python-3.4.0.3-1.fc19.noarch ovirt-engine-restapi-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-lib-3.4.0-0.7.beta2.fc19.noarch ovirt-engine-userportal-3.4.0-0.7.beta2.fc19.noarch On host: # rpm -qa vdsm* vdsm-python-zombiereaper-4.14.2-0.fc19.noarch vdsm-xmlrpc-4.14.2-0.fc19.noarch vdsm-4.14.2-0.fc19.x86_64 vdsm-cli-4.14.2-0.fc19.noarch vdsm-python-4.14.2-0.fc19.x86_64 Using default 3.4 DataCenter/Cluster, created WinXP VM via WebAdmin GUI *without* Sysprep enabled. Trying to Run Once with WinXP ISO attached, I get: Error while executing action Run VM once: Network error during communication with the Host. Relevant log part attached as XmlRpcExtensionException-part.log Command org.ovirt.engine.core.bll.RunVmOnceCommand throw Vdc Bll exception. With error message VdcBLLException: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException: org.apache.xmlrpc.common.XmlRpcExtensionException: Null values aren't supported, if isEnabledForExtensions() == false (Failed with error VDS_NETWORK_ERROR and code 5022) Second try, created WinXP VM via WebAdmin GUI *with* Sysprep enabled. On Initial Run tab, checked Configure Time Zone and providing VM OS specific timezone override, whose value is different than in System tab's (general) Time Zone field. Trying to Run Once with Sysprep enabled WinXP ISO attached, I get: Cannot run VM. VM is running. Relevant log part attached as VmIsRunning-part.log Command CreateVmVDSCommand(HostName = f19-host-34beta2, HostId = 02a21a1a-47d6-4d90-8059-a69f0724feff, vmId=cd3722b0-3139-4d23-8ad4-f01875e85a63, vm=VM [winxp-foo]) execution failed. Exception: RuntimeException: java.lang.NullPointerException .. CanDoAction of action RunVmOnce failed. Reasons:VAR__ACTION__RUN,VAR__TYPE__VM,VAR__ACTION__RUN,VAR__TYPE__VM,ACTION_TYPE_FAILED_VM_IS_RUNNING Checking if VM is really running on host (it's not): # vdsClient -s 0 list table (no results) Full engine.log + vdsm.log attached. I can provide WebAdmin GUI link and more details if needed. It's possible that there's something wrong with my engine/host, but I'm clueless as how to fix above issues.. Thanks, Vojtech 2014-02-12 00:07:02,041 INFO [org.ovirt.engine.core.vdsbroker.IsVmDuringInitiatingVDSCommand] (ajp--127.0.0.1-8702-5) [1891c562] START, IsVmDuringInitiatingVDSCommand( vmId = cd3722b0-3139-4d23-8ad4-f01875e85a63), log id: 536a0258 2014-02-12 00:07:02,042 INFO [org.ovirt.engine.core.vdsbroker.IsVmDuringInitiatingVDSCommand] (ajp--127.0.0.1-8702-5) [1891c562] FINISH, IsVmDuringInitiatingVDSCommand, return: false, log id: 536a0258 2014-02-12 00:07:02,052 INFO [org.ovirt.engine.core.bll.RunVmOnceCommand] (ajp--127.0.0.1-8702-5) [1891c562] Running command: RunVmOnceCommand internal: false. Entities affected : ID: cd3722b0-3139-4d23-8ad4-f01875e85a63 Type: VM 2014-02-12 00:07:02,068 INFO [org.ovirt.engine.core.bll.RunVmCommand] (ajp--127.0.0.1-8702-5) [1891c562] Running VM with attached cd en_windows_xp_professional_with_service_pack_3_x86_cd_vl_x14-73974.iso 2014-02-12 00:07:02,071 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.IsoPrefixVDSCommand] (ajp--127.0.0.1-8702-5) [1891c562] START, IsoPrefixVDSCommand(HostName = f19-host-34beta2, HostId = 02a21a1a-47d6-4d90-8059-a69f0724feff, storagePoolId=0002-0002-0002-0002-0002), log id: 160a4058 2014-02-12 00:07:02,080 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.IsoPrefixVDSCommand] (ajp--127.0.0.1-8702-5) [1891c562] FINISH, IsoPrefixVDSCommand, return:
[Users] [ovirt-test-day-2] - testing neutron integration - remove external networks
Hi, I tested $subject, I have to say i don't know much about networks / neutron, so maybe some of the issues i encountered are just my fault.. i used pre-configured neutron server (thanks Mike!) and the beta2 for ovirt-engine, i used the wiki to configure it: http://www.ovirt.org/Overlay_Networks_with_Neutron_Integration these are the issues i've seen: 1. add provider is hidden, since 'system' node in the tree is collapsed by default, i couldn't find it, the way to add provider should at least be documented in the neutron integration wiki, i had to ask around to find it.. 2. add provider dialog: wrong tab indexing - after entering name, i clicked 'tab' to enter description, but the focus moved to the 'cancel' button [bug 1064240] this is pretty minor, but i think its basic usage issue, and probably easy fix. 3. selecting 'Subnet' sub-tab of the imported external network doest show anything, and creates an error in the engine log [bug 1064231] Other than that, i was able to create and remove the external network with no issues, we might need a better (maybe step-by-step?) documentation on configuring this, as it was not trivial (there are manual steps need to be done on the hosts..) or, even better, automating everything needed on the host side into host-deploy. Thanks, Omer. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[Users] [Ovirt-Test-Day-2]
Hi I had tested the following items : *** infra 1038222 Read Only Admin role in AP Test results : Working as expected, user can only view everything but can not perform any action *** *** network 1058594 add /networks sub-collection under /datacenters/xxx Test results : Working as expected *** *** ppc Multiarchitecture support 1053715 Ability to search by architecture Test results : Working as expected *** *** sla 1036746 High Availability flag should be included when exporting/importing from Export Domain Test results : Working as expected *** *** sla 1036749 Even Distribution Policy by number of VMs Test results : Working as expected Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1064289 *** *** storage 1047273 Adding Disk to a VM which is not down adds a Disk that is not activated Test results : Working as expected *** *** sla 1036753 Make reservations for HA VMs to make sure there's enough capacity to start them if N hosts fail Test results : Not worked , found a bug that was already reported (1057579) Working only when host is removed or moved to another cluster *** Apart from that I had opened the following bugs: --- https://bugzilla.redhat.com/show_bug.cgi?id=1063704 https://bugzilla.redhat.com/show_bug.cgi?id=1064289 https://bugzilla.redhat.com/show_bug.cgi?id=1064395 https://bugzilla.redhat.com/show_bug.cgi?id=1064397 Regards Eli Mesika ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[Users] ovirt test day 2
Hi, I tested the following: https://bugzilla.redhat.com/1053646easily collapsible left-pane - was not included in test day 1 (I was supposed to test it back then) - works fine. https://bugzilla.redhat.com/1054209 - read only disks - works fine. https://bugzilla.redhat.com/1054219 - Only comment is - IMHO it should be considered having disks marked as read only (where applicable) in templates - disks and perhaps also when showing the disks of each snapshot. other bugs opened: https://bugzilla.redhat.com/show_bug.cgi?id=1064601 Yair ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[Users] [ovirt-test-day-2] Testing all-in-one feature on f19
Hi, In the 3.4 ovirt-test-day-2 I've tested the all-in-one feature. I installed the all-in-one setup on a vm. The installation ended almost successfully, except of the vdsm service, where the the host didn't become operational due to lack of support in clusterLevel = 3.4: Feb 11 15:51:52 localhost vdsm root ERROR VIR_MIGRATE_ABORT_ON_ERROR not found in libvirt, support for clusterLevel = 3.4 is disabled. For Fedora 19 users, please consider upgrading libvirt from the virt-preview repository Once I created a new 3.3 DC and configured a local storage, the local host become operational and I was able to create a vm and to run it. Thanks, Moti ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] [ovirt-test-day-2] Testing all-in-one feature on f19
Same issue for me, I did a minimum fedora 19 install added the appropriate repositories. Completed almost successfully, host didn't come up with vdsm compatibility error message. The vdsm on the host is: vdsm-4.13.3-3.fc19.x86_64 I tried the same 3.3 dc/cluster and the host came up immediately. Alexander On Tuesday, February 11, 2014 11:02:37 AM Moti Asayag wrote: Hi, In the 3.4 ovirt-test-day-2 I've tested the all-in-one feature. I installed the all-in-one setup on a vm. The installation ended almost successfully, except of the vdsm service, where the the host didn't become operational due to lack of support in clusterLevel = 3.4: Feb 11 15:51:52 localhost vdsm root ERROR VIR_MIGRATE_ABORT_ON_ERROR not found in libvirt, support for clusterLevel = 3.4 is disabled. For Fedora 19 users, please consider upgrading libvirt from the virt-preview repository Once I created a new 3.3 DC and configured a local storage, the local host become operational and I was able to create a vm and to run it. Thanks, Moti ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] [ovirt-test-day-2] Testing all-in-one feature on f19
On 02/11/2014 06:19 PM, Alexander Wels wrote: Same issue for me, I did a minimum fedora 19 install added the appropriate repositories. Completed almost successfully, host didn't come up with vdsm compatibility error message. The vdsm on the host is: vdsm-4.13.3-3.fc19.x86_64 I tried the same 3.3 dc/cluster and the host came up immediately. Alexander On Tuesday, February 11, 2014 11:02:37 AM Moti Asayag wrote: Hi, In the 3.4 ovirt-test-day-2 I've tested the all-in-one feature. I installed the all-in-one setup on a vm. The installation ended almost successfully, except of the vdsm service, where the the host didn't become operational due to lack of support in clusterLevel = 3.4: Feb 11 15:51:52 localhost vdsm root ERROR VIR_MIGRATE_ABORT_ON_ERROR not found in libvirt, support for clusterLevel = 3.4 is disabled. For Fedora 19 users, please consider upgrading libvirt from the virt-preview repository Once I created a new 3.3 DC and configured a local storage, the local host become operational and I was able to create a vm and to run it. Thanks, Moti ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users no one tested on .el6? ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] [ovirt-test-day-2] Testing all-in-one feature on f19
To reply to myself, I forgot to add the correct repo to my host, once I fixed that updated the host, it came up fine in the default 3.4 dc. The correct vdsm version is: vdsm-4.14.2-0.fc19.x86_64 On Tuesday, February 11, 2014 11:19:35 AM Alexander Wels wrote: Same issue for me, I did a minimum fedora 19 install added the appropriate repositories. Completed almost successfully, host didn't come up with vdsm compatibility error message. The vdsm on the host is: vdsm-4.13.3-3.fc19.x86_64 I tried the same 3.3 dc/cluster and the host came up immediately. Alexander On Tuesday, February 11, 2014 11:02:37 AM Moti Asayag wrote: Hi, In the 3.4 ovirt-test-day-2 I've tested the all-in-one feature. I installed the all-in-one setup on a vm. The installation ended almost successfully, except of the vdsm service, where the the host didn't become operational due to lack of support in clusterLevel = 3.4: Feb 11 15:51:52 localhost vdsm root ERROR VIR_MIGRATE_ABORT_ON_ERROR not found in libvirt, support for clusterLevel = 3.4 is disabled. For Fedora 19 users, please consider upgrading libvirt from the virt-preview repository Once I created a new 3.3 DC and configured a local storage, the local host become operational and I was able to create a vm and to run it. Thanks, Moti ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] [ovirt-test-day-2] Testing all-in-one feature on f19
Argh, I'm running into stuff like this too because I'm using the incorrect repo as well. I'm going off the test day page, which says to enable prerelease, but apparently I'm supposed to use http://ovirt-mirror.eng.lab.tlv.redhat.com/releases/3.4.0-beta2/ Where is this URL documented? Why can't I install this repo with an RPM like the others? I assumed prerelease would be updated with stuff for test day 2, but it's not? Constructive criticism: test day setup is all very confusing for those of us that don't work with builds on a regular basis. Why can't there be a simple step-by-step instruction for how to install engine and a host on Fedora 19 for test day? It's such a black art as it is now. I have a set up steps in one etherpad that worked before, and another set of steps Einav provided me, and another set of steps from an outdated test page -- and I work these steps in some combination hoping it'll work, and it usually doesn't :( - Original Message - From: Alexander Wels aw...@redhat.com To: users@ovirt.org Sent: Tuesday, February 11, 2014 11:40:31 AM Subject: Re: [Users] [ovirt-test-day-2] Testing all-in-one feature on f19 To reply to myself, I forgot to add the correct repo to my host, once I fixed that updated the host, it came up fine in the default 3.4 dc. The correct vdsm version is: vdsm-4.14.2-0.fc19.x86_64 On Tuesday, February 11, 2014 11:19:35 AM Alexander Wels wrote: Same issue for me, I did a minimum fedora 19 install added the appropriate repositories. Completed almost successfully, host didn't come up with vdsm compatibility error message. The vdsm on the host is: vdsm-4.13.3-3.fc19.x86_64 I tried the same 3.3 dc/cluster and the host came up immediately. Alexander On Tuesday, February 11, 2014 11:02:37 AM Moti Asayag wrote: Hi, In the 3.4 ovirt-test-day-2 I've tested the all-in-one feature. I installed the all-in-one setup on a vm. The installation ended almost successfully, except of the vdsm service, where the the host didn't become operational due to lack of support in clusterLevel = 3.4: Feb 11 15:51:52 localhost vdsm root ERROR VIR_MIGRATE_ABORT_ON_ERROR not found in libvirt, support for clusterLevel = 3.4 is disabled. For Fedora 19 users, please consider upgrading libvirt from the virt-preview repository Once I created a new 3.3 DC and configured a local storage, the local host become operational and I was able to create a vm and to run it. Thanks, Moti ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] [ovirt-test-day-2] Testing all-in-one feature on f19
- Original Message - From: Karli Sjöberg karli.sjob...@slu.se To: ih...@redhat.com Cc: users@ovirt.org Sent: Wednesday, February 12, 2014 9:37:14 AM Subject: Re: [Users] [ovirt-test-day-2] Testing all-in-one feature on f19 On Tue, 2014-02-11 at 18:40 +0200, Itamar Heim wrote: On 02/11/2014 06:19 PM, Alexander Wels wrote: Same issue for me, I did a minimum fedora 19 install added the appropriate repositories. Completed almost successfully, host didn't come up with vdsm compatibility error message. The vdsm on the host is: vdsm-4.13.3-3.fc19.x86_64 I tried the same 3.3 dc/cluster and the host came up immediately. Alexander On Tuesday, February 11, 2014 11:02:37 AM Moti Asayag wrote: Hi, In the 3.4 ovirt-test-day-2 I've tested the all-in-one feature. I installed the all-in-one setup on a vm. The installation ended almost successfully, except of the vdsm service, where the the host didn't become operational due to lack of support in clusterLevel = 3.4: Feb 11 15:51:52 localhost vdsm root ERROR VIR_MIGRATE_ABORT_ON_ERROR not found in libvirt, support for clusterLevel = 3.4 is disabled. For Fedora 19 users, please consider upgrading libvirt from the virt-preview repository Once I created a new 3.3 DC and configured a local storage, the local host become operational and I was able to create a vm and to run it. Thanks, Moti ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users no one tested on .el6? ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users Was stuck on watch duty first half of the day so was short on time and had to continue the rest of the testing today. It might be worth noting on the wiki page[1] that if you´re a tester (like we are) that does change the contents of the '(el6| fedora)'-ovirt.repo (like enabling ovirt-3.4.0-prerelease e.g.), that when you later update the ovirt-release-'(el6|fedora)' rpm, the repo file gets saved as an .rpmnew instead. Was just luck we saw that in yum and move-replaced our el6-ovirt.repo with the el6-ovirt.repo.rpmnew before continuing with the rest of the instructions. Perhaps something simple like: Note: When done with your testing, please remember to change enabled back to 0 to avoid having duplicate repo files As for the upgrade, it was actually done first from 3.3.3-RC to 3.3.3-GA, and then up to 3.4.0-beta2. Both of which went through without major issues. Minor issue going up to 3.4.0 was that engine-setup still changed the access rights to the predefined ISO domain in /etc/exports to None (empty python variable?), Indeed. It's mentioned in known issues. Will hopefully be fixed in a few days. but other than that, it went smoothly by. Tested making a live snapshot on a VM that failed, big surprise. Logs are attached. Will continue testing the new power-saving policy as soon as we can manage to find another Host to incorporate into the cluster. Oh, and we tried using the ovirt-log-collector to compile the logs but it failed when trying to gather hypervisor data, just after we typed in the password for admin@internal. Even when executing with the option --no-hypervisors it still tried to do that?! I think it should work. Can you send logs please? Thanks! -- Didi ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] [ovirt-test-day-2] Testing all-in-one feature on f19
On Wed, 2014-02-12 at 02:51 -0500, Yedidyah Bar David wrote: - Original Message - From: Karli Sjöberg karli.sjob...@slu.se To: ih...@redhat.com Cc: users@ovirt.org Sent: Wednesday, February 12, 2014 9:37:14 AM Subject: Re: [Users] [ovirt-test-day-2] Testing all-in-one feature on f19 On Tue, 2014-02-11 at 18:40 +0200, Itamar Heim wrote: On 02/11/2014 06:19 PM, Alexander Wels wrote: Same issue for me, I did a minimum fedora 19 install added the appropriate repositories. Completed almost successfully, host didn't come up with vdsm compatibility error message. The vdsm on the host is: vdsm-4.13.3-3.fc19.x86_64 I tried the same 3.3 dc/cluster and the host came up immediately. Alexander On Tuesday, February 11, 2014 11:02:37 AM Moti Asayag wrote: Hi, In the 3.4 ovirt-test-day-2 I've tested the all-in-one feature. I installed the all-in-one setup on a vm. The installation ended almost successfully, except of the vdsm service, where the the host didn't become operational due to lack of support in clusterLevel = 3.4: Feb 11 15:51:52 localhost vdsm root ERROR VIR_MIGRATE_ABORT_ON_ERROR not found in libvirt, support for clusterLevel = 3.4 is disabled. For Fedora 19 users, please consider upgrading libvirt from the virt-preview repository Once I created a new 3.3 DC and configured a local storage, the local host become operational and I was able to create a vm and to run it. Thanks, Moti ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users no one tested on .el6? ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users Was stuck on watch duty first half of the day so was short on time and had to continue the rest of the testing today. It might be worth noting on the wiki page[1] that if you´re a tester (like we are) that does change the contents of the '(el6| fedora)'-ovirt.repo (like enabling ovirt-3.4.0-prerelease e.g.), that when you later update the ovirt-release-'(el6|fedora)' rpm, the repo file gets saved as an .rpmnew instead. Was just luck we saw that in yum and move-replaced our el6-ovirt.repo with the el6-ovirt.repo.rpmnew before continuing with the rest of the instructions. Perhaps something simple like: Note: When done with your testing, please remember to change enabled back to 0 to avoid having duplicate repo files As for the upgrade, it was actually done first from 3.3.3-RC to 3.3.3-GA, and then up to 3.4.0-beta2. Both of which went through without major issues. Minor issue going up to 3.4.0 was that engine-setup still changed the access rights to the predefined ISO domain in /etc/exports to None (empty python variable?), Indeed. It's mentioned in known issues. Will hopefully be fixed in a few days. Ah, cool. but other than that, it went smoothly by. Tested making a live snapshot on a VM that failed, big surprise. Logs are attached. Will continue testing the new power-saving policy as soon as we can manage to find another Host to incorporate into the cluster. Oh, and we tried using the ovirt-log-collector to compile the logs but it failed when trying to gather hypervisor data, just after we typed in the password for admin@internal. Even when executing with the option --no-hypervisors it still tried to do that?! I think it should work. Can you send logs please? Does the log-collector log it´s own logging?:) Or what logs are you referring to? Thanks! -- Didi -- Med Vänliga Hälsningar --- Karli Sjöberg Swedish University of Agricultural Sciences Box 7079 (Visiting Address Kronåsvägen 8) S-750 07 Uppsala, Sweden Phone: +46-(0)18-67 15 66 karli.sjob...@slu.se ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
