Hi Itamar, Apparently not. I've just upgraded the engine and the node to the latest stable packages and it is still unable to start up the installation process of RHEL 5 x86_64 based virtual machines. # rpm -q qemu qemu-kvm vdsm qemu-1.4.2-9.fc19.x86_64 qemu-kvm-1.4.2-9.fc19.x86_64 vdsm-4.12.1-2.fc19.x86_64 # rpm -q ovirt-engine ovirt-engine-3.3.0-4.fc19.noarch Does anyone else is facing the same issue? On Mon, Sep 16, 2013 at 6:37 PM, Itamar Heim <iheim@redhat.com> wrote:
On 09/05/2013 06:31 PM, Raul José Cheleguini wrote:
Hello all,
Please, I'm performing tests with oVirt 3.3 and it has been working really well, except the fact that the installation of RHEL 5 VMs is not happening, not sure why. Does anybody else is experiencing the same issue? Details:
Reproducible steps:
1) Start the VM via 'Run once" option. 2) Insert the boot parameters, for instance: linux text 3) vmlinuz and initrd are loaded without errors. 4) Black screen with a blinking cursor. 5) Anaconda never come up, Kernel is not loaded apparently.
The same behavior occurs with the following versions:
RHEL 5.9 x86_64 RHEL 5.8 x86_64 RHEL 5.7 x86_64
VM definitions:
Operating System: Red Hat Enterprise Linux 5.x x64 Optimized for: Server
If I simple change to a RHEL 5.9 32Bits ISO (Even with the 'Operating System' field defined to work for x64), I am able to carry on with the VM installation and everything goes ok.
Fedora 18 and 19 for x84_64 works well, also RHEL 6 builds for x86_64.
Packages in use:
ovirt-engine-3.3.0-1.fc19.**noarch qemu-1.4.2-7.fc19.x86_64 qemu-kvm-1.4.2-7.fc19.x86_64 libvirt-1.0.5.5-1.fc19.x86_64
Details and data collected:
VM name: tests-rhel5-64bits engine.log vdsm.log qemu process arguments libvirt relevant logs
Last test timestamp: 2013-Sep-05, 12:09 VM tests-rhel5-64bits started on Host dell-pe2950-1
Should I file a bug? Any help will be really appreciated. Thanks, Raul.
______________________________**_________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/**mailman/listinfo/users<http://lists.ovirt.org/mailman/listinfo/users>
was this resolved?