It's easily possible if your LXC networking is using a layer-2 mode such as bridge or macvlan. That puts the container's namespace on the same layer-2 network as the host, and you can do the rest in the most obvious way: remove the IP address from the host and add it to the container. (If the address has to be assigned using DHCP, then the container can just run a DHCP client.)

(This however requires the container's MAC address or DHCP Client ID to be known by the local network's DHCP server. If this is a problem then you might need to assign the host a custom MAC address, and give the container the host's MAC.)

For example, if you want to use bridge mode, and have a standard Linux bridge named br0 (see your distro's instructions for creating one), then your LXC configuration might look like this:

lxc.net.1.type = veth
lxc.net.1.flags = up
lxc.net.1.link = br0
lxc.net.1.hwaddr = 02:00:xx:yy:zz:tt

If static IP configuration is wanted:

lxc.net.1.ipv4.address = 45.76.XX.XX/23
lxc.net.1.ipv4.gateway = 45.76.YY.YY
lxc.net.1.ipv6.address = 2001:19f0:X:X:X:X:X:X/64
lxc.net.1.ipv6.gateway = 2001:19f0:X:X::1

If you want to use DHCP and/or SLAAC, then just leave out the address/gateway settings and install a standard DHCP client on the container.

Note: I've heard claims that macvlan mode provides better performance, but I don't actually know how to configure it. Plus, it seems to require the host to also use a macvlan in order to be able to communicate with its own guests.

If you must use a routed mode, it's still doable in mostly the same way, but the container will not be able to use DHCP, and the host will additionally need to run Proxy-ARP to pretend that the IP address is still "on link" despite it being assigned to another system. (Routers don't forward ARP requests.) If DHCP is mandatory, then a special DHCP client configuration might be necessary for the host to acquire the address without actually assigning it to an interface.

It's easily possible if your LXC networking is using a layer-2 mode such as bridge or macvlan. That puts the container's namespace on the same layer-2 network as the host, and you can do the rest in the most obvious way: remove the IP address from the host and add it to the container. (If the address has to be assigned using DHCP, then the container can just run a DHCP client.)

(This however requires the container's MAC address or DHCP Client ID to be known by the local network's DHCP server. If this is a problem then you might need to assign the host a custom MAC address, and give the container the host's MAC.)

For example, if you want to use bridge mode, first create a standard Linux bridge – in this example named br0 – with your Ethernet interface as a member. Making it permanent is very distro-dependent (using ifcfg or /etc/network/interfaces or systemd-networkd), but temporary configuration can be done using:

ip link add br0 type bridge
ip link set br0 up
ip link set ens3 master br0

Note: If you only have remote access to the host server, then it's a very good idea to use KVM or serial console when making such changes.

Then your LXC configuration might look like this:

lxc.net.1.type = veth
lxc.net.1.flags = up
lxc.net.1.link = br0
lxc.net.1.hwaddr = 02:00:xx:yy:zz:tt

If static IP configuration is wanted:

lxc.net.1.ipv4.address = 45.76.XX.XX/23
lxc.net.1.ipv4.gateway = 45.76.YY.YY
lxc.net.1.ipv6.address = 2001:19f0:X:X:X:X:X:X/64
lxc.net.1.ipv6.gateway = 2001:19f0:X:X::1

If you want to use DHCP and/or SLAAC, then just leave out the address/gateway settings and install a standard DHCP client on the container.

Once you start the container, ip link ls master br0 and bridge link will show a second bridge port.

Note: I've heard claims that macvlan mode provides better performance, but I don't actually know how to configure it. Plus, it seems to require the host to also use a macvlan in order to be able to communicate with its own guests.

If you must use a routed mode, it's still doable in mostly the same way, but the container will not be able to use DHCP, and the host will additionally need to run Proxy-ARP to pretend that the IP address is still "on link" despite it being assigned to another system. (Routers don't forward ARP requests.) If DHCP is mandatory, then a special DHCP client configuration might be necessary for the host to acquire the address without actually assigning it to an interface.

It's easily possible if your LXC networking is using a layer-2 mode such as bridge or macvlan. That puts the container's namespace on the same layer-2 network as the host, and you can do the rest in the most obvious way: remove the IP address from the host and add it to the container. (If the address has to be assigned using DHCP, then the container can just run a DHCP client.)

(This however requires the container's MAC address or DHCP Client ID to be known by the local network's DHCP server. If this is a problem then you might need to assign the host a custom MAC address, and give the container the host's MAC.)

If you must use a routed mode, it's still doable in mostly the same way, but the container will not be able to use DHCP, and the host will additionally need to run Proxy-ARP to pretend that the IP address is still "on link" despite it being assigned to another system. (Routers don't forward ARP requests.) If DHCP is mandatory, then a special DHCP client configuration might be necessary for the host to acquire the address without actually assigning it to an interface.

It's easily possible if your LXC networking is using a layer-2 mode such as bridge or macvlan. That puts the container's namespace on the same layer-2 network as the host, and you can do the rest in the most obvious way: remove the IP address from the host and add it to the container. (If the address has to be assigned using DHCP, then the container can just run a DHCP client.)

(This however requires the container's MAC address or DHCP Client ID to be known by the local network's DHCP server. If this is a problem then you might need to assign the host a custom MAC address, and give the container the host's MAC.)

For example, if you want to use bridge mode, and have a standard Linux bridge named br0 (see your distro's instructions for creating one), then your LXC configuration might look like this:

lxc.net.1.type = veth
lxc.net.1.flags = up
lxc.net.1.link = br0
lxc.net.1.hwaddr = 02:00:xx:yy:zz:tt

If static IP configuration is wanted:

lxc.net.1.ipv4.address = 45.76.XX.XX/23
lxc.net.1.ipv4.gateway = 45.76.YY.YY
lxc.net.1.ipv6.address = 2001:19f0:X:X:X:X:X:X/64
lxc.net.1.ipv6.gateway = 2001:19f0:X:X::1

If you want to use DHCP and/or SLAAC, then just leave out the address/gateway settings and install a standard DHCP client on the container.

Note: I've heard claims that macvlan mode provides better performance, but I don't actually know how to configure it. Plus, it seems to require the host to also use a macvlan in order to be able to communicate with its own guests.

If you must use a routed mode, it's still doable in mostly the same way, but the container will not be able to use DHCP, and the host will additionally need to run Proxy-ARP to pretend that the IP address is still "on link" despite it being assigned to another system. (Routers don't forward ARP requests.) If DHCP is mandatory, then a special DHCP client configuration might be necessary for the host to acquire the address without actually assigning it to an interface.