The steps outlined in the initial bug report reliably (100%) reproduce the
problem for me on Ubuntu 16.04, it is tested in different Environments (1xAMD,
ca. 10xIntel).
Here's the short way to get there:
- Install a basic Ubuntu 16.04 Server
- apt-get install virt-manager (installing the GUI pulls in the heavy lifting
components)
- create a libvirt/lxc container of something like
<domain type='lxc'>
<name>AnyName</name>
<memory unit='KiB'>2097152</memory>
<currentMemory unit='KiB'>2097152</currentMemory>
<vcpu placement='static'>4</vcpu>
<resource>
<partition>/machine</partition>
</resource>
<os>
<type arch='x86_64'>exe</type>
<init>/sbin/init</init>
</os>
<features>
<privnet/>
</features>
<clock offset='utc'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
<devices>
<filesystem type='file' accessmode='passthrough'>
<driver type='loop' format='raw'/>
<source file='/path/to/image.raw'/>
<target dir='/'/>
</filesystem>
<interface type='bridge'>
<mac address='00:16:3e:34:ea:4b'/>
<source bridge='br1'/>
<target dev='vnet2'/>
<guest dev='eth0'/>
</interface>
<console type='pty' tty='/dev/pts/3'>
<source path='/dev/pts/3'/>
<target type='lxc' port='0'/>
<alias name='console0'/>
</console>
<hostdev mode='capabilities' type='misc'>
<source>
<char>/dev/net/tun</char>
</source>
</hostdev>
</devices>
</domain>
(I have experimented quite a lot, and it boils down to the loop-mounted
file system)
- Start the container via virsh or virt-manager
- Restart libvirtd
- Examine state of the container in virsh or virt-manager vs. the state of the
loop device via losetup
The important parts are:
- The container is shown as stopped
- The container dosen't reply to network requests or console connection
requests (i.e. it seems truly dead)
- The loop device doesn't show up in host-side "mount | grep loop"
- libvirtd allows to (re-)start the container, ending up with a double-
mounted file system
Migrating to lxd is not feasable in many environments, in addition to
that i am totally aware (and not critisizing!), that libvirt-lxc was/is
unsupported. For me the real bug is, that this scenario is possible: If
Ubuntu were to just exclude libvirt's lxc driver, that would be not
really fine, but at least fool-proof.
The blocker to lxd adoption is not on the admin side (me), but on the
end user side: Virt-manager is the favorite toy for SMB/NGO local
admins, typically run via XQuartz on a Mac or XMing on Windows.
Please let me know, if and when I can be of further help - I am willing
to test and have quite a few testbeds at hand, where I can easily create
throw-away containers and ruin them. Since I tripped over this, I
migrated around to have one node running no containers at every single
customer, just to do exactly that.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1680997
Title:
Container file system corruption on libvirtd restart
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1680997/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
