да каких там только нету опций. всё там есть. только RTFM на странице man systemd.unit.. Before/After всякие там есть

Я же специально написал: без копипасты содержимого шаблона lxc. Понятно что можно скопировать и вписать туда WantedBy/RequiredBy/Wants/Requires, но я хочу обойтись без этого. Вот было бы какое-нибудь Inherits=lxc - было бы вообще прекрасно, но я не нашёл.

зачем нужны свои сервисы и менеджмент из systemd, когда есть builtin решения в lxd?

Зачем нужны сервисы и менеджмент из lxd, когда вся система использует systemd? Или если мне нужна какая-нибудь нетривиальная конфигурация, когда контейнер должен запускаться до/после какого-то сервиса/события в системе? Ну и в Debian Stretch я что-то не вижу пакета lxd (Или он часть lxd?).

оно вроде каноникаловское всё, и lxc и lxd, чё там дебиан мутит это не ко мне.
а насчёт некопипастить, есть systemctl edit который делает *.service.d/override.conf в который можно вписать только нужные вещи.

Вроде бы нет, каноникал их только спонсирует.
Пошёл искать edit, там же нашёл add-requires и add-wants (В галаза долблюсь, извиняюсь), что уже близко.
Но опять же

/# systemctl add-requires lxc@container1 lxc@container0
Failed to add dependency: File lxc@container1.target: No such file or directory

А почему .target а не .service?

У add-requires и add-wants особая семантика: первый аргумент берётся с расширением .target по умолчанию, а второй — .service. Допиши к обоим аргументам расширение явно.

Но вообще я бы рекомендовал не делать add-wants (как можно догадаться из вышесказанного, эти команды придумывались для добавления зависимостей к целям), а дописать текстом в drop-in. Так ты сможешь видеть эту зависимость, если сделаешь systemctl cat.

Благодарю. Но не помогло.
По этой документации создал конфиг /etc/systemd/system/lxc@container1.service.d/requires_container0.conf с содержимым:

[Install]
Requires=lxc@container0.service

Решено

Решение без зависимостей и шаблонов сервисов в systemd

# /var/lib/lxc/container0/config

# Запускать автоматически.
lxc.start.auto = 1
# Место в очереди, меньше - раньше (Хотя гугл говорит об обратном).
lxc.start.order = 0

# Создать veth-пару в контейнере со вторым концом (veth1) в хосте.
lxc.network.0.type = veth
lxc.network.0.name = veth0
lxc.network.0.veth.pair = veth1

# /var/lib/lxc/container1/config

# Запускать автоматически.
lxc.start.auto = 1
# Место в очереди, меньше - раньше (Хотя гугл говорит об обратном).
lxc.start.order = 1

# "Забрать" veth1 из хоста.
lxc.network.0.type = phys
lxc.network.0.link = veth1

systemctl enable lxc

# /etc/systemd/network/10-veth0-veth1.netdev

# Создать veth0-veth1 пару.
[NetDev]
Kind=veth0
Name=veth0

[Peer]
Name=veth1

# /etc/systemd/system/lxc@container0.service.d/requires_veth0.conf

# Ждать пока systemd-networkd создаст veth0.
[Install]
Requires=sys-subsystem-net-devices-veth0.device

# /etc/systemd/system/lxc@container1.service.d/requires_veth1.conf

# Ждать пока systemd-networkd создаст veth1.
[Install]
Requires=sys-subsystem-net-devices-veth1.device

# /var/lib/lxc/container0/config

# "Забрать" veth0 из хоста.
lxc.network.0.type = phys
lxc.network.0.link = veth0

# /var/lib/lxc/container1/config

# "Забрать" veth1 из хоста.
lxc.network.0.type = phys
lxc.network.0.link = veth1

systemctl enable systemd-networkd.service lxc@container0.service lxc@container1.service

Не [Install], а [Unit].

# Ждать пока systemd-networkd создаст veth0.
[Install]
Requires=sys-subsystem-net-devices-veth0.device

Так тоже неправильно. Это нужно в [Unit] класть.

Благодарю, поправил.

У тебя исходное решение именно потому и не работало, что ты не там зависимость прописал.

Буду знать. Но оставлю последнее решение, пусть сетью занимается сервис для этого написанный, а не lxc.

так это всё только чтобы сеть поднималась? омг, попробуй всё же LXD, хотяб в виртуалке и из snap
например

~$ cat /etc/systemd/network/02-veth.network 
[Match]
Name=veth*
Driver=openvswitch

[Link]
ARP=true
RequiredForOnline=true

[Network]
Description=lxd-veth
LinkLocalAddressing=no
BindCarrier=lo
IPv4ProxyARP=true

~$ lxc profile show privileged 
config:
  security.nesting: "true"
  security.privileged: "true"
description: privileged LXD profile
devices:
  lxd-veth1:
    nictype: macvlan
    parent: veth1
    type: nic
...

~$ sudo ovs-vsctl show
...
    Bridge "ovs-bridge0"
        Port "veth1"
            Interface "veth1"
                type: internal
...

Проклятый Леннарт. Когда ж он, наконец-то, сдохнет?

Идёшь в /usr/lib/systemd/system (для CentOS7), ищешь нужный тебе сервис/таргет, добавляешь в строку After зависимость.

Широкий глюк, который в центоси везде (да и в других дистрах тоже) в том, что написано After=network.target в связи с чем сетевые сервисы не стартуют автоматически, если привязаны к конкретному интерфейсу (например, 172.19.11.5).

Дело в том, что network.target возвращает успешное выполнение СРАЗУ после запуска, не дожидаясь поднятия интерфейса. Если сервис привязан к *, то 127.0.0.1 есть и сервис стартует. В противном случае, напишет в сислог «no such interface». Лечится заменой на After=network-online.target - этот таргет ждёт поднятия интерфейсов и привязанные к конкретным IP сервисы стартуют без проблем.

Аффектится на очень многое, включая постфикс, sshd (да-да, прописав в sshd_config привязку к IP можно потерять управление сервером %) ), мускль и частично OpenVPN.

Нужно что бы

Сдохни, тварь.

без копипасты содержимого шаблона

Сделай override на конкретные экземпляры.

systemctl edit lxc@foobar1
systemctl edit lxc@foobar2

Дело в том, что network.target возвращает успешное выполнение СРАЗУ после запуска, не дожидаясь поднятия интерфейса.

Для этого есть network-online.target, но для него нужны костыли в системе управления сетью (systemd-networkd-wait-online, NetworkManager-wait-online, etc.)

Так это, ты точно прочитал простыню кусков кода целиком? Там же два способа решения этой задачи, и первый ещё короче, чем твой вариант lxd. К тому же в моей конфигурации не используется мост на хосте, и на то есть причины.

Проклятый Леннарт. Когда ж он, наконец-то, сдохнет?

Когда сдохнет - пожалеешь, на смену ему придёт писатель самого лучшего менеджера сервисов, инита, пакетного менеджера и браузера в одном пакете на... NodeJS!

Идёшь в /usr/lib/systemd/system (для CentOS7), ищешь нужный тебе сервис/таргет, добавляешь в строку After зависимость.

В /etc/systemd/system же, оно ведь для локальных конфигов. И там выше уже разобрались.

Широкий глюк, который в центоси везде (да и в других дистрах тоже) в том, что написано After=network.target в связи с чем сетевые сервисы не стартуют автоматически, если привязаны к конкретному интерфейсу (например, 172.19.11.5).

Дело в том, что network.target возвращает успешное выполнение СРАЗУ после запуска, не дожидаясь поднятия интерфейса. Если сервис привязан к *, то 127.0.0.1 есть и сервис стартует. В противном случае, напишет в сислог «no such interface». Лечится заменой на After=network-online.target - этот таргет ждёт поднятия интерфейсов и привязанные к конкретным IP сервисы стартуют без проблем.

Аффектится на очень многое, включая постфикс, sshd (да-да, прописав в sshd_config привязку к IP можно потерять управление сервером %) ), мускль и частично OpenVPN.

Да, действительно, на Debian - то же самое в юнитах. Но моего случая это не касается, потому как от container0 зависит достижение таргета network-online и перед запуском контейнеров нужно только что бы были интерфейсы.

Сдохни, тварь.

Позже.

Сделай override на конкретные экземпляры.

Уже.

Спсисок костылей был бы неполным без ifupdown с networking.service, который тоже WantedBy=network-online.target.

и первый ещё короче, чем твой вариант lxd

я не согласен. потому что из всего листинга, конфигом который надо писать — является только 02-veth.network
при этом, не нужно думать о конкретных vm, всего один* интерфейс.

sudo ovs-vsctl --may-exist add-port ovs-bridge0 veth1 -- set Interface veth1 type=internal
lxc profile device set privileged lxd-veth1 nictype macvlan
lxc profile device set privileged lxd-veth1 parent veth1

Ну хорошо, возможно lxd и проще. Но lxc уже работает как нужно и пока причин для замены нет.

а то, что у тебя есть причины не использовать свитч между lxc системами, но при этом есть необходимость в их приоритезации загрузки уже наводит на мысль что здесь что-то нетак. наверное тебе стоит рассказать, может поможем.

Окей, проясню. container0 - это «роутер», container1 - это «сервер», хост - это клиент. Причиной делать такое стал OpenVPN клиент, который блокирует входящие соединения на физическом интерфейсе. Я честно пытался найти более адекватное решение, но лучшим - рабочим - вариантом оказались netns, которые можно использовать без контейнеров, но не так удобно. Поэтому есть container0, который фильтрует и маршрутизует, внутри которого физический интерфейс enp11s0 и два veth интерфейса, объединённых в мост, со вторыми концами в хосте и «сервере» соответственно.

может поможем

OpenVPN

https://www.youtube.com/watch?v=HcfHBgUTn7I

С ним всё так плохо?

мой совет будет таким: настроил, работает — не трожь
лучше месяц потратить на lxc, чем два на кусок говна, как OpenVPN
lxc хотя бы люди делают, а не рептилоиды.