I have a UCS instance with a nic trunked to a pair of vlans, one for
provisioning (vlan1) and one for primary service (vlan 101)
My expectation:
all pxe/provision activity happens over nic1/vlan1, while a nic1.101
sysconfig file is created to define the primary interface.
My result:
no matter how I configure this, I end up with a system trying to use
nic1.101 dns servers during provisioning, and fails. Further inspection
shows "only one interface found" during boot - it's like the virtual nic
isn't being recognized, even though I've configured it with the appropriate
vlan tag and listed the parent eth0.
I understand that nic1.101 has to be flagged as "managed" in order for
foreman to configure it - but that seems to lead to all sorts of other
issues, including registration of DNS (which I don't want) being attempted
and failing.
eth0 is capable of booting natively and provisioning. If we ignored the
eth0.1 completely we'd be set. However, during ks, we don't resolve the
repo name, because "dnsservers is <blank>" even though there is a dns
server configured in the prov subnet. It's as if I select the second nic as
'primary', it tries to provision using it's subnet details instead of the
one that's checked as prov.
Does this make sense?
···
On Thursday, 22 September 2016 07:20:35 UTC-6, Cale Bouscal wrote:
>
> I have a UCS instance with a nic trunked to a pair of vlans, one for
> provisioning (vlan1) and one for primary service (vlan 101)
>
> My expectation:
> - all pxe/provision activity happens over nic1/vlan1, while a nic1.101
> sysconfig file is created to define the primary interface.
>
> My result:
> - no matter how I configure this, I end up with a system trying to use
> nic1.101 dns servers during provisioning, and fails. Further inspection
> shows "only one interface found" during boot - it's like the virtual nic
> isn't being recognized, even though I've configured it with the appropriate
> vlan tag and listed the parent eth0.
>
> I understand that nic1.101 has to be flagged as "managed" in order for
> foreman to configure it - but that seems to lead to all sorts of other
> issues, including registration of DNS (which I don't want) being attempted
> and failing.
>
> How do I achieve the result I'm looking for?
>
the problem in this case is probably that we configure these interfaces during
last step of provisioning (%post in case of kickstart, finish script in case of
debian). If you need to use VLAN for the actual installation you should be
able to achieve it by changing provisioning template, there's no built-in
support for it atm. OTOH the data that you'd need should be accessible in that
template, you can take a look at [1] for good example.
On Thursday 22 of September 2016 06:20:03 Cale Bouscal wrote:
I have a UCS instance with a nic trunked to a pair of vlans, one for
provisioning (vlan1) and one for primary service (vlan 101)
My expectation:
all pxe/provision activity happens over nic1/vlan1, while a nic1.101
sysconfig file is created to define the primary interface.
My result:
no matter how I configure this, I end up with a system trying to use
nic1.101 dns servers during provisioning, and fails. Further inspection
shows “only one interface found” during boot - it’s like the virtual nic
isn’t being recognized, even though I’ve configured it with the appropriate
vlan tag and listed the parent eth0.
I understand that nic1.101 has to be flagged as “managed” in order for
foreman to configure it - but that seems to lead to all sorts of other
issues, including registration of DNS (which I don’t want) being attempted
and failing.
According to what I see, the --nameserver [1] is used from subnet of primary
interface. I think the provisioning interface was meant only for PXE boot but
the rest of the installation goes through primary interface including
downloading the content.
I'm still a bit confused about your setup. You have one physical nic, you try
to build two virtual vlan nics eth0.1 and eth0.101 and use first of them for
provisioning and second as primary? I don't think this would work.
On Thursday 22 of September 2016 06:57:36 Cale Bouscal wrote:
Hmm, not sure that’s what we’re looking for.
eth0 is capable of booting natively and provisioning. If we ignored the
eth0.1 completely we’d be set. However, during ks, we don’t resolve the
repo name, because "dnsservers is " even though there is a dns
server configured in the prov subnet. It’s as if I select the second nic as
’primary’, it tries to provision using it’s subnet details instead of the
one that’s checked as prov.
Does this make sense?
On Thursday, 22 September 2016 07:20:35 UTC-6, Cale Bouscal wrote:
I have a UCS instance with a nic trunked to a pair of vlans, one for
provisioning (vlan1) and one for primary service (vlan 101)
My expectation:
all pxe/provision activity happens over nic1/vlan1, while a nic1.101
sysconfig file is created to define the primary interface.
My result:
no matter how I configure this, I end up with a system trying to use
nic1.101 dns servers during provisioning, and fails. Further inspection
shows “only one interface found” during boot - it’s like the virtual nic
isn’t being recognized, even though I’ve configured it with the
appropriate
vlan tag and listed the parent eth0.
I understand that nic1.101 has to be flagged as “managed” in order for
foreman to configure it - but that seems to lead to all sorts of other
issues, including registration of DNS (which I don’t want) being attempted
and failing.
> According to what I see, the --nameserver [1] is used from subnet of primary
> interface. I think the provisioning interface was meant only for PXE boot but
> the rest of the installation goes through primary interface including
> downloading the content.
I also think that is incorrect, we should configure provisioning
interface and then reconfigure them in POST section.
Looking in the docs, it looks like network option might accept multiple
entries, then we could configure all of them during provisioning? Or at
least both provisioning and primary.
Why we use the POST network configuration instead the "network" Anaconda
options in the first place? Is this because Anaconda in older RHEL
versions?
Yes, older RHEL Anaconda didn't expose options for bonds/vlans IIRC. I think
things like aliases are still not supported. Might be worth of re-checking
with current versions.
···
On Monday 26 of September 2016 16:14:36 Lukas Zapletal wrote:
> > According to what I see, the --nameserver [1] is used from subnet of
> > primary interface. I think the provisioning interface was meant only for
> > PXE boot but the rest of the installation goes through primary interface
> > including downloading the content.
>
> I also think that is incorrect, we should configure provisioning
> interface and then reconfigure them in POST section.
>
> Looking in the docs, it looks like network option might accept multiple
> entries, then we could configure all of them during provisioning? Or at
> least both provisioning and primary.
>
> Why we use the POST network configuration instead the "network" Anaconda
> options in the first place? Is this because Anaconda in older RHEL
> versions?
