Re: [libvirt] Problems with filesystem type='block'
On Fri, Mar 22, 2013 at 12:27 PM, Daniel P. Berrange berra...@redhat.com wrote: On Fri, Mar 22, 2013 at 11:59:56AM +, 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' nametestdeb/name uuiddf03b2ce-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_poweroffdestroy/on_poweroff on_rebootrestart/on_reboot on_crashdestroy/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+: 22063: info : libvirt version: 1.0.3 2013-03-23 21:32:38.863+: 22063: debug : lxcContainerAvailable:2490 : container support is enabled 2013-03-23 21:32:38.889+: 22063: debug : lxcContainerAvailable:2490 : container support is enabled 2013-03-23 21:32:38.890+: 22063: info : lxcSecurityInit:1395 : lxcSecurityInit (null) 2013-03-23 21:32:38.890+: 22063: debug : lxcCapsInit:143 : Initialized caps for security driver none with DOI 0 2013-03-23 21:32:38.892+: 22063: debug : virLXCProcessAutoDestroyRun:122 : conn=0x7f4efc0fb190 2013-03-23 21:32:46.294+: 22057: debug : virLXCProcessStart:1060 : Setting current domain def as transient 2013-03-23 21:32:46.295+: 22057: debug : virLXCProcessStart:1082 : Preparing host devices 2013-03-23 21:32:46.295+: 22057: debug : virLXCProcessStart:1100 : Generating domain security label (if required) 2013-03-23 21:32:46.295+: 22057: debug : virLXCProcessStart: : Setting domain security labels 2013-03-23 21:32:46.295+: 22057: debug : virLXCProcessSetupInterfaceBridged:316 : calling vethCreate() 2013-03-23 21:32:46.297+: 22057: debug : virLXCProcessSetupInterfaceBridged:320 : parentVeth: veth1, containerVeth: veth2 2013-03-23 21:32:46.479+: 22051: error : virNetSocketReadWire:1362 : Cannot recv data: Connection reset by peer 2013-03-23 21:32:46.479+: 22051: debug : virLXCMonitorEOFNotify:120 : EOF notify mon=0x7f4ef0004a00 2013-03-23 21:32:46.479+: 22051: debug : virLXCMonitorEOFNotify:127 : EOF callback mon=0x7f4ef0004a00 vm=0x7f4efc0d0a00 2013-03-23 21:32:46.479+: 22051: debug : virLXCProcessMonitorEOFNotify:561 : mon=0x7f4ef0004a00 vm=0x7f4efc0d0a00 2013-03-23 21:32:46.579+: 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+: 1: debug : lxcContainerIdentifyCGroup 2013-03-23 21:32:46.579+: 22057: debug : virLXCProcessStop:749 : Stopping VM name=testdeb pid=22180 reason=6 2013-03-23 21:32:46.579+: 22057: debug : virLXCProcessCleanup:228 : Stopping VM name=testdeb pid=22180 reason=6
Re: [libvirt] Problems with filesystem type='block'
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' nametestdeb/name uuiddf03b2ce-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_poweroffdestroy/on_poweroff on_rebootrestart/on_reboot on_crashdestroy/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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Problems with filesystem type='block'
On Fri, Mar 22, 2013 at 11:59:56AM +, 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' nametestdeb/name uuiddf03b2ce-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_poweroffdestroy/on_poweroff on_rebootrestart/on_reboot on_crashdestroy/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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Problems with filesystem type='block'
On Sun, Mar 3, 2013 at 11:19 PM, Gao feng gaof...@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 car...@gentoo.org wrote: On Fri, Dec 21, 2012 at 10:15 PM, Lars Kellogg-Stedman l...@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+: 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+: 1468: info : libvirt version: 1.0.1 2012-12-22 04:10:57.967+: 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+: 1: warning : lxcContainerDropCapabilities:1788 : libcap-ng support not compiled in, unable to clear capabilities 2012-12-22 04:10:58.198+: 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+: 7197: debug : virFileMakePathHelper:1272 : path=/v ar/run/libvirt/lxc mode=0777 2013-03-04 04:17:55.443+: 7197: debug : virFileClose:72 : Closed fd 18 2013-03-04 04:17:55.443+: 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+: 7197: debug : virFileClose:72 : Closed fd 21 2013-03-04 04:17:55.444+: 7197: debug : virCommandRunAsync:2218 : Command result 0, with PID 7294 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 3 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 4 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 5 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 6 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 7 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 8 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 9 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 10 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 11 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 12 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 13 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 14 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 15 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 16 2013-03-04 04:17:55.444+: 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
Re: [libvirt] Problems with filesystem type='block'
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 l...@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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Problems with filesystem type='block'
On Fri, Dec 21, 2012 at 10:15 PM, Lars Kellogg-Stedman l...@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+: 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+: 1468: info : libvirt version: 1.0.1 2012-12-22 04:10:57.967+: 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+: 1: warning : lxcContainerDropCapabilities:1788 : libcap-ng support not compiled in, unable to clear capabilities 2012-12-22 04:10:58.198+: 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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Problems with filesystem type='block'
On Sun, Mar 3, 2013 at 5:24 PM, Doug Goldstein car...@gentoo.org wrote: On Fri, Dec 21, 2012 at 10:15 PM, Lars Kellogg-Stedman l...@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+: 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+: 1468: info : libvirt version: 1.0.1 2012-12-22 04:10:57.967+: 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+: 1: warning : lxcContainerDropCapabilities:1788 : libcap-ng support not compiled in, unable to clear capabilities 2012-12-22 04:10:58.198+: 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+: 7197: debug : virFileMakePathHelper:1272 : path=/v ar/run/libvirt/lxc mode=0777 2013-03-04 04:17:55.443+: 7197: debug : virFileClose:72 : Closed fd 18 2013-03-04 04:17:55.443+: 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+: 7197: debug : virFileClose:72 : Closed fd 21 2013-03-04 04:17:55.444+: 7197: debug : virCommandRunAsync:2218 : Command result 0, with PID 7294 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 3 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 4 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 5 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 6 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 7 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 8 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 9 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 10 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 11 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 12 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 13 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 14 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 15 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 16 2013-03-04 04:17:55.444+: 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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Problems with filesystem type='block'
Hi Doug, On 2013/03/04 12:38, Doug Goldstein wrote: On Sun, Mar 3, 2013 at 5:24 PM, Doug Goldstein car...@gentoo.org wrote: On Fri, Dec 21, 2012 at 10:15 PM, Lars Kellogg-Stedman l...@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+: 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+: 1468: info : libvirt version: 1.0.1 2012-12-22 04:10:57.967+: 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+: 1: warning : lxcContainerDropCapabilities:1788 : libcap-ng support not compiled in, unable to clear capabilities 2012-12-22 04:10:58.198+: 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+: 7197: debug : virFileMakePathHelper:1272 : path=/v ar/run/libvirt/lxc mode=0777 2013-03-04 04:17:55.443+: 7197: debug : virFileClose:72 : Closed fd 18 2013-03-04 04:17:55.443+: 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+: 7197: debug : virFileClose:72 : Closed fd 21 2013-03-04 04:17:55.444+: 7197: debug : virCommandRunAsync:2218 : Command result 0, with PID 7294 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 3 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 4 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 5 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 6 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 7 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 8 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 9 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 10 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 11 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 12 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 13 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 14 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 15 2013-03-04 04:17:55.444+: 7294: debug : virFileClose:72 : Closed fd 16 2013-03-04 04:17:55.444+: 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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[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+: 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+: 1468: info : libvirt version: 1.0.1 2012-12-22 04:10:57.967+: 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+: 1: warning : lxcContainerDropCapabilities:1788 : libcap-ng support not compiled in, unable to clear capabilities 2012-12-22 04:10:58.198+: 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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
