9:38 a.m.
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.
10:38 a.m.
On Apr 9, 2015, at 08:38 , Brandon Merjil <bmerjil(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
11:03 a.m.
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(a)redhat.com>
wrote:
On Apr 9, 2015, at 08:38 , Brandon Merjil <bmerjil(a)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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
11:21 a.m.
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
11:31 a.m.
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(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
11:44 a.m.
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
11:49 a.m.
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(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
11:54 a.m.
On Apr 9, 2015, at 10:49 , Brandon Merjil <bmerjil(a)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(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
9:23 p.m.
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(a)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(a)madboa.com
45°38' N, 122°6' W
--0-1163336231-1428603831=:6654--
3515
days inactive
3515
days old
8 comments
4 participants
participants (4)
-
Brandon Merjil -
Michal Skrivanek -
Paul Heinlein -
Sven Kieske