Re: If your networking is failing after updating to the latest git version of QEMU...

[Jason Wang]

On Thu, Sep 29, 2022 at 1:06 AM Philippe Mathieu-Daudé  wrote:
>
> On 28/9/22 10:27, Thomas Huth wrote:
> >
> > ... it might have happened due to the removal of the "slirp" submodule
> > from the git repository. For example if you see an error message like this:
> >
> >   Parameter 'type' expects a netdev backend type
> >
> > this likely means that the "user" mode backend type is not available in
> > your binary anymore. To fix it, simply install "libslirp-devel" (or
> > libslirp-dev or however it is called) from your OS distribution and
> > recompile.
>
> Thanks for the hint Thomas. I'm afraid many developers will miss your
> email.
>
> Jason, Marc-André, could we improve the buildsys check or display
> a more helpful information from the code instead?

It looks to me we need to improve the build.

Thanks

>
> Thanks,
>
> Phil.
>

Re: modify NetdevUserOptions through QMP in QEMU 6 - how?

[Jason Wang]

On Tue, Dec 14, 2021 at 10:53 PM Michael S. Tsirkin  wrote:
>
> On Mon, Dec 13, 2021 at 09:02:15AM +0100, Thomas Huth wrote:
> >  Hi!
> >
> > On 10/12/2021 18.02, Alexander Sosedkin wrote:
> > > With QEMU 5 I could totally issue a QMP netdev_add
> > > with the same ID to adjust the NetdevUserOptions I want,
> > > such as restrict or hostfwd. No deleting needed,
> > > just a netdev_add with what I want changed as a param.
> >
> > I'm a little bit surprised that this worked, since AFAIK there is no code in
> > QEMU to *change* the parameters of a running netdev... likely the code added
> > a new netdev with the same ID, replacing the old one?
> >
> > > With QEMU 6 it started failing, claiming the ID is already used.
> > > And if I do netdev_del + netdev_add, I just lose connectivity.
> > > What's even stranger, I still see old netdev attached in info network:
> > >
> > > > netdev_del {'id': 'net0'}
> > > {}
> > > > human-monitor-command {'command-line': 'info network'}
> > > virtio-net-pci.0:
> > > index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
> > >   \ net0: index=0,type=user,net=10.0.2.0,restrict=off
> >
> > I think that's "normal" - there used to be problems in the past that the
> > devices (virtio-net-pci in this case) did not like the netdevs to be removed
> > on the fly. So the netdevs are kept around until you remove the device, too
> > (i.e. issue a device_del for the virtio-net-pci device).
> >
> > > > netdev_add {'type': 'user', 'id': 'net0', 'restrict': False, 'hostfwd': 
> > > > [{'str': 'tcp:127.0.0.1:58239-:22'}]}
> > > {}
> > > > human-monitor-command {'command-line': 'info network'}
> > > unseal: virtio-net-pci.0:
> > > index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
> > >   \ net0: index=0,type=user,net=10.0.2.0,restrict=off
> > > net0: index=0,type=user,net=10.0.2.0,restrict=off
> > >
> > > What's the correct QMP command sequence to modify NetdevUserOptions?
> >
> > AFAIK there is no way to modify running netdevs - you'd have to delete the
> > netdev and the device, and then add both again. But I might have missed
> > something here, so I CC:-ed some people who might be more familiar with the
> > details here.
> >
> >  Thomas
> >
> >
> > > Please CC me on replies.
>
>
> Wow this really goes to show how wide our feature matrix is.
>
> Yes it's probably an unintended side effect but yes it
> did work it seems, so we really should not just break it
> without warning.
>
>
> Probably this one:
>
> commit 831734cce6494032e9233caff4d8442b3a1e7fef
> Author: Markus Armbruster 
> Date:   Wed Nov 25 11:02:20 2020 +0100
>
> net: Fix handling of id in netdev_add and netdev_del
>
>
>
> Jason, what is your take here?

I might be wrong, but I agree with Thomas. Adding a netdev with the
same ID looks wrong, if it works, it looks like a bug. And I don't
think we support changing netdev properties.

Thanks

>
>
> Alexander, what happens if we just drop the duplicate ID check? Do
> things work for you again?
> Warning: completely untested.
>
> Signed-off-by: Michael S. Tsirkin 
>
>
> diff --git a/net/net.c b/net/net.c
> index f0d14dbfc1..01f5a187b6 100644
> --- a/net/net.c
> +++ b/net/net.c
> @@ -1055,12 +1055,6 @@ static int net_client_init1(const Netdev *netdev, bool 
> is_netdev, Error **errp)
>  }
>  }
>
> -nc = qemu_find_netdev(netdev->id);
> -if (nc) {
> -error_setg(errp, "Duplicate ID '%s'", netdev->id);
> -return -1;
> -}
> -
>  if (net_client_init_fun[netdev->type](netdev, netdev->id, peer, errp) < 
> 0) {
>  /* FIXME drop when all init functions store an Error */
>  if (errp && !*errp) {
> --
> MST
>

Re: network buffering in fault tolerance

[Jason Wang]

On 2020/9/30 下午1:12, Shivam Mehra wrote:


I came across this documentation with source code for providing 
network buffering to applications 
https://www.nfradead.org/~tgr/libnl/doc/api/route_2qdisc_2plug_8c_source.html 
. 
This network-buffering helps output-commit problem when providing 
fault tolerance to virtual machines. The output is buffered until an 
acknowledgement arrives from the backup VM and then released to the 
external world. So that backup and primary VMs seem consistent 
externally. Initially developed for XEN VMM to provide fault tolerance 
to VMs and I think it's now available for |QEMU| too.


Where does the script reside which does network-buffering for 
checkpoints? and what are the commands to make this happen?


I want to do this network-buffering for packets originating from an 
application. Is it possible to do it in the same way as above? Does it 
do any damage to the host kernel? Can I get  a simple working example 
for this?




Hi Shivam:

I haven't gone through the qdisc you mentioned, but it depends on a 
specific host network setup to work if I understand correctly.


Qemu support a native HA (COLO) which has a buffer filter.

Cc Chen for more information.

Thanks