-
Notifications
You must be signed in to change notification settings - Fork 41
Incorrect assumptions about 'machines.raw' #293
Comments
From my understanding, that failure is just another regression caused by #265. Before the refactoring PR, After the PR, that's not the case any more. The original check for the existing image has disappered. So kube-spawn tries to unmount the image even if it does not exist. As a result, we see a failure like this. Adding a simple check for the volume image could resolve this issue. Writing a document is of course good, but I'm afraid that's not enough. In practice, most users would just start kube-spawn with ext4 on the host filesystem, not btrfs. Then systemd-machined will create the loopback mount automatically, and kube-spawn will end up having issues like #281. Not every user is capable of manually resizing the volume. Thus it is really necessary for kube-spawn to resize the volume like #283. Sorry, but I'm on vacation right now. So I'm not sure I can work on it in 2 weeks. |
Systemd prior to version 240 was creating /var/lib/machines.raw as btrfs volume for storing machined disks. However, this functionality is now remove and now it stores it as regular files. More details here: https://github.com/systemd/systemd/blob/401faa3533280b05fee972e0c64885caf4b31e4c/units/var-lib-machines.mount#L10 Additionally, it someone already have /var/lib/machines baked by btrfs, machined won't create machines.raw, which will also cause setting up cluster to fail. This patch adds check, if machineImage exists and it not, it fallbacks to just checking disk space available for /var/lib/machines. Closes kinvolk#339 kinvolk#293 Signed-off-by: Mateusz Gozdek <[email protected]>
Systemd prior to version 240 was creating /var/lib/machines.raw as btrfs volume for storing machined disks. However, this functionality is now remove and now it stores it as regular files. More details here: https://github.com/systemd/systemd/blob/401faa3533280b05fee972e0c64885caf4b31e4c/units/var-lib-machines.mount#L10 Additionally, it someone already have /var/lib/machines baked by btrfs, machined won't create machines.raw, which will also cause setting up cluster to fail. This patch adds check, if machineImage exists and it not, it fallbacks to just checking disk space available for /var/lib/machines. Refs kinvolk#339 kinvolk#293 Signed-off-by: Mateusz Gozdek <[email protected]>
Systemd prior to version 240 was creating /var/lib/machines.raw as btrfs volume for storing machined disks. However, this functionality is now remove and now it stores it as regular files. More details here: https://github.com/systemd/systemd/blob/401faa3533280b05fee972e0c64885caf4b31e4c/units/var-lib-machines.mount#L10 Additionally, it someone already have /var/lib/machines baked by btrfs, machined won't create machines.raw, which will also cause setting up cluster to fail. This patch adds check, if machineImage exists and it not, it fallbacks to just checking disk space available for /var/lib/machines. Refs kinvolk#339 kinvolk#293 Signed-off-by: Mateusz Gozdek <[email protected]>
Systemd prior to version 240 was creating /var/lib/machines.raw as btrfs volume for storing machined disks. However, this functionality is now remove and now it stores it as regular files. More details here: https://github.com/systemd/systemd/blob/401faa3533280b05fee972e0c64885caf4b31e4c/units/var-lib-machines.mount#L10 Additionally, it someone already have /var/lib/machines baked by btrfs, machined won't create machines.raw, which will also cause setting up cluster to fail. This patch adds check, if machineImage exists and it not, it fallbacks to just checking disk space available for /var/lib/machines. Refs kinvolk#339 kinvolk#293 Signed-off-by: Mateusz Gozdek <[email protected]>
Recent commit assumes that /var/lib/machines is loopback mounted onto /var/lib/machines.raw. But many people will have /var/lib/machines as its own btrfs partition:
So now it fails with:
instead
I don't think this approach is correct. It assumes this application is the only thing using nspawn, it tries to unmount /var/lib/machines which won't work if other containers are running.
I think this should just be documented. The documented approach is to run:
machinectl set-limit 20G
which, if you are using the /var/lib/machines.raw loopback mount method.The text was updated successfully, but these errors were encountered: