Hello, I am testing provisioning from foreman 1.8.0 to ovirt 3.5 with both on CentOS 7.1503 and have run into an issue after the system has been deployed to ovirt. When the guest system reboots after the kickstart completes it loads the PXE menu from a the same tftp server which tries to start localboot 0. It then tries to boot based on the order that ovirt had set for the guest, which is PXE first and HD second. The message I'm seeing is "Booting from local disk... No more network devices No bootable device" If I change the guest boot options to only the virtual HD the guest boots up without an issue. I have also done a provision to a plain libvirt/kvm server and had no issue after the reboot. Same foreman server and tftp server with PXE menu localboot 0 option were used. Any ideas what I might be running into here, and any additional information needed. Thanks.
On Apr 9, 2015, at 08:38 , Brandon Merjil <bmerjil@ken-ohki.org> wrote:
Hello,
I am testing provisioning from foreman 1.8.0 to ovirt 3.5 with both on CentOS 7.1503 and have run into an issue after the system has been deployed to ovirt. When the guest system reboots after the kickstart completes it loads the PXE menu from a the same tftp server which tries to start localboot 0. It then tries to boot based on the order that ovirt had set for the guest, which is PXE first and HD second. The message I'm seeing is "Booting from local disk... No more network devices No bootable device"
If I change the guest boot options to only the virtual HD the guest boots up without an issue.
I have also done a provision to a plain libvirt/kvm server and had no issue after the reboot. Same foreman server and tftp server with PXE menu localboot 0 option were used. Any ideas what I might be running into here, and any additional information needed.
The boot order is fixed in VM configuration. For initial config/install it would be recommended to use Run Once with changed boot order Thanks, michal
Thanks.
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
I'm doing the provision from foreman and not ovirt. So when you provision from Foreman you cannot do a run once as it is calling the api side of ovirt. There is also the fact that when this is done on just libvirt/kvm it works correctly with the boot order that is PXE first then HD second after the system has been provisioned. On Apr 9, 2015 16:38, "Michal Skrivanek" <michal.skrivanek@redhat.com> wrote:
On Apr 9, 2015, at 08:38 , Brandon Merjil <bmerjil@ken-ohki.org> wrote:
Hello,
I am testing provisioning from foreman 1.8.0 to ovirt 3.5 with both on CentOS 7.1503 and have run into an issue after the system has been deployed to ovirt. When the guest system reboots after the kickstart completes it loads the PXE menu from a the same tftp server which tries to start localboot 0. It then tries to boot based on the order that ovirt had set for the guest, which is PXE first and HD second. The message I'm seeing is "Booting from local disk... No more network devices No bootable device"
If I change the guest boot options to only the virtual HD the guest boots up without an issue.
I have also done a provision to a plain libvirt/kvm server and had no issue after the reboot. Same foreman server and tftp server with PXE menu localboot 0 option were used. Any ideas what I might be running into here, and any additional information needed.
The boot order is fixed in VM configuration. For initial config/install it would be recommended to use Run Once with changed boot order
Thanks, michal
Thanks.
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On 09/04/15 10:03, Brandon Merjil wrote:
I'm doing the provision from foreman and not ovirt. So when you provision from Foreman you cannot do a run once as it is calling the api side of ovirt.
this is not true! the run once functionality can be called via api. but I don't know if foreman supports this, but this would be a question for the foreman community. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
But my question is still why does this work with libvirt/kvm and ovirt fails. libvirt/kvm is not doing run once, it is using the defaults provided by the host which is PXE first HD second. On Apr 9, 2015 17:21, "Sven Kieske" <s.kieske@mittwald.de> wrote:
On 09/04/15 10:03, Brandon Merjil wrote:
I'm doing the provision from foreman and not ovirt. So when you provision from Foreman you cannot do a run once as it is calling the api side of ovirt.
this is not true! the run once functionality can be called via api.
but I don't know if foreman supports this, but this would be a question for the foreman community.
-- Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On 09/04/15 10:31, Brandon Merjil wrote:
But my question is still why does this work with libvirt/kvm and ovirt fails. libvirt/kvm is not doing run once, it is using the defaults provided by the host which is PXE first HD second.
I guess you are running into the ipxe boot loop problem: http://ipxe.org/howto/chainloading#breaking_the_infinite_loop this still seems to be a foreman problem to me, because it's the dhcp/pxe server who handles what gets booted. I know for sure cobbler can handle this, maybe it's a bug in how foreman dhcp/pxe selects the local boot device in ovirt vms? HTH -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
I looked at that as well but ovirt is using gPXE, and I my situation there is no loop. it just stops after trying once. Is there an api reference for the run once option. I'd like to have some thing to point to if I start asking the foreman group about this. On Apr 9, 2015 17:44, "Sven Kieske" <s.kieske@mittwald.de> wrote:
But my question is still why does this work with libvirt/kvm and ovirt fails. libvirt/kvm is not doing run once, it is using the defaults
On 09/04/15 10:31, Brandon Merjil wrote: provided
by the host which is PXE first HD second.
I guess you are running into the ipxe boot loop problem: http://ipxe.org/howto/chainloading#breaking_the_infinite_loop
this still seems to be a foreman problem to me, because it's the dhcp/pxe server who handles what gets booted.
I know for sure cobbler can handle this, maybe it's a bug in how foreman dhcp/pxe selects the local boot device in ovirt vms?
HTH
-- Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On Apr 9, 2015, at 10:49 , Brandon Merjil <bmerjil@ken-ohki.org> wrote:
I looked at that as well but ovirt is using gPXE, and I my situation there is no loop. it just stops after trying once. Is there an api reference for the run once option. I'd like to have some thing to point to if I start asking the foreman group about this.
I believe Sven is right; RunOnce is not relevant if you speak about reboot within the guest OS. I suppose that's the case. It is the same QEMU process then and the only difference might be in PXE bootrom, possibly a gPXE bug.
On Apr 9, 2015 17:44, "Sven Kieske" <s.kieske@mittwald.de> wrote:
On 09/04/15 10:31, Brandon Merjil wrote:
But my question is still why does this work with libvirt/kvm and ovirt fails. libvirt/kvm is not doing run once, it is using the defaults provided by the host which is PXE first HD second.
I guess you are running into the ipxe boot loop problem: http://ipxe.org/howto/chainloading#breaking_the_infinite_loop
this still seems to be a foreman problem to me, because it's the dhcp/pxe server who handles what gets booted.
I know for sure cobbler can handle this, maybe it's a bug in how foreman dhcp/pxe selects the local boot device in ovirt vms?
HTH
-- Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen _______________________________________________ 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
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1163336231-1428603831=:6654 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 9 Apr 2015, Michal Skrivanek wrote:
On Apr 9, 2015, at 10:49 , Brandon Merjil <bmerjil@ken-ohki.org> wrote:
I looked at that as well but ovirt is using gPXE, and I my situation there is no loop. it just stops after trying once. Is there an api reference for the run once option. I'd like to have some thing to point to if I start asking the foreman group about this.
I believe Sven is right; RunOnce is not relevant if you speak about reboot within the guest OS. I suppose that's the case. It is the same QEMU process then and the only difference might be in PXE bootrom, possibly a gPXE bug.
We're still running oVirt Engine 3.5.0 on Fedora 19, but I recently upgraded our hypervisor nodes to CentOS 7 (and then 7.1). I've had no end of trouble with the boot rom images available for CentOS 7.1 nodes. There are two sets of files and one set of symlinks: * /usr/share/qemu-kvm/rhel6-*.rom -> actual files -> installed by qemu-kvm-rhev package -> the default images used by oVirt-installed qemu-kvm * /usr/share/ipxe/*.rom -> actual files -> installed by ipxe-roms-qemu package * /usr/share/qemu-kvm/pxe-*.rom -> symlinks pointing to ../ipxe/*rom images -> installed by qemu-kvm-rhev package I'll note that the qemu-kvm-rhev package is provided by the oVirt team; it's not part of the stock CentOS repository. In our environment, the rhel6-*.rom images won't accept responses from our DHCP server (dhcpd on CentOS 6), while the iPXE images fail when loading the 64-bit installation kernels for very new distributions: CentOS 7.1, Ubuntu 1410 and 1404, and Debian sid. In the end, I punted. I extracted the iPXE images from the Fedora 20 ipxe-roms-qemu and tasked cfengine with pushing them into place: 10222000.rom -> /usr/share/qemu-kvm/rhel6-pcnet.rom 10ec8029.rom -> /usr/share/qemu-kvm/rhel6-ne2k_pci.rom 10ec8139.rom -> /usr/share/qemu-kvm/rhel6-rtl8139.rom 1af41000.rom -> /usr/share/qemu-kvm/rhel6-virtio.rom 8086100e.rom -> /usr/share/qemu-kvm/rhel6-e1000.rom That's the only solution that works for me. NOTE: The ROM images must be the same on all your hypervisor nodes; if they aren't, live migrations will fail. -- Paul Heinlein heinlein@madboa.com 45°38' N, 122°6' W --0-1163336231-1428603831=:6654--
participants (4)
-
Brandon Merjil -
Michal Skrivanek -
Paul Heinlein -
Sven Kieske