qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Sukrit Bhatnagar <skrtbhtngr@gmail.com>,
	Dmitry Fleytman <dmitry.fleytman@gmail.com>,
	qemu-devel@nongnu.org, Yuval Shaia <yuval.shaia@oracle.com>
Subject: Re: [Qemu-devel] [RFC 0/1] Add live migration support to the PVRDMA device
Date: Tue, 25 Jun 2019 14:39:21 +0300	[thread overview]
Message-ID: <e957d1d1-d531-9438-b716-3c61fe3f83a2@gmail.com> (raw)
In-Reply-To: <20190625091116.GE3226@work-vm>



On 6/25/19 12:11 PM, Dr. David Alan Gilbert wrote:
> * Marcel Apfelbaum (marcel.apfelbaum@gmail.com) wrote:
>> Hi Dmitry,
>>
>> On 6/25/19 11:39 AM, Dmitry Fleytman wrote:
>>>> On 25 Jun 2019, at 11:14, Marcel Apfelbaum <marcel.apfelbaum@gmail.com> wrote:
>>>>
>>>> Hi Sukrit
>>>>
>>>> On 6/21/19 5:45 PM, Sukrit Bhatnagar wrote:
>>>>> Hi,
>>>> [...]
>>>>> This RFC is meant to request suggestions on the things which are
>>>>> working and for help on the things which are not.
>>>>>
>>>> [...]
>>>>> What is not working:
>>>>>
>>>> [...]
>>>>> * It seems that vmxnet3 migration itself is not working properly, at least
>>>>>     for me. The pvrdma device depends on it, vmxnet3 is function 0 and pvrdma
>>>>>     is function 1. This is happening even for a build of unmodified code from
>>>>>     the master branch.
>>>>>     After migration, the network connectivity is lost at destination.
>>>>>     Things are fine at the source before migration.
>>>>>     This is the command I am using at src:
>>>>>
>>>>>     sudo /home/skrtbhtngr/qemu/build/x86_64-softmmu/qemu-system-x86_64 \
>>>>>       -enable-kvm \
>>>>>       -m 2G -smp cpus=2 \
>>>>>       -hda /home/skrtbhtngr/fedora.img \
>>>>>       -netdev tap,id=hostnet0 \
>>>>>       -device vmxnet3,netdev=hostnet0,id=net0,mac=52:54:00:99:ff:bc \
>>>>>       -monitor telnet:127.0.0.1:4444,server,nowait \
>>>>>       -trace events=/home/skrtbhtngr/trace-events \
>>>>>       -vnc 0.0.0.0:0
>>>>>
>>>>>     Similar command is used for the dest. Currently, I am trying
>>>>>     same-host migration for testing purpose, without the pvrdma device.
>>>>>     Two tap interfaces, for src and dest were created successfully at
>>>>>     the host. Kernel logs:
>>>>>     ...
>>>>>     br0: port 2(tap0) entered forwarding state
>>>>>     ...
>>>>>     br0: port 3(tap1) entered forwarding state
>>>>>
>>>>>     tcpdump at the dest reports only outgoing ARP packets, which ask
>>>>>     for gateway: "ARP, Request who-has _gateway tell guest1".
>>>>>
>>>>>     Tried using user (slirp) as the network backend, but no luck.
>>>>>        Also tried git bisect to find the issue using a working commit (given
>>>>>     by Marcel), but it turns out that it is very old and I faced build
>>>>>     errors one after another.
>>>>>
>>>>>     Please note that e1000 live migration is working fine in the same setup.
>>>>>
>>>> I tried to git bisect , but I couldn't find a working version of vmxnet supporting live migration ....
>>>> I tried even a commit from December 2014 and it didn't work.
>>>>
>>>> What is strange (to me) is that the networking packets can't be sent from the guest (after migration)
>>>> even after rebooting the guest.
>>> This makes me think that some network offload configuration wasn’t properly migrated or applied.
>>> What network backend are you using?
>> Suktrit tried with tap device, I tried with slirp.
>> If you can point me to the property that disables all the offloads it will
>> really help.
>>
>>> Do you see any outgoing packets in the sniffer?
>> I didn't use the sniffer, I checked dmesg in guest, there was a line
>> complaining that it can't send packets.
> What exactly was the error?

I'll try to reproduce the error

Thanks,
Marcel

> I don't know much about vmxnet3;  but if the guest driver is seeing the
> problem then I guess that's the best pointer we have.
>
>
> Dave
>
>> Thanks,
>> Marcel
>>
>>>> Any help or pointer would be greatly appreciated.
>>>> Thanks,
>>>> Marcel
>>>>
>>>>
>>>> [...]
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK



  reply	other threads:[~2019-06-25 11:42 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-21 14:45 [Qemu-devel] [RFC 0/1] Add live migration support to the PVRDMA device Sukrit Bhatnagar
2019-06-21 14:45 ` [Qemu-devel] [RFC 1/1] hw/pvrdma: Add live migration support Sukrit Bhatnagar
2019-06-25 15:32   ` Yuval Shaia
2019-06-28 11:26     ` Dr. David Alan Gilbert
2019-06-29 12:45       ` Sukrit Bhatnagar
2019-06-30  8:13         ` Yuval Shaia
2019-07-01  2:15           ` Sukrit Bhatnagar
2019-07-01 12:08             ` Yuval Shaia
2019-07-08 10:54         ` Dr. David Alan Gilbert
2019-06-25 15:38   ` Yuval Shaia
2019-06-21 17:55 ` [Qemu-devel] [RFC 0/1] Add live migration support to the PVRDMA device no-reply
2019-06-25  8:14 ` Marcel Apfelbaum
2019-06-25  8:39   ` Dmitry Fleytman
2019-06-25  8:49     ` Marcel Apfelbaum
2019-06-25  9:11       ` Dr. David Alan Gilbert
2019-06-25 11:39         ` Marcel Apfelbaum [this message]
2019-06-25 10:25       ` Dmitry Fleytman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e957d1d1-d531-9438-b716-3c61fe3f83a2@gmail.com \
    --to=marcel.apfelbaum@gmail.com \
    --cc=dgilbert@redhat.com \
    --cc=dmitry.fleytman@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=skrtbhtngr@gmail.com \
    --cc=yuval.shaia@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).