[libvirt] Problems with <filesystem type='block'>
Using libvirt 1.0.1, I'm trying to start an LXC container using the '<filesytem type="block">' syntax, like this: <filesystem type="block" accessmode="passthrough"> <source dev="/dev/vg_files/vm-foobar-root" /> <target dir="/" /> </filesystem> The specified block device exists: # ls -lL /dev/vg_files/vm-foobar-root brw-rw---- 1 root disk 253, 19 Dec 21 22:23 /dev/vg_files/vm-foobar-root If I start the domain, it appears to start without any errors... # virsh start foobar Domain foobar started ...but it's not actually running. The log files (with loglevel=2) don't seem to be very interesting; this is everything from the instance log file: 2012-12-22 04:10:57.862+0000: starting up PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin LIBVIRT_DEBUG=2 LIBVIRT_LOG_OUTPUTS=2:stderr /usr/lib/libvirt/libvirt_lxc --name foobar --console 22 --security=none --handshake 25 --background --veth veth1 2012-12-22 04:10:57.967+0000: 1468: info : libvirt version: 1.0.1 2012-12-22 04:10:57.967+0000: 1468: info : lxcCapsInit:151 : No driver, not initializing security driver PATH=/bin:/sbin TERM=linux container=lxc-libvirt container_uuid=9041e32e-1df2-00c2-4660-dfa5b41510b7 LIBVIRT_LXC_UUID=9041e32e-1df2-00c2-4660-dfa5b41510b7 LIBVIRT_LXC_NAME=foobar /sbin/init 2012-12-22 04:10:58.198+0000: 1: warning : lxcContainerDropCapabilities:1788 : libcap-ng support not compiled in, unable to clear capabilities 2012-12-22 04:10:58.198+0000: 1493: warning : lxcControllerClearCapabilities:679 : libcap-ng support not compiled in, unable to clear capabilities Running an "strace" on the libvirtd process (strace -p <libvirtd_pid> -f ...), it doesn't look like libvirt is ever trying to mount the referenced filesystem. Is this supposed to work? It seems like the support for having libvirt mount the block device is relatively recent, and I haven't had much luck finding examples of other folks using this capability. Thanks, -- Lars
On Fri, Dec 21, 2012 at 10:15 PM, Lars Kellogg-Stedman <lars@oddbit.com> wrote:
Using libvirt 1.0.1, I'm trying to start an LXC container using the '<filesytem type="block">' syntax, like this:
<filesystem type="block" accessmode="passthrough"> <source dev="/dev/vg_files/vm-foobar-root" /> <target dir="/" /> </filesystem>
The specified block device exists:
# ls -lL /dev/vg_files/vm-foobar-root brw-rw---- 1 root disk 253, 19 Dec 21 22:23 /dev/vg_files/vm-foobar-root
If I start the domain, it appears to start without any errors...
# virsh start foobar Domain foobar started
...but it's not actually running. The log files (with loglevel=2) don't seem to be very interesting; this is everything from the instance log file:
2012-12-22 04:10:57.862+0000: starting up PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin LIBVIRT_DEBUG=2 LIBVIRT_LOG_OUTPUTS=2:stderr /usr/lib/libvirt/libvirt_lxc --name foobar --console 22 --security=none --handshake 25 --background --veth veth1 2012-12-22 04:10:57.967+0000: 1468: info : libvirt version: 1.0.1 2012-12-22 04:10:57.967+0000: 1468: info : lxcCapsInit:151 : No driver, not initializing security driver PATH=/bin:/sbin TERM=linux container=lxc-libvirt container_uuid=9041e32e-1df2-00c2-4660-dfa5b41510b7 LIBVIRT_LXC_UUID=9041e32e-1df2-00c2-4660-dfa5b41510b7 LIBVIRT_LXC_NAME=foobar /sbin/init 2012-12-22 04:10:58.198+0000: 1: warning : lxcContainerDropCapabilities:1788 : libcap-ng support not compiled in, unable to clear capabilities 2012-12-22 04:10:58.198+0000: 1493: warning : lxcControllerClearCapabilities:679 : libcap-ng support not compiled in, unable to clear capabilities
Running an "strace" on the libvirtd process (strace -p <libvirtd_pid> -f ...), it doesn't look like libvirt is ever trying to mount the referenced filesystem.
Is this supposed to work? It seems like the support for having libvirt mount the block device is relatively recent, and I haven't had much luck finding examples of other folks using this capability.
Thanks,
-- Lars
Lars, I just gave it a whirl. And I'm able to reproduce the same issue you are seeing. The issue appears to be that lxcContainerMountFsBlockAuto() is never being called. It was added in http://www.redhat.com/archives/libvir-list/2011-August/msg00201.html Hopefully I'll have more info soon. -- Doug Goldstein
On Sun, Mar 3, 2013 at 5:24 PM, Doug Goldstein <cardoe@gentoo.org> wrote:
On Fri, Dec 21, 2012 at 10:15 PM, Lars Kellogg-Stedman <lars@oddbit.com> wrote:
Using libvirt 1.0.1, I'm trying to start an LXC container using the '<filesytem type="block">' syntax, like this:
<filesystem type="block" accessmode="passthrough"> <source dev="/dev/vg_files/vm-foobar-root" /> <target dir="/" /> </filesystem>
The specified block device exists:
# ls -lL /dev/vg_files/vm-foobar-root brw-rw---- 1 root disk 253, 19 Dec 21 22:23 /dev/vg_files/vm-foobar-root
If I start the domain, it appears to start without any errors...
# virsh start foobar Domain foobar started
...but it's not actually running. The log files (with loglevel=2) don't seem to be very interesting; this is everything from the instance log file:
2012-12-22 04:10:57.862+0000: starting up PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin LIBVIRT_DEBUG=2 LIBVIRT_LOG_OUTPUTS=2:stderr /usr/lib/libvirt/libvirt_lxc --name foobar --console 22 --security=none --handshake 25 --background --veth veth1 2012-12-22 04:10:57.967+0000: 1468: info : libvirt version: 1.0.1 2012-12-22 04:10:57.967+0000: 1468: info : lxcCapsInit:151 : No driver, not initializing security driver PATH=/bin:/sbin TERM=linux container=lxc-libvirt container_uuid=9041e32e-1df2-00c2-4660-dfa5b41510b7 LIBVIRT_LXC_UUID=9041e32e-1df2-00c2-4660-dfa5b41510b7 LIBVIRT_LXC_NAME=foobar /sbin/init 2012-12-22 04:10:58.198+0000: 1: warning : lxcContainerDropCapabilities:1788 : libcap-ng support not compiled in, unable to clear capabilities 2012-12-22 04:10:58.198+0000: 1493: warning : lxcControllerClearCapabilities:679 : libcap-ng support not compiled in, unable to clear capabilities
Running an "strace" on the libvirtd process (strace -p <libvirtd_pid> -f ...), it doesn't look like libvirt is ever trying to mount the referenced filesystem.
Is this supposed to work? It seems like the support for having libvirt mount the block device is relatively recent, and I haven't had much luck finding examples of other folks using this capability.
Thanks,
-- Lars
Lars,
I just gave it a whirl. And I'm able to reproduce the same issue you are seeing. The issue appears to be that lxcContainerMountFsBlockAuto() is never being called. It was added in http://www.redhat.com/archives/libvir-list/2011-August/msg00201.html Hopefully I'll have more info soon.
-- Doug Goldstein
It appears in the case of filesystem type=block the libvirt_lxc helper just gets wedged right away from first execution. 2013-03-04 04:17:55.443+0000: 7197: debug : virFileMakePathHelper:1272 : path=/v ar/run/libvirt/lxc mode=0777 2013-03-04 04:17:55.443+0000: 7197: debug : virFileClose:72 : Closed fd 18 2013-03-04 04:17:55.443+0000: 7197: debug : virCommandRunAsync:2200 : About to r un PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/u sr/x86_64-pc-linux-gnu/gcc-bin/4.6.3 LIBVIRT_DEBUG=1 LIBVIRT_LOG_OUTPUTS=1:stderr /usr/libexec/libvirt_lxc --name testdeb --console 17 --security=none --handshake 20 --background --veth veth1 2013-03-04 04:17:55.444+0000: 7197: debug : virFileClose:72 : Closed fd 21 2013-03-04 04:17:55.444+0000: 7197: debug : virCommandRunAsync:2218 : Command result 0, with PID 7294 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 3 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 4 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 5 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 6 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 7 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 8 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 9 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 10 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 11 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 12 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 13 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 14 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 15 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 16 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 19 That's the last time anything with PID 7294 or lxc appears in the log file. I'm unfortunately not getting any lxcContainer debug messages in the log using LIBVIRT_DEBUG=1 LIBVIRT_LOG_OUTPUT=1:stderr -- Doug Goldstein
Hi Doug, On 2013/03/04 12:38, Doug Goldstein wrote:
On Sun, Mar 3, 2013 at 5:24 PM, Doug Goldstein <cardoe@gentoo.org> wrote:
On Fri, Dec 21, 2012 at 10:15 PM, Lars Kellogg-Stedman <lars@oddbit.com> wrote:
Using libvirt 1.0.1, I'm trying to start an LXC container using the '<filesytem type="block">' syntax, like this:
<filesystem type="block" accessmode="passthrough"> <source dev="/dev/vg_files/vm-foobar-root" /> <target dir="/" /> </filesystem>
The specified block device exists:
# ls -lL /dev/vg_files/vm-foobar-root brw-rw---- 1 root disk 253, 19 Dec 21 22:23 /dev/vg_files/vm-foobar-root
If I start the domain, it appears to start without any errors...
# virsh start foobar Domain foobar started
...but it's not actually running. The log files (with loglevel=2) don't seem to be very interesting; this is everything from the instance log file:
2012-12-22 04:10:57.862+0000: starting up PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin LIBVIRT_DEBUG=2 LIBVIRT_LOG_OUTPUTS=2:stderr /usr/lib/libvirt/libvirt_lxc --name foobar --console 22 --security=none --handshake 25 --background --veth veth1 2012-12-22 04:10:57.967+0000: 1468: info : libvirt version: 1.0.1 2012-12-22 04:10:57.967+0000: 1468: info : lxcCapsInit:151 : No driver, not initializing security driver PATH=/bin:/sbin TERM=linux container=lxc-libvirt container_uuid=9041e32e-1df2-00c2-4660-dfa5b41510b7 LIBVIRT_LXC_UUID=9041e32e-1df2-00c2-4660-dfa5b41510b7 LIBVIRT_LXC_NAME=foobar /sbin/init 2012-12-22 04:10:58.198+0000: 1: warning : lxcContainerDropCapabilities:1788 : libcap-ng support not compiled in, unable to clear capabilities 2012-12-22 04:10:58.198+0000: 1493: warning : lxcControllerClearCapabilities:679 : libcap-ng support not compiled in, unable to clear capabilities
Running an "strace" on the libvirtd process (strace -p <libvirtd_pid> -f ...), it doesn't look like libvirt is ever trying to mount the referenced filesystem.
Is this supposed to work? It seems like the support for having libvirt mount the block device is relatively recent, and I haven't had much luck finding examples of other folks using this capability.
Thanks,
-- Lars
Lars,
I just gave it a whirl. And I'm able to reproduce the same issue you are seeing. The issue appears to be that lxcContainerMountFsBlockAuto() is never being called. It was added in http://www.redhat.com/archives/libvir-list/2011-August/msg00201.html Hopefully I'll have more info soon.
-- Doug Goldstein
It appears in the case of filesystem type=block the libvirt_lxc helper just gets wedged right away from first execution.
2013-03-04 04:17:55.443+0000: 7197: debug : virFileMakePathHelper:1272 : path=/v ar/run/libvirt/lxc mode=0777 2013-03-04 04:17:55.443+0000: 7197: debug : virFileClose:72 : Closed fd 18 2013-03-04 04:17:55.443+0000: 7197: debug : virCommandRunAsync:2200 : About to r un PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/u sr/x86_64-pc-linux-gnu/gcc-bin/4.6.3 LIBVIRT_DEBUG=1 LIBVIRT_LOG_OUTPUTS=1:stderr /usr/libexec/libvirt_lxc --name testdeb --console 17 --security=none --handshake 20 --background --veth veth1 2013-03-04 04:17:55.444+0000: 7197: debug : virFileClose:72 : Closed fd 21 2013-03-04 04:17:55.444+0000: 7197: debug : virCommandRunAsync:2218 : Command result 0, with PID 7294 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 3 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 4 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 5 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 6 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 7 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 8 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 9 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 10 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 11 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 12 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 13 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 14 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 15 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 16 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 19
That's the last time anything with PID 7294 or lxc appears in the log file. I'm unfortunately not getting any lxcContainer debug messages in the log using LIBVIRT_DEBUG=1 LIBVIRT_LOG_OUTPUT=1:stderr
Did you check the last version libvirt? I can't reproduce this problem with last libvirt. Thanks! Gao
On Sun, Mar 3, 2013 at 11:19 PM, Gao feng <gaofeng@cn.fujitsu.com> wrote:
Hi Doug,
On 2013/03/04 12:38, Doug Goldstein wrote:
On Sun, Mar 3, 2013 at 5:24 PM, Doug Goldstein <cardoe@gentoo.org> wrote:
On Fri, Dec 21, 2012 at 10:15 PM, Lars Kellogg-Stedman <lars@oddbit.com> wrote:
Using libvirt 1.0.1, I'm trying to start an LXC container using the '<filesytem type="block">' syntax, like this:
<filesystem type="block" accessmode="passthrough"> <source dev="/dev/vg_files/vm-foobar-root" /> <target dir="/" /> </filesystem>
The specified block device exists:
# ls -lL /dev/vg_files/vm-foobar-root brw-rw---- 1 root disk 253, 19 Dec 21 22:23 /dev/vg_files/vm-foobar-root
If I start the domain, it appears to start without any errors...
# virsh start foobar Domain foobar started
...but it's not actually running. The log files (with loglevel=2) don't seem to be very interesting; this is everything from the instance log file:
2012-12-22 04:10:57.862+0000: starting up PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin LIBVIRT_DEBUG=2 LIBVIRT_LOG_OUTPUTS=2:stderr /usr/lib/libvirt/libvirt_lxc --name foobar --console 22 --security=none --handshake 25 --background --veth veth1 2012-12-22 04:10:57.967+0000: 1468: info : libvirt version: 1.0.1 2012-12-22 04:10:57.967+0000: 1468: info : lxcCapsInit:151 : No driver, not initializing security driver PATH=/bin:/sbin TERM=linux container=lxc-libvirt container_uuid=9041e32e-1df2-00c2-4660-dfa5b41510b7 LIBVIRT_LXC_UUID=9041e32e-1df2-00c2-4660-dfa5b41510b7 LIBVIRT_LXC_NAME=foobar /sbin/init 2012-12-22 04:10:58.198+0000: 1: warning : lxcContainerDropCapabilities:1788 : libcap-ng support not compiled in, unable to clear capabilities 2012-12-22 04:10:58.198+0000: 1493: warning : lxcControllerClearCapabilities:679 : libcap-ng support not compiled in, unable to clear capabilities
Running an "strace" on the libvirtd process (strace -p <libvirtd_pid> -f ...), it doesn't look like libvirt is ever trying to mount the referenced filesystem.
Is this supposed to work? It seems like the support for having libvirt mount the block device is relatively recent, and I haven't had much luck finding examples of other folks using this capability.
Thanks,
-- Lars
Lars,
I just gave it a whirl. And I'm able to reproduce the same issue you are seeing. The issue appears to be that lxcContainerMountFsBlockAuto() is never being called. It was added in http://www.redhat.com/archives/libvir-list/2011-August/msg00201.html Hopefully I'll have more info soon.
-- Doug Goldstein
It appears in the case of filesystem type=block the libvirt_lxc helper just gets wedged right away from first execution.
2013-03-04 04:17:55.443+0000: 7197: debug : virFileMakePathHelper:1272 : path=/v ar/run/libvirt/lxc mode=0777 2013-03-04 04:17:55.443+0000: 7197: debug : virFileClose:72 : Closed fd 18 2013-03-04 04:17:55.443+0000: 7197: debug : virCommandRunAsync:2200 : About to r un PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/u sr/x86_64-pc-linux-gnu/gcc-bin/4.6.3 LIBVIRT_DEBUG=1 LIBVIRT_LOG_OUTPUTS=1:stderr /usr/libexec/libvirt_lxc --name testdeb --console 17 --security=none --handshake 20 --background --veth veth1 2013-03-04 04:17:55.444+0000: 7197: debug : virFileClose:72 : Closed fd 21 2013-03-04 04:17:55.444+0000: 7197: debug : virCommandRunAsync:2218 : Command result 0, with PID 7294 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 3 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 4 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 5 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 6 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 7 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 8 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 9 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 10 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 11 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 12 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 13 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 14 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 15 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 16 2013-03-04 04:17:55.444+0000: 7294: debug : virFileClose:72 : Closed fd 19
That's the last time anything with PID 7294 or lxc appears in the log file. I'm unfortunately not getting any lxcContainer debug messages in the log using LIBVIRT_DEBUG=1 LIBVIRT_LOG_OUTPUT=1:stderr
Did you check the last version libvirt? I can't reproduce this problem with last libvirt.
Thanks! Gao
So still trying to figure out what I'm doing wrong with LXC because I just can't get any joy. So I'll go one issue at a time. The following VM definition: <domain type='lxc'> <name>testdeb</name> <uuid>df03b2ce-725a-42e2-39e4-d646be8facb3</uuid> <memory unit='KiB'>332768</memory> <currentMemory unit='KiB'>332768</currentMemory> <vcpu placement='static'>1</vcpu> <os> <type arch='x86_64'>exe</type> <init>/sbin/init</init> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <devices> <emulator>/usr/libexec/libvirt_lxc</emulator> <filesystem type='block' accessmode='passthrough'> <source dev='/dev/mapper/vms-testdeb'/> <target dir='/'/> </filesystem> <interface type='network'> <mac address='52:54:00:95:d5:f2'/> <source network='default'/> </interface> <console type='pty'> <target type='lxc' port='0'/> </console> </devices> </domain> Results in /dev/mapper/vms-testdeb being mounted right over my host's / partition. Here's the output from mount: rootfs on / type rootfs (rw) /dev/sda3 on / type ext4 (rw,noatime,data=ordered) udev on /dev type devtmpfs (rw,nosuid,relatime,size=10240k,nr_inodes=497278,mode=755) devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755) /dev/mapper/vms-testdeb on / type ext4 (rw,relatime,data=ordered) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) proc on /proc/sys type proc (ro,relatime) sysfs on /sys type sysfs (ro,relatime) tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,relatime,size=64k,mode=755) cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,relatime,cpuset) cgroup on /sys/fs/cgroup/cpu type cgroup (rw,relatime,cpu) cgroup on /sys/fs/cgroup/cpuacct type cgroup (rw,relatime,cpuacct) cgroup on /sys/fs/cgroup/memory type cgroup (rw,relatime,memory) cgroup on /sys/fs/cgroup/devices type cgroup (rw,relatime,devices) cgroup on /sys/fs/cgroup/freezer type cgroup (rw,relatime,freezer) cgroup on /sys/fs/cgroup/blkio type cgroup (rw,relatime,blkio) cgroup on /sys/fs/cgroup/net_prio type cgroup (rw,relatime,net_prio) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nodev,noexec,nosuid) Now if I do the following: # mkdir /mnt/testdeb # mount /dev/mapper/vms-testdeb /mnt/testdeb And change the definition to: <filesystem type='mount' accessmode='passthrough'> <source dir='/mnt/testdeb'/> <target dir='/'/> </filesystem> It at least appears to work. The LXC domain boots but believes it only has R/O access to its /. As a side note, I created it with: # mount /dev/mapper/vms-testdeb /mnt/testdeb # debootstrap squeeze /mnt/testdeb -- Doug Goldstein
On Thu, Mar 21, 2013 at 11:50:40PM -0500, Doug Goldstein wrote:
So still trying to figure out what I'm doing wrong with LXC because I just can't get any joy. So I'll go one issue at a time.
The following VM definition: <domain type='lxc'> <name>testdeb</name> <uuid>df03b2ce-725a-42e2-39e4-d646be8facb3</uuid> <memory unit='KiB'>332768</memory> <currentMemory unit='KiB'>332768</currentMemory> <vcpu placement='static'>1</vcpu> <os> <type arch='x86_64'>exe</type> <init>/sbin/init</init> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <devices> <emulator>/usr/libexec/libvirt_lxc</emulator> <filesystem type='block' accessmode='passthrough'> <source dev='/dev/mapper/vms-testdeb'/> <target dir='/'/> </filesystem>
So, it seems I only tested 'type=block with non-/ filesystem mounts. I can confirm it is broken for <target dir="/"/>. The fix is not exactly trivial, so might take me a while
Now if I do the following: # mkdir /mnt/testdeb # mount /dev/mapper/vms-testdeb /mnt/testdeb
And change the definition to:
<filesystem type='mount' accessmode='passthrough'> <source dir='/mnt/testdeb'/> <target dir='/'/> </filesystem>
It at least appears to work. The LXC domain boots but believes it only has R/O access to its /.
What does /proc/mounts say inside the container for '/' ? When I do this I get a full R+W filesystem in the container Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Fri, Mar 22, 2013 at 11:59:56AM +0000, Daniel P. Berrange wrote:
On Thu, Mar 21, 2013 at 11:50:40PM -0500, Doug Goldstein wrote:
So still trying to figure out what I'm doing wrong with LXC because I just can't get any joy. So I'll go one issue at a time.
The following VM definition: <domain type='lxc'> <name>testdeb</name> <uuid>df03b2ce-725a-42e2-39e4-d646be8facb3</uuid> <memory unit='KiB'>332768</memory> <currentMemory unit='KiB'>332768</currentMemory> <vcpu placement='static'>1</vcpu> <os> <type arch='x86_64'>exe</type> <init>/sbin/init</init> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <devices> <emulator>/usr/libexec/libvirt_lxc</emulator> <filesystem type='block' accessmode='passthrough'> <source dev='/dev/mapper/vms-testdeb'/> <target dir='/'/> </filesystem>
So, it seems I only tested 'type=block with non-/ filesystem mounts. I can confirm it is broken for <target dir="/"/>.
The fix is not exactly trivial, so might take me a while
Ok, I've pushed 5 changes which fix this setup for me, so hopefully it will work for you too. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Fri, Mar 22, 2013 at 12:27 PM, Daniel P. Berrange <berrange@redhat.com> wrote:
On Fri, Mar 22, 2013 at 11:59:56AM +0000, Daniel P. Berrange wrote:
On Thu, Mar 21, 2013 at 11:50:40PM -0500, Doug Goldstein wrote:
So still trying to figure out what I'm doing wrong with LXC because I just can't get any joy. So I'll go one issue at a time.
The following VM definition: <domain type='lxc'> <name>testdeb</name> <uuid>df03b2ce-725a-42e2-39e4-d646be8facb3</uuid> <memory unit='KiB'>332768</memory> <currentMemory unit='KiB'>332768</currentMemory> <vcpu placement='static'>1</vcpu> <os> <type arch='x86_64'>exe</type> <init>/sbin/init</init> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <devices> <emulator>/usr/libexec/libvirt_lxc</emulator> <filesystem type='block' accessmode='passthrough'> <source dev='/dev/mapper/vms-testdeb'/> <target dir='/'/> </filesystem>
So, it seems I only tested 'type=block with non-/ filesystem mounts. I can confirm it is broken for <target dir="/"/>.
The fix is not exactly trivial, so might take me a while
Ok, I've pushed 5 changes which fix this setup for me, so hopefully it will work for you too.
Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Daniel, So I've given the changes a shot with both filesystem types, block and mount and I'm running c9c87376f2b2197ad774533ad6a6dd2f631ca105. Both ways I get the following error: error: Failed to start domain testdeb error: internal error guest failed to start: PATH=/bin:/sbin TERM=linux container=lxc-libvirt container_uuid=df03b2ce-725a-42e2-39e4-d646be8facb3 LIBVIRT_LXC_UUID=df03b2ce-725a-42e2-39e4-d646be8facb3 LIBVIRT_LXC_NAME=testdeb /sbin/init error receiving signal from container: Input/output error The error message after the internal error guest failed to start", changes between runs. The following mount is left behind, one for each time I've tried to start the domain: libvirt on /run/libvirt/lxc/testdeb.fuse type fuse (rw,nosuid,nodev) And lastly the following is left behind: ls -l /var/run/libvirt/lxc/ total 0 drwxr-xr-x 2 root root 40 Mar 23 23:26 testdeb.devpts drwxr-xr-x 2 root root 40 Mar 23 23:26 testdeb.fuse srwx------ 1 root root 0 Mar 23 23:31 testdeb.sock # LIBVIRT_DEBUG=4 LIBVIRT_LOG_FILTERS=1:lxc LIBVIRT_LOG_OUTPUTS=1:stderr /usr/sbin/libvirtd | tee -a libvirtd.log 2013-03-23 21:32:38.863+0000: 22063: info : libvirt version: 1.0.3 2013-03-23 21:32:38.863+0000: 22063: debug : lxcContainerAvailable:2490 : container support is enabled 2013-03-23 21:32:38.889+0000: 22063: debug : lxcContainerAvailable:2490 : container support is enabled 2013-03-23 21:32:38.890+0000: 22063: info : lxcSecurityInit:1395 : lxcSecurityInit (null) 2013-03-23 21:32:38.890+0000: 22063: debug : lxcCapsInit:143 : Initialized caps for security driver "none" with DOI "0" 2013-03-23 21:32:38.892+0000: 22063: debug : virLXCProcessAutoDestroyRun:122 : conn=0x7f4efc0fb190 2013-03-23 21:32:46.294+0000: 22057: debug : virLXCProcessStart:1060 : Setting current domain def as transient 2013-03-23 21:32:46.295+0000: 22057: debug : virLXCProcessStart:1082 : Preparing host devices 2013-03-23 21:32:46.295+0000: 22057: debug : virLXCProcessStart:1100 : Generating domain security label (if required) 2013-03-23 21:32:46.295+0000: 22057: debug : virLXCProcessStart:1111 : Setting domain security labels 2013-03-23 21:32:46.295+0000: 22057: debug : virLXCProcessSetupInterfaceBridged:316 : calling vethCreate() 2013-03-23 21:32:46.297+0000: 22057: debug : virLXCProcessSetupInterfaceBridged:320 : parentVeth: veth1, containerVeth: veth2 2013-03-23 21:32:46.479+0000: 22051: error : virNetSocketReadWire:1362 : Cannot recv data: Connection reset by peer 2013-03-23 21:32:46.479+0000: 22051: debug : virLXCMonitorEOFNotify:120 : EOF notify mon=0x7f4ef0004a00 2013-03-23 21:32:46.479+0000: 22051: debug : virLXCMonitorEOFNotify:127 : EOF callback mon=0x7f4ef0004a00 vm=0x7f4efc0d0a00 2013-03-23 21:32:46.479+0000: 22051: debug : virLXCProcessMonitorEOFNotify:561 : mon=0x7f4ef0004a00 vm=0x7f4efc0d0a00 2013-03-23 21:32:46.579+0000: 22057: error : virLXCProcessStart:1248 : internal error guest failed to start: PATH=/bin:/sbin TERM=linux container=lxc-libvirt container_uuid=df03b2ce-725a-42e2-39e4-d646be8facb3 LIBVIRT_LXC_UUID=df03b2ce-725a-42e2-39e4-d646be8facb3 LIBVIRT_LXC_NAME=testdeb /sbin/init 2013-03-23 21:32:46.432+0000: 1: debug : lxcContainerIdentifyCGroup 2013-03-23 21:32:46.579+0000: 22057: debug : virLXCProcessStop:749 : Stopping VM name=testdeb pid=22180 reason=6 2013-03-23 21:32:46.579+0000: 22057: debug : virLXCProcessCleanup:228 : Stopping VM name=testdeb pid=22180 reason=6 2013-03-23 21:32:46.579+0000: 22057: debug : virLXCProcessAutoDestroyRemove:148 : vm=testdeb uuid=df03b2ce-725a-42e2-39e4-d646be8facb3 2013-03-23 21:32:46.579+0000: 22057: debug : virLXCMonitorClose:209 : mon=0x7f4ef0004a00 2013-03-23 21:32:46.579+0000: 22057: debug : virLXCMonitorClose:215 : Clear EOF callback mon=0x7f4ef0004a00 2013-03-23 21:32:46.581+0000: 22057: error : virNetDevSetOnline:536 : Cannot get interface flags on 'veth1': No such device 2013-03-23 21:32:46.587+0000: 22057: error : virCommandWait:2315 : internal error Child process (ip link del veth1) unexpected exit status 1: Cannot find device "veth1" 2013-03-23 21:32:46.601+0000: 22057: error : virCommandWait:2315 : internal error Child process (ip link del veth2) unexpected exit status 1: Cannot find device "veth2" 2013-03-23 21:32:46.601+0000: 22051: debug : virLXCProcessStop:749 : Stopping VM name=testdeb pid=-1 reason=1 2013-03-23 21:32:46.601+0000: 22051: debug : virLXCProcessStop:751 : VM 'testdeb' not active 2013-03-23 21:32:46.601+0000: 22051: debug : virLXCProcessStop:749 : Stopping VM name=testdeb pid=-1 reason=1 2013-03-23 21:32:46.601+0000: 22051: debug : virLXCProcessStop:751 : VM 'testdeb' not active 2013-03-23 21:32:46.601+0000: 22051: debug : virLXCMonitorDispose:200 : mon=0x7f4ef0004a00 2013-03-23 21:32:46.602+0000: 22051: debug : virLXCProcessAutoDestroyRun:122 : conn=0x7f4ef8000ae0 # tail -n 16 /var/log/libvirt/lxc/testdeb.log 2013-03-23 21:32:46.432+0000: 1: debug : lxcContainerPivotRoot:464 : Pivot via /mnt/testdeb 2013-03-23 21:32:46.432+0000: 1: debug : lxcContainerMountBasicFS:583 : Mounting basic filesystems pivotRoot=1 2013-03-23 21:32:46.432+0000: 1: debug : lxcContainerMountBasicFS:589 : Processing proc -> /proc 2013-03-23 21:32:46.432+0000: 1: debug : lxcContainerMountBasicFS:606 : Mount proc on /proc type=proc flags=e, opts=(null) 2013-03-23 21:32:46.432+0000: 1: debug : lxcContainerMountBasicFS:589 : Processing /proc/sys -> /proc/sys 2013-03-23 21:32:46.432+0000: 1: debug : lxcContainerMountBasicFS:606 : Mount /proc/sys on /proc/sys type=(null) flags=1000, opts=(null) 2013-03-23 21:32:46.432+0000: 1: debug : lxcContainerMountBasicFS:589 : Processing /proc/sys -> /proc/sys 2013-03-23 21:32:46.432+0000: 1: debug : lxcContainerMountBasicFS:606 : Mount /proc/sys on /proc/sys type=(null) flags=1021, opts=(null) 2013-03-23 21:32:46.432+0000: 1: debug : lxcContainerMountBasicFS:589 : Processing sysfs -> /sys 2013-03-23 21:32:46.432+0000: 1: debug : lxcContainerMountBasicFS:606 : Mount sysfs on /sys type=sysfs flags=e, opts=(null) 2013-03-23 21:32:46.432+0000: 1: debug : lxcContainerMountBasicFS:589 : Processing sysfs -> /sys 2013-03-23 21:32:46.432+0000: 1: debug : lxcContainerMountBasicFS:606 : Mount sysfs on /sys type=sysfs flags=1021, opts=(null) 2013-03-23 21:32:46.432+0000: 1: debug : lxcContainerMountBasicFS:630 : Mount devfs on /dev type=tmpfs flags=2, opts=mode=755,size=65536 2013-03-23 21:32:46.432+0000: 1: debug : lxcContainerMountBasicFS:642 : rc=0 2013-03-23 21:32:46.432+0000: 1: error : lxcContainerMountProcFuse:664 : Failed to mount /.oldroot//var/run/libvirt/lxc/testdeb.fuse/meminfo on /proc/meminfo: No such file or directory 2013-03-23 21:32:46.432+0000: 22180: error : virLXCControllerRun:1475 : error receiving signal from container: Input/output error error receiving signal from container: Input/output error If I compile with --without-fuse, it gets a bit farther... # LIBVIRT_DEBUG=4 LIBVIRT_LOG_FILTERS=1:lxc LIBVIRT_LOG_OUTPUTS=1:stderr ./daemon/libvirtd 2>&1 | tee libvirtd.new 2013-03-24 04:58:10.095+0000: 13373: info : libvirt version: 1.0.3 2013-03-24 04:58:10.095+0000: 13373: debug : lxcContainerAvailable:2490 : container support is enabled 2013-03-24 04:58:10.104+0000: 13373: debug : lxcContainerAvailable:2490 : container support is enabled 2013-03-24 04:58:10.104+0000: 13373: info : lxcSecurityInit:1395 : lxcSecurityInit (null) 2013-03-24 04:58:10.104+0000: 13373: debug : lxcCapsInit:143 : Initialized caps for security driver "none" with DOI "0" 2013-03-24 04:58:10.106+0000: 13373: debug : virLXCProcessAutoDestroyRun:122 : conn=0x7f39a00f4bb0 2013-03-24 04:58:38.641+0000: 13367: debug : virLXCProcessStart:1060 : Setting current domain def as transient 2013-03-24 04:58:38.641+0000: 13367: debug : virLXCProcessStart:1082 : Preparing host devices 2013-03-24 04:58:38.641+0000: 13367: debug : virLXCProcessStart:1100 : Generating domain security label (if required) 2013-03-24 04:58:38.641+0000: 13367: debug : virLXCProcessStart:1111 : Setting domain security labels 2013-03-24 04:58:38.642+0000: 13367: debug : virLXCProcessSetupInterfaceBridged:316 : calling vethCreate() 2013-03-24 04:58:38.646+0000: 13367: debug : virLXCProcessSetupInterfaceBridged:320 : parentVeth: veth0, containerVeth: veth1 2013-03-24 04:58:38.719+0000: 13367: error : virLXCProcessStart:1254 : internal error bob: /var/run/libvirt/lxc, testdeb bob: /var/run/libvirt/lxc, testdeb 2013-03-24 04:58:38.719+0000: 13348: error : virNetSocketReadWire:1362 : Cannot recv data: Connection reset by peer 2013-03-24 04:58:38.719+0000: 13348: debug : virLXCMonitorEOFNotify:120 : EOF notify mon=0x7f3994004850 2013-03-24 04:58:38.719+0000: 13348: debug : virLXCMonitorEOFNotify:127 : EOF callback mon=0x7f3994004850 vm=0x7f39a00f4dd0 2013-03-24 04:58:38.719+0000: 13348: debug : virLXCProcessMonitorEOFNotify:561 : mon=0x7f3994004850 vm=0x7f39a00f4dd0 2013-03-24 04:58:38.819+0000: 13367: error : virLXCProcessStart:1262 : internal error guest failed to start: PATH=/bin:/sbin TERM=linux container=lxc-libvirt container_uuid=df03b2ce-725a-42e2-39e4-d646be8facb3 LIBVIRT_LXC_UUID=df03b2ce-725a-42e2-39e4-d646be8facb3 LIBVIRT_LXC_NAME=testdeb /sbin/init 2013-03-24 04:58:38.701+0000: 1: debug : lxcContainerIdentifyCGroup 2013-03-24 04:58:38.819+0000: 13367: debug : virLXCProcessStop:749 : Stopping VM name=testdeb pid=13814 reason=6 2013-03-24 04:58:38.819+0000: 13367: debug : virLXCProcessCleanup:228 : Stopping VM name=testdeb pid=13814 reason=6 2013-03-24 04:58:38.819+0000: 13367: debug : virLXCProcessAutoDestroyRemove:148 : vm=testdeb uuid=df03b2ce-725a-42e2-39e4-d646be8facb3 2013-03-24 04:58:38.819+0000: 13367: debug : virLXCMonitorClose:209 : mon=0x7f3994004850 2013-03-24 04:58:38.819+0000: 13367: debug : virLXCMonitorClose:215 : Clear EOF callback mon=0x7f3994004850 2013-03-24 04:58:38.821+0000: 13367: error : virNetDevSetOnline:536 : Cannot get interface flags on 'veth0': No such device 2013-03-24 04:58:38.827+0000: 13367: error : virCommandWait:2315 : internal error Child process (ip link del veth0) unexpected exit status 1: Cannot find device "veth0" 2013-03-24 04:58:38.834+0000: 13367: error : virCommandWait:2315 : internal error Child process (ip link del veth1) unexpected exit status 1: Cannot find device "veth1" 2013-03-24 04:58:38.834+0000: 13348: debug : virLXCProcessStop:749 : Stopping VM name=testdeb pid=-1 reason=1 2013-03-24 04:58:38.834+0000: 13348: debug : virLXCProcessStop:751 : VM 'testdeb' not active 2013-03-24 04:58:38.834+0000: 13348: debug : virLXCProcessStop:749 : Stopping VM name=testdeb pid=-1 reason=1 2013-03-24 04:58:38.834+0000: 13348: debug : virLXCProcessStop:751 : VM 'testdeb' not active 2013-03-24 04:58:38.834+0000: 13348: debug : virLXCMonitorDispose:200 : mon=0x7f3994004850 2013-03-24 04:58:38.835+0000: 13348: debug : virLXCProcessAutoDestroyRun:122 : conn=0x7f399c000ce0 # tail -n 16 /var/log/libvirt/lxc/testdeb.log 2013-03-24 04:58:38.701+0000: 1: debug : lxcContainerMountBasicFS:589 : Processing sysfs -> /sys 2013-03-24 04:58:38.701+0000: 1: debug : lxcContainerMountBasicFS:606 : Mount sysfs on /sys type=sysfs flags=1021, opts=(null) 2013-03-24 04:58:38.701+0000: 1: debug : lxcContainerMountBasicFS:630 : Mount devfs on /dev type=tmpfs flags=2, opts=mode=755,size=65536 2013-03-24 04:58:38.701+0000: 1: debug : lxcContainerMountBasicFS:642 : rc=0 2013-03-24 04:58:38.701+0000: 1: debug : lxcContainerMountCGroups:1896 : Mounting cgroups at '/sys/fs/cgroup' 2013-03-24 04:58:38.701+0000: 1: debug : lxcContainerMountCGroups:1931 : Create mount point '/sys/fs/cgroup/cpuset' 2013-03-24 04:58:38.701+0000: 1: debug : lxcContainerMountCGroups:1931 : Create mount point '/sys/fs/cgroup/cpu' 2013-03-24 04:58:38.701+0000: 1: debug : lxcContainerMountCGroups:1931 : Create mount point '/sys/fs/cgroup/cpuacct' 2013-03-24 04:58:38.701+0000: 1: debug : lxcContainerMountCGroups:1931 : Create mount point '/sys/fs/cgroup/memory' 2013-03-24 04:58:38.701+0000: 1: debug : lxcContainerMountCGroups:1931 : Create mount point '/sys/fs/cgroup/devices' 2013-03-24 04:58:38.701+0000: 1: debug : lxcContainerMountCGroups:1931 : Create mount point '/sys/fs/cgroup/freezer' 2013-03-24 04:58:38.701+0000: 1: debug : lxcContainerMountCGroups:1931 : Create mount point '/sys/fs/cgroup/blkio' 2013-03-24 04:58:38.701+0000: 1: debug : lxcContainerMountCGroups:1931 : Create mount point '/sys/fs/cgroup/net_prio' 2013-03-24 04:58:38.701+0000: 1: debug : lxcContainerMountFSDevPTS:696 : Trying to move /.oldroot//var/run/libvirt/lxc/testdeb.devpts to /dev/pts 2013-03-24 04:58:38.701+0000: 1: error : lxcContainerMountFSDevPTS:702 : Failed to mount /.oldroot//var/run/libvirt/lxc/testdeb.devpts on /dev/pts: No such file or directory 2013-03-24 04:58:38.702+0000: 13814: error : virLXCControllerRun:1475 : error receiving signal from container: Input/output error error receiving signal from container: Input/output error -- Doug Goldstein
On Sun, Mar 03, 2013 at 05:24:39PM -0600, Doug Goldstein wrote:
On Fri, Dec 21, 2012 at 10:15 PM, Lars Kellogg-Stedman <lars@oddbit.com> wrote:
Using libvirt 1.0.1, I'm trying to start an LXC container using the '<filesytem type="block">' syntax, like this:
<filesystem type="block" accessmode="passthrough"> <source dev="/dev/vg_files/vm-foobar-root" /> <target dir="/" /> </filesystem>
The specified block device exists:
# ls -lL /dev/vg_files/vm-foobar-root brw-rw---- 1 root disk 253, 19 Dec 21 22:23 /dev/vg_files/vm-foobar-root
If I start the domain, it appears to start without any errors...
# virsh start foobar Domain foobar started
I just gave it a whirl. And I'm able to reproduce the same issue you are seeing. The issue appears to be that lxcContainerMountFsBlockAuto() is never being called. It was added in http://www.redhat.com/archives/libvir-list/2011-August/msg00201.html Hopefully I'll have more info soon.
I tried this with latest GIT and did not experience any problems. # dd if=/dev/zero of=disk.img count=100 bs=1M # losetup -f /root/disk.img # losetup -a /dev/loop1: [64768]:3774561 (/root/disk.img) # virsh -c lxc:/// dumpxml busy | xpath /domain/devices/filesystem[2] Found 1 nodes: -- NODE -- <filesystem type="block" accessmode="passthrough"> <source dev="/dev/loop1" /> <target dir="/mnt" /> </filesystem> # virsh -c lxc:/// start busy Domain busy started # virsh -c lxc:/// console busy Connected to domain busy Escape character is ^] # ls /mnt/ lost+found # grep /mnt /proc/mounts /.oldroot/dev/loop1 /mnt ext2 rw,seclabel,relatime 0 0 Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
participants (4)
-
Daniel P. Berrange -
Doug Goldstein -
Gao feng -
Lars Kellogg-Stedman