10:15 p.m.
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
5:24 p.m.
On Fri, Dec 21, 2012 at 10:15 PM, Lars Kellogg-Stedman <lars(a)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
10:38 p.m.
On Sun, Mar 3, 2013 at 5:24 PM, Doug Goldstein <cardoe(a)gentoo.org> wrote:
On Fri, Dec 21, 2012 at 10:15 PM, Lars Kellogg-Stedman
<lars(a)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
11:19 p.m.
Hi Doug,
On 2013/03/04 12:38, Doug Goldstein wrote:
On Sun, Mar 3, 2013 at 5:24 PM, Doug Goldstein
<cardoe(a)gentoo.org> wrote:
> On Fri, Dec 21, 2012 at 10:15 PM, Lars Kellogg-Stedman <lars(a)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
11:50 p.m.
On Sun, Mar 3, 2013 at 11:19 PM, Gao feng <gaofeng(a)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(a)gentoo.org> wrote:
>> On Fri, Dec 21, 2012 at 10:15 PM, Lars Kellogg-Stedman <lars(a)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
6:59 a.m.
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 :|
12:27 p.m.
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 :|
12:09 a.m.
On Fri, Mar 22, 2013 at 12:27 PM, Daniel P. Berrange
<berrange(a)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
6:37 a.m.
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(a)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 :|
4074
days inactive
4166
days old
8 comments
4 participants
participants (4)
-
Daniel P. Berrange -
Doug Goldstein -
Gao feng -
Lars Kellogg-Stedman