Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Big problems with tcp offload #1

Closed
guilhem opened this issue Feb 8, 2012 · 8 comments
Closed

Big problems with tcp offload #1

guilhem opened this issue Feb 8, 2012 · 8 comments

Comments

@guilhem
Copy link

guilhem commented Feb 8, 2012

I use KVM in my company with a mix Linux/WIndows.

I use them with vhost_net, bridge and/or macvtap.

Problems com with macvtap on Windows.
without any management of tcp offload :

  1. Windows reject any packet send from another vm on the same host (and in macvtap too). (can be correct by a tricky rule in iptables... but it's quite awful
  2. More painful, when GRO is activated on host, ALL packets are dropped by windows...
@YanVugenfirer
Copy link
Collaborator

Windows does not support GRO (receive offload). Any such configuration on
host will cause Windows to misbehave.

Those issues should be solved on the host. Windows driver reports that it
has no RX offload capabilities.
I will speak to QEMU guys to see what can be done.

Best regards,
Yan.

On Wed, Feb 8, 2012 at 5:37 PM, Guilhem <
reply@reply.github.com

wrote:

I use KVM in my company with a mix Linux/WIndows.

I use them with vhost_net, bridge and/or macvtap.

Problems com with macvtap on Windows :
without any management of tcp offload :

  1. Windows reject any paquet send from another another on the same host
    (and in macvtap too). (can be correct by a tricky rule in iptables... but
    it's quite awful
  2. More painful, when GRO is activated on host, ALL packets are dropped by
    windows...

Reply to this email directly or view it on GitHub:
YanVugenfirer/kvm-guest-drivers-windows#1


Daynix Computing LTD
Yan Vugenfirer, Technology expert and consultant
Email: yan@daynix.com
Phone: +972-54-4758084
Web: www.daynix.com

@guilhem
Copy link
Author

guilhem commented Feb 8, 2012

Thank you for this information, I hope this will be fix ASAP :)

Don't hesitate to come back to me, I can do some tests on my infrastructure

@iggy
Copy link

iggy commented Feb 10, 2012

That's how macvtap is supposed to work.

@vipmike007
Copy link

1) Windows reject any packet send from another vm on the same host (and in macvtap too). (can be correct by a tricky rule in iptables... but it's quite awful

Tried this via virt-manager ,did not hit this issue . might be libvirt default firewall rule make it ?

@guilhem
Copy link
Author

guilhem commented Feb 13, 2012

  1. A linux vm send packet without any good checksum (thanks to offload). But with macvtap, packet is directly send to the Windows VM (and so without a good checksum). And Windows reject the package.
    To correct this, I must use this rule on the GUEST Linux :
    -A POSTROUTING -d WINDOWS-GUEST -p tcp -j CHECKSUM --checksum-fill
    Very tricky rule...

@vipmike007
Copy link

Hi, guihem

which network type are you using , e1000 + macvtap , Am I right ?

@guilhem
Copy link
Author

guilhem commented Feb 13, 2012

HOST : e1000e + vhost_net
Guests : macvtap + virtio

EDIT : to be more precise, this is my libvirt conf

    <interface type='direct'>
      <mac address='de:ad:b9:73:7e:33'/>
      <source mode='bridge' dev='eth0.2086'/>
      <target dev='macvtap2'/>
      <model type='virtio'/>
      <alias name='net0'/>
      <address slot='0x03' bus='0x00' domain='0x0000' type='pci' function='0x0'/>
    </interface>

@sameehj
Copy link
Contributor

sameehj commented Nov 16, 2017

Hi,

we are currently in a process of closing all github's issues that have been resolved or expired. I'm currently closing this issue, please reopen the issue or else open a new issue if needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants