[LITMUS^RT] HELP:NFS+KVM Tutorial

Sanjib Das cnt.sanjib at googlemail.com
Tue Jan 28 10:56:20 CET 2014 

Hi Glenn,

While following instruction from this link
https://wiki.litmus-rt.org/litmus/InstallationInstructions

cd $DIR# get Linux 3.10.5wget
http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.10.5.tar.bz2tar
xjf linux-3.10.5.tar.bz2wget
http://www.litmus-rt.org/releases/2013.1/litmus-rt-2013.1.patchmv
linux-3.10.5 litmus-rt# apply the LITMUS RT patchcd litmus-rtpatch -p1
< ../litmus-rt-2013.1.patch

before menuconfig I copied configuration file from /boot and renamed
it as .config

then ran 'yes " "| make oldconfig'

After that

*make menuconfig shows only "Clustered-EDF" in LITMUR^RT->Scheduling option*

Rest of the schedules don't show up.

@important:: I am not using any KVM or QEMU in this installation flow.

Thanks in advance

Sanjib






On Mon, Jan 20, 2014 at 6:08 PM, Glenn Elliott <gelliott at cs.unc.edu> wrote:

> Again, when you see this type of error, it's because your kernel expects
> to find NFS as a module.  A module is like a shared library (i.e., *.so)
> for the OS.  Modules are good for general use, but are a pain to work with
> during Litmus development.  We suggest that you avoid them.
>
> Module files are denoted with a ".ko" suffix and are located in
> /lib/modules/<kernel name>/*.  That is, modules are stored on the
> filesystem.  In this case, your kernel is looking for the NFS module for
> your specific kernel in the qcow2.img file.  Of course, there are no
> modules in your image file because you compiled the kernel within your host
> environment, not the guest environment.  To get NFS working, you need to
> compile NFS support DIRECTLY INTO the kernel--analogous to a static library
> (i.e., *.a).
>
> To do so:
> 1) Bring up your compilation configuration with "make menuconfig"
> 2) Select "File systems"
> 3) Navigate towards the bottom of the list and select "Network File
> Systems".  Hit space-bar to ensure that there is a "[*]" next to the option.
> 4) With "Network File Systems" selected, hit enter/return to select more
> options.
> 5) Enable the NFS features that you need (probably just "NFS client
> subsystem", but you can select the others to, just to be safe).  Keep
> hitting space-bar until the item is selected with "<*>".  The "*" means
> that it will be compiled into the kernel.  "<M>" means that the feature
> will be compiled as a module.  Don't compile as a module!!!!  <*> good.
>  <M> bad.
>
> These instructions should guide you in the right direction, but I don't
> have time or ability to replicate your particular system configuration to
> test them.  You may have to spend some more time on your own, perhaps
> searching google for answers, to finally get things to work.  There is no
> shortage of Linux kernel tutorials online.  You can always try googling a
> particular error code or message.  I'm sorry that we don't have a complete
> turn-key configuration for Litmus.  Unfortunately, Linux doesn't really
> either (at least for x86), so it's all but impossible for us to provide one.
>
> -Glenn
>
>
> On Jan 20, 2014, at 11:45 AM, Sanjib Das <cnt.sanjib at googlemail.com>
> wrote:
>
> Hi,
> here is the last few lines before the login prompt come up using this
> command
> "qemu-system-x86_64 -enable-kvm -cpu host -smp 2 -hda
> /home/sdas/images/ubuntu.
> backing.qcow2.img -m 1024 -name "ubuntu-qemu-cjk" -nographic -kernel
> "/home/sdas/litmus/litmus-rt/arch/x86_64/boot/bzImage" -append
> "console=ttyS0,115200 root=/dev/hda1" -gdb tcp::12345 -net nic -net
> user,hostfwd=::2222-:22
> "
>
> OUTPUT::
>
> modprobe: chdir(3.10.5-litmus2012.2+): No such file or directory
> Begin: Loading essential drivers ... done.
> Begin: Running /scripts/init-premount ... done.
> Begin: Mounting root file system ... Begin: Running /scripts/local-top ...
> modprobe: chdir(3.10.5-litmus2012.2+): No such file or directory
> done.
> Begin: Running /scripts/local-premount ... done.
> modprobe: chdir(3.10.5-litmus2012.2+): No such file or directory
> [   13.709380] EXT4-fs (hda1): mounted filesystem with ordered data mode.
> Opts: (null)
> Begin: Running /scripts/local-bottom ... done.
> done.
> Begin: Running /scripts/init-bottom ... done.
>
> Last login: Mon Jan 20 10:59:16 EST 2014 on ttyS0
> Welcome to Ubuntu 11.10 (GNU/Linux 3.10.5-litmus2012.2+ x86_64)
>
>  * Documentation:  https://help.ubuntu.com/
> Your Ubuntu release is not supported anymore.
> For upgrade information, please visit:
> http://www.ubuntu.com/releaseendoflife
>
> New release '12.04.3 LTS' available.
> Run 'do-release-upgrade' to upgrade to it.
>
> Thanks in advance
> Sanjib
>
>
>
> On Mon, Jan 20, 2014 at 5:36 PM, Sanjib Das <cnt.sanjib at googlemail.com>wrote:
>
>> Dear Andea and Glenn,
>>
>> Thank you very much.
>> Now I am able to make an nfs and also share data. but only with the
>> following command
>> 'qemu-system-x86_64 -enable-kvm -cpu host -smp 2 -hda
>> /home/sdas/images/ubuntu.backing.qcow2.img -m 1024 -name "ubuntu-qemu-cjk"
>> -nographic -net nic -net user,hostfwd=::2222-:22'
>>
>> But it use this command "qemu-system-x86_64 -enable-kvm -cpu host -smp 2
>> -hda /home/sdas/images/ubuntu.backing.qcow2.img -m 1024 -name
>> "ubuntu-qemu-cjk" -nographic -kernel
>> "/home/sdas/litmus/litmus-rt/arch/x86_64/boot/bzImage" -append
>> "console=ttyS0,115200 root=/dev/hda1" -gdb tcp::12345 -net nic -net
>> user,hostfwd=::2222-:22"
>>
>> 'modprobe nfs' returns error 'Can't read module
>> /lib/modules........................'
>>
>> I guessed I have to use -initrd option in qemu-system-x86_63 command,
>> make bzImage is not creating any initrd or initramfs file.
>>
>> Any suggestion with cordially accepted.
>>
>> Thanks in advance
>>
>> Sanjib
>>
>> On Mon, Jan 20, 2014 at 2:48 PM, Andrea Bastoni <bastoni at sprg.uniroma2.it
>> > wrote:
>>
>>>
>>> On Jan 20, 2014 2:40 PM, "Glenn Elliott" <gelliott at cs.unc.edu> wrote:
>>> >
>>> > Comments inline.
>>> >
>>> > On Jan 20, 2014, at 2:17 AM, Sanjib Das <cnt.sanjib at googlemail.com>
>>> wrote:
>>> >
>>> >> Hi Glenn,
>>> >>
>>> >> ssh -p 2222 realtime at localhost Command requires a password, where I
>>> gave 'realtime' and is not working.
>>> >> sdas at debian:~$ ssh -p 2222 realtime at localhost
>>> >> realtime at localhost's password:
>>> >
>>> >
>>> > Well, at least it's working.  It looks like we've lost any
>>> documentation of the passwords.
>>>
>>> Hi all,
>>>
>>> Perhaps silly question, but did someone already try root root?
>>>
>>> I believe I initially set up our qemu like that, but they've been
>>> reworked quite a bit since that.
>>>
>>> Thanks,
>>> Andrea
>>>
>>> > However, you say that you can log in when -vga is working.  So do this:
>>> > 1) Boot with -vga.  This will dump you into a root-privelged console.
>>> > 2) Do "passwd"
>>> > 3) Pick any password you want for the root user.  (You can also reset
>>> the password of the "realtime" user if you wish.)
>>> > 4) Shutdown
>>> >
>>> >> FYI:"
>>> >>
>>> >> kvm -smp 2 -m 512 -boot c -vga std -net nic -net
>>> user,hostfwd=tcp::10022-:22 -kernel path_to_kernel/arch/x86/boot/bzImage
>>> -append root=/dev/hda1 -hda kvm_image.img
>>> >>
>>> >> "
>>> >> also ask for user-name and password, whats exactly i don't know. But
>>> if I use -nographic  instead of  -vga std it doesn't ask for pass.
>>> >
>>> >
>>> > 5) Now relaunch with "-nographic".  Doing "ssh -p 2222 root at localhost"
>>> should now work using the password you set in step #3 above.
>>> >
>>> >> And also
>>> >>
>>> >> sdas at debian:~$    sudo chmod u+s
>>> /usr/local/libexec/qemu-bridge-helper
>>> >> chmod: cannot access `/usr/local/libexec/qemu-bridge-helper': No such
>>> file or directory
>>> >> sdas at debian:~$
>>> >>
>>> >> It seems to be a bug.
>>> >
>>> >
>>> > Not a bug.  You just don't have qemu-bridge-helper installed at
>>> /usr/local/libexec/.  On my 12.x version of Ubuntu, it's at
>>> /usr/lib/qemu-bridge-helper ("> find /usr -name "*qemu*" is a brute force
>>> way of searching for a file).  I'm not sure about Debian.  I found an old
>>> bug report that indicates Debian (at least in 2012) may not have it
>>> installed (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691138).
>>> >
>>> >> And nfsd output
>>> >> sdas at debian:~$ sudo tail -f /var/log/messages | grep -i 'nfs'
>>> >> Jan 20 07:41:24 debian kernel: [ 2768.813543] nfsd: last server has
>>> exited, flushing export cache
>>> >> Jan 20 07:41:26 debian kernel: [ 2770.506707] NFSD: Using
>>> /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
>>> >> Jan 20 07:41:26 debian kernel: [ 2770.506741] NFSD: starting
>>> 90-second grace period
>>> >>
>>> >>
>>> >> Thanks in advance
>>> >> Sanjib
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> On Mon, Jan 20, 2014 at 1:19 AM, Glenn Elliott <gelliott at cs.unc.edu>
>>> wrote:
>>> >>>
>>> >>>
>>> >>> On Jan 19, 2014, at 7:07 PM, Sanjib Das <cnt.sanjib at googlemail.com>
>>> wrote:
>>> >>>
>>> >>>> Dear Concern,
>>> >>>>
>>> >>>> Can any one give me some suggestion about file sharing. Cause I am
>>> following the link https://wiki.litmus-rt.org/litmus/LiblitmusViaNFSbut still not succeeded.
>>> >>>>
>>> >>>> I am trying to do this with the following command
>>> 'qemu-system-x86_64 -enable-kvm -cpu host -smp 2 -hda
>>> /home/sdas/images/ubuntu.backing.qcow2.img -m 1024 -name "ubuntu-qemu-cjk"
>>> -nographic -kernel "/home/sdas/litmus/litmus-rt/arch/x86_64/boot/bzImage"
>>> -append "console=ttyS0,115200 root=/dev/hda1" -gdb tcp::12345 -net nic -net
>>> user,hostfwd=::2222-:22'
>>> >>>>
>>> >>>> And as a result eth0 in side the guest is configured automatically
>>> >>>>
>>> >>>> From guest to host  'ping 10.0.2.2' is working
>>> >>>> "root at ubuntu-qemu:~# ping 10.0.2.2
>>> >>>> PING 10.0.2.2 (10.0.2.2) 56(84) bytes of data.
>>> >>>> 64 bytes from 10.0.2.2: icmp_req=1 ttl=255 time=2.28 ms
>>> >>>> 64 bytes from 10.0.2.2: icmp_req=2 ttl=255 time=0.515 ms
>>> >>>> ^C
>>> >>>> --- 10.0.2.2 ping statistics ---
>>> >>>> 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
>>> >>>> rtt min/avg/max/mdev = 0.515/1.398/2.281/0.883 ms
>>> >>>> root at ubuntu-qemu:~#
>>> >>>> "
>>> >>>> But Host to guest 'ping 10.0.2.15' not working
>>> >>>>
>>> >>>> "sdas at debian:~$ ping 10.0.2.15
>>> >>>> PING 10.0.2.15 (10.0.2.15) 56(84) bytes of data.
>>> >>>> ^C
>>> >>>> --- 10.0.2.15 ping statistics ---
>>> >>>> 2 packets transmitted, 0 received, 100% packet loss, time 1006ms
>>> >>>>
>>> >>>> sdas at debian:~$
>>> >>>> "
>>> >>>>
>>> >>>> ip route guest :
>>> >>>> root at ubuntu-qemu:~# ip route
>>> >>>> default via 10.0.2.2 dev eth0  metric 100
>>> >>>> 10.0.2.0/24 dev eth0  proto kernel  scope link  src 10.0.2.15
>>> >>>> root at ubuntu-qemu:~#
>>> >>>>
>>> >>>>
>>> >>>> ip route host:
>>> >>>>
>>> >>>> sdas at debian:~$ ip route
>>> >>>> default via 192.168.0.1 dev eth0
>>> >>>> 169.254.0.0/16 dev eth0  scope link  metric 1000
>>> >>>> 192.168.0.0/24 dev eth0  proto kernel  scope link  src
>>> 192.168.0.101
>>> >>>> sdas at debian:~$
>>> >>>>
>>> >>>> my host is debian 7 wheezy.
>>> >>>>
>>> >>>> Any quick suggestion/ alternate tutorial / link/  will very helpful.
>>> >>>
>>> >>>
>>> >>>
>>> >>> I don't believe that direct network access from the host to the
>>> guest is necessary to get NFS to work.  With respect to host->guest
>>> networking, you can ssh into the guest OS by doing "ssh -p 2222
>>> realtime at localhost".  If you want to set up a virtual network, I
>>> believe these instructions will be useful:
>>> http://wiki.qemu.org/Features/HelperNetworking
>>> >>>
>>> >>> Anyway, assuming that your NFS server on the host is working and
>>> your guest can ping the host, I believe your guest OS should be able to
>>> mount the host's network drive.  You've already shown that the guest can
>>> ping the host.  Are you sure NFS is working on the host?  What do the NFS
>>> logs say?
>>> >>>
>>> >>> -Glenn
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> litmus-dev mailing list
>>> >>> litmus-dev at lists.litmus-rt.org
>>> >>> https://lists.litmus-rt.org/listinfo/litmus-dev
>>> >>>
>>> >>
>>> >> _______________________________________________
>>> >> litmus-dev mailing list
>>> >> litmus-dev at lists.litmus-rt.org
>>> >> https://lists.litmus-rt.org/listinfo/litmus-dev
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > litmus-dev mailing list
>>> > litmus-dev at lists.litmus-rt.org
>>> > https://lists.litmus-rt.org/listinfo/litmus-dev
>>> >
>>>
>>> _______________________________________________
>>> litmus-dev mailing list
>>> litmus-dev at lists.litmus-rt.org
>>> https://lists.litmus-rt.org/listinfo/litmus-dev
>>>
>>>
>>
> _______________________________________________
> litmus-dev mailing list
> litmus-dev at lists.litmus-rt.org
> https://lists.litmus-rt.org/listinfo/litmus-dev
>
>
>
> _______________________________________________
> litmus-dev mailing list
> litmus-dev at lists.litmus-rt.org
> https://lists.litmus-rt.org/listinfo/litmus-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20140128/6630f23e/attachment.html>

More information about the litmus-dev mailing list