[LITMUS^RT] HELP:NFS+KVM Tutorial

Mon Jan 20 14:48:43 CET 2014

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/LiblitmusViaNFS but
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20140120/e698231d/attachment.html>