[Qemu-devel] Playing with virtfs.

[Qemu-devel] Playing with virtfs.

[Rob Landley]

Using yesterday's -git, following the instructions in
http://wiki.qemu.org/Documentation/9psetup (which is missing a kernel
symbol, you need to add CONFIG_VIRTIO_PCI to your kernel too), I managed
to mount a read-only virtfs filesystem, adding this to the
qemu-system-x86_64 command line:

-virtfs
local,security_model=passthrough,mount_tag=kvm,path=/home/landley/9ptest

And then in the emulated Linux:

  root@kvm:~# mount -t 9p -o trans=virtio,version=9p2000.L kvm woot
  root@kvm:~# ls -l woot
  total 80
  -rw-r--r-- 1 1000 1000 77874 Jan 22 23:33 config-linux
  root@kvm:~# cd woot
  root@kvm:~/woot# touch fred
  touch: setting times of `fred': No such file or directory
  root@kvm:~/woot#

I.E. It seems to work fine read only, but changes are discarded.

Am I doing something wrong, or is this expected?  (If so, when is write
support likely to go in?)

Rob

Re: [Qemu-devel] Playing with virtfs.

[Aneesh Kumar K. V]

On Sun, 23 Jan 2011 13:33:14 -0600, Rob Landley <rob@landley.net> wrote:
> Using yesterday's -git, following the instructions in
> http://wiki.qemu.org/Documentation/9psetup (which is missing a kernel
> symbol, you need to add CONFIG_VIRTIO_PCI to your kernel too), I managed
> to mount a read-only virtfs filesystem, adding this to the
> qemu-system-x86_64 command line:

With top of the kernel tree 52cfd503ad7176d23a5dd7af3981744feb60622f
I am able to build the kernel without CONFIG_VIRTIO_PCI. What is the
exact error you are finding ?

> 
> -virtfs
> local,security_model=passthrough,mount_tag=kvm,path=/home/landley/9ptest
> 
> And then in the emulated Linux:
> 
>   root@kvm:~# mount -t 9p -o trans=virtio,version=9p2000.L kvm woot
>   root@kvm:~# ls -l woot
>   total 80
>   -rw-r--r-- 1 1000 1000 77874 Jan 22 23:33 config-linux
>   root@kvm:~# cd woot
>   root@kvm:~/woot# touch fred
>   touch: setting times of `fred': No such file or directory
>   root@kvm:~/woot#
> 
> I.E. It seems to work fine read only, but changes are discarded.
> 
> Am I doing something wrong, or is this expected?  (If so, when is write
> support likely to go in?)
> 

Are you running qemu as root ? Using passthrough security model require
the ability to change the ownership of the file. Otherwise you can use
security=none, but the credentials with which files are created will
not be correct. 

-aneesh

Re: [Qemu-devel] Playing with virtfs.

[Rob Landley]

On 01/24/2011 10:15 AM, Aneesh Kumar K. V wrote:
> On Sun, 23 Jan 2011 13:33:14 -0600, Rob Landley <rob@landley.net> wrote:
>> Using yesterday's -git, following the instructions in
>> http://wiki.qemu.org/Documentation/9psetup (which is missing a kernel
>> symbol, you need to add CONFIG_VIRTIO_PCI to your kernel too), I managed
>> to mount a read-only virtfs filesystem, adding this to the
>> qemu-system-x86_64 command line:
> 
> With top of the kernel tree 52cfd503ad7176d23a5dd7af3981744feb60622f
> I am able to build the kernel without CONFIG_VIRTIO_PCI. What is the
> exact error you are finding ?

It wasn't a runtime error, it's that some of the config symbols the
instructions told me to switch on were hidden.  CONFIG_NET_9P_VIRTIO
depends on CONFIG_VIRTIO which is selected by CONFIG_VIRTIO_PCI.  If
CONFIG_VIRTIO isn't forced on by something, you can't select
CONFIG_NET_9P_VIRTIO.

>>
>> -virtfs
>> local,security_model=passthrough,mount_tag=kvm,path=/home/landley/9ptest
>>
>> And then in the emulated Linux:
>>
>>   root@kvm:~# mount -t 9p -o trans=virtio,version=9p2000.L kvm woot
>>   root@kvm:~# ls -l woot
>>   total 80
>>   -rw-r--r-- 1 1000 1000 77874 Jan 22 23:33 config-linux
>>   root@kvm:~# cd woot
>>   root@kvm:~/woot# touch fred
>>   touch: setting times of `fred': No such file or directory
>>   root@kvm:~/woot#
>>
>> I.E. It seems to work fine read only, but changes are discarded.
>>
>> Am I doing something wrong, or is this expected?  (If so, when is write
>> support likely to go in?)
>>
> 
> Are you running qemu as root ?

Nope, I try to avoid doing that where possible.

> Using passthrough security model require
> the ability to change the ownership of the file. Otherwise you can use
> security=none, but the credentials with which files are created will
> not be correct. 

Yup, that was it.

I note that security=mapped behaves like security=passthrough.  (Which
is a pity, because it would have been the first legitimate use for
extended attributes I've seen since I stopped using OS/2.)

> -aneesh

It works!  Thanks.

Rob