As discussed on IRC, the container created on the target will not be
created as a snapshot of the image LV, it will instead be a fresh empty
LV with a full copy of the source container. This is suboptimal and it
is planned to improve it, but aside from the additional transfer time
for the rsync and the space inefficiency, the container should still
work.
However, in IRC, jamespage mentioned that he thought it wasn't working,
so I've marked the bug as incomplete pending a re-check:
[09:18:59] > hi jamespage is the issue with that bug that the resulting LV is
not COW? If so, that's known and it's a planned optimization to first do a
snapshot of the base image at the target and then do the rsync. but we haven't
gotten to those migration optimizations in any of the storage backends yet. Is
this blocking anything?
[09:19:59] <jamespage> mmcc, the container was migrated between two hosts; on
the first host it worked ok; on the target it lost its parent - I don't think
its at-all functional now
[09:20:22] <jamespage> but I'd have to check
** Changed in: lxd (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1499359
Title:
LVM based container migration lose parent block device
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1499359/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
