LXC support for openmediavault-kvm plugin

wojciszpl For a static IP in a debian lxc container see this RE: Using Pi-hole as DNS server for OMV

Krisbee, thanks for posting, I'll read it, but I'd prefer to stay with just static MAC and IP collect from DHCP (I have reservation made for it)

Thanks to this I can manage all the IP's from one place.

I made few additional reboots and checks and I found the schema:

1. After reboot of OMV, LXC container is collecting random MAC adress -> so finally also random IP from DHCP. It looks like MAC adress from XML (plugin) is completely ignored

2. Reboting LXC results in different (random) mac each time

3. I have to go to the XML (in plugin), do something (at least add space and remove it) do make "Save" button enabled, save it and now reboot LXC container

4. After this, my LXC container have a good MAC and IP adress

So it looks like after reboot of all the system, settings from XML are ignored and it is needed to open/save it from plugin so they are used.

Can You take a look@it @ryecoaaron ?

PS: I have also a lot of warning in my journal related to libvirt - is it normal?

25 października 2024
21:27
this function is not supported by the connection driver: virDomainGetMessages
libvirtd
47
21:27
End of file while reading data: Błąd wejścia/wyjścia
libvirtd
21:26
this function is not supported by the connection driver: virDomainGetMessages
libvirtd
5
21:26
End of file while reading data: Błąd wejścia/wyjścia
libvirtd
21:25
this function is not supported by the connection driver: virDomainGetMessages
libvirtd
10
21:20
Unable to remove /sys/fs/cgroup/machine.slice/machine-lxc\x2d17253\x2dadguard.scope/libvirt/init.scope/ (16)
libvirtd
8
21:20
Unable to remove /sys/fs/cgroup/machine.slice/machine-lxc\x2d17253\x2dadguard.scope/libvirt/system.slice/ (16)
libvirtd
21:20
Unable to remove /sys/fs/cgroup/machine.slice/machine-lxc\x2d17253\x2dadguard.scope/libvirt/system.slice//tailscaled.service (16)
libvirtd
21:20
Unable to remove /sys/fs/cgroup/machine.slice/machine-lxc\x2d17253\x2dadguard.scope/libvirt/system.slice/tailscaled.service/ (16)
libvirtd
21:20
Unable to remove /sys/fs/cgroup/machine.slice/machine-lxc\x2d17253\x2dadguard.scope/libvirt/system.slice/systemd-journald.service/ (16)
libvirtd
21:20
Unable to remove /sys/fs/cgroup/machine.slice/machine-lxc\x2d17253\x2dadguard.scope/libvirt/init.scope/ (16)
libvirtd
21:20
End of file while reading data: Błąd wejścia/wyjścia
libvirtd
2
21:17
this function is not supported by the connection driver: virDomainGetMessages
libvirtd
18

This behavior of the mac being ignored is new. I have been running a pihole lxc and a nextcloud lxc using my router to issue a static ip based on the lxc mac for 2 years, but saw the same thing in my last reboot a few days ago on just the nextcoud lxc.

Quote from ryecoaaron

Hard to say since I don't know what you were doing when the messages happened. None of them look harmful though.

All of them appears during process of making of using the lxc containers via plugin. Are You aware of this issue of ignoring mac from XML? As I see, BernH is confirming he has same problem from a while.

BernH Did You solve it or claimed to anybody?

ryecoaaron I don't know what lxc images others are using, or if they tested more than one Linux flavour, but out of deb 12, ubuntu 22.04 and alpine 318 only ubuntu appears NOT to have the problem of the mac address changing after a reboot with the container's default DHCP net config. ( Alpine has other quirks: the image auto root passwd change to "openmediavault" does not work, error spawning with tty's, reboot and poweroff commands needing full path in default ash shell. )

I guess people don't wan't/like the workaround of using static ip configs in their lxc containers as they want control/visibility in their router/firewall.

Quote from Krisbee

ryecoaaron I don't know what lxc images others are using, or if they tested more than one Linux flavour, but out of deb 12, ubuntu 22.04 and alpine 318 only ubuntu appears NOT to have the problem of the mac address changing after a reboot with the container's default DHCP net config. ( Alpine has other quirks: the image auto root passwd change to "openmediavault" does not work, error spawning with tty's, reboot and poweroff commands needing full path in default ash shell. )

I guess people don't wan't/like the workaround of using static ip configs in their lxc containers as they want control/visibility in their router/firewall.

My Nextcloud lxc is Ubuntu 22.04 but my pihole is Debian 12 so I would suspect the problem is not the lxc image, but a bug in libvirt or qemu. Given that with the info at hand it even appears to be intermittent or perhaps hardware environment related (ie. you saying Ubuntu doesn’t have an issue me saying it did with my system), this may not be something that is easily fixable.

I have not done any investigation into it as it was only one reboot I did where I noticed it. I just “fixed” the IP with a router reboot as I have seen routers misbehave too. My router had the correct reservation in place but another dynamic entry for the lxc, yet the lxc was showing a correct MAC address. It was as if the MAC address changed from wrong to right after the ip address was negotiated.

All that said, I have not had the time to do any further investigation, and seeing as this is the second thread I have seen with lxc changing IP complaints, I suspect it isn’t just my system.

I also have not tried to find out if anyone has reported to the projects, so don’t know if it is on the radar for a fix.

Quote from BernH

This behavior of the mac being ignored is new. I have been running a pihole lxc and a nextcloud lxc using my router to issue a static ip based on the lxc mac for 2 years, but saw the same thing in my last reboot a few days ago on just the nextcoud lxc.

This makes me feel a bit better. I've just started trying lxc in OMV, using the pihole example and using Debian 12. I was sure I had it working correct, but took it down and redid it a week or so later, but couldn't get a static ip address, I didn't check the mac address, but that would make complete sense.

I'll see what happens in thread and try again some other time, I running pihole and tailscale on a raspi, and a old nuc, but rather have the pi version as a lxc, I did have it running via docker, but I think a lxc is a better solution.

Well done people for noticing this, made a bloke feel not quite so simple

Quote from trythat

This makes me feel a bit better. I've just started trying lxc in OMV, using the pihole example and using Debian 12. I was sure I had it working correct, but took it down and redid it a week or so later, but couldn't get a static ip address, I didn't check the mac address, but that would make complete sense.

I'll see what happens in thread and try again some other time, I running pihole and tailscale on a raspi, and a old nuc, but rather have the pi version as a lxc, I did have it running via docker, but I think a lxc is a better solution.

Well done people for noticing this, made a bloke feel not quite so simple

You don't have to wait for the solution of this issue, is You're ok with setting static IP directly in the LCX container, instead of DHCP.

I also prefered to used static MAC and reservation on DHCP but who knows when this problem will be solved.

So I've just decided to change network config in container and replaced DHCP with static adress - works fine for few days without single issue.

Quote from wojciszpl

You don't have to wait for the solution of this issue, is You're ok with setting static IP directly in the LCX container, instead of DHCP.

I also prefered to used static MAC and reservation on DHCP but who knows when this problem will be solved.

So I've just decided to change network config in container and replaced DHCP with static adress - works fine for few days without single issue.

Thats what I thought about doing, I think I'll spin up a lxc container again and do as you say and retire the for another project.

Quote from ryecoaaron

No. It seems to be a change in libvirt or qemu and likely a bug. I can't really change something in the plugin to fix this. I tried finding more info but didn't find any.

Seems to be fixed in latest set of debian 12.8 updates.