Neither the block nor the scsi drivers appear to be running as far as I can tell.
- Steve On Thu, Jun 30, 2022 at 11:07 AM Simon Weller <[email protected]> wrote: > Steve, > > Are you running the virtio-block or virtio-scsi drivers? > > -Si > > > ________________________________ > From: S.Fuller <[email protected]> > Sent: Thursday, June 30, 2022 8:52 AM > To: [email protected] <[email protected]> > Subject: Re: Asymmetric traffic issues? > > EXTERNAL EMAIL: This message originated outside of ENA. Use caution when > clicking links, opening attachments, or complying with requests. Click the > "Phish Alert Report" button above the email, or contact MIS, regarding any > suspicious message. > > > > Well, I checked everything that I could for any QOS settings and there is > nothing configured there. What is curious is that Idon't see this behavior > when the transmitting host is running Linux, or if I'm using the E1000 > drivers (although with the E1000 driver, the overall throughput is lower). > It really feels like I'mrunning into some weird issue with the virtio > drivers on Windows. My Windows hosts are (to my knowledge) using the latest > version of the virtio drivers - 100.90.104.21700 dated 2/23/2022. > > Steve Fuller > [email protected] > > On Wed, Jun 29, 2022 at 3:04 PM S.Fuller <[email protected]> wrote: > > > Vivek, > > > > Thanks for the reply. I am using the KVM hypervisor. I'll will review the > > QoS on the hypervisor for both of the nodes. > > > > I'm checking throughput between two different VMs that running on two > > different hosts within the same cluster. As of right now, I'm receiving > > similar results using both iperf3 and nuttcp as the testing tools. We are > > only seeing this issue when the VM is not on the same host as the vrouter > > for its isolated network. > > > > On Tue, Jun 28, 2022 at 6:40 AM Vivek Kumar > > <[email protected]> wrote: > > > >> Hey Fuller, > >> > >> What hypervisor are you using ? I know you have checked all bandwidth > >> limit on templates and global settings, but it’s worth to check the QoS > on > >> the hypervisor level, because at the end it’s the hypervisor which > manages > >> all. And from where are you trying to check the network throughout, > >> between client and server ? > >> > >> > >> Vivek Kumar > >> Sr. Manager - Cloud & DevOps > >> TechOps | Indiqus Technologies > >> > >> + 91 7503460090 <tel:++91+7503460090> > >> [email protected] <mailto:[email protected]> > >> www.indiqus.com<http://www.indiqus.com> < > https://www.indiqus.com/> > >> > >> > >> > >> > On 28-Jun-2022, at 1:58 AM, S.Fuller <[email protected]> wrote: > >> > > >> > Environment: > >> > > >> > Two physical hosts > >> > - Cloudstack 4.11.3 > >> > - Verified that there are no bandwidth limits in place on any of the > >> > templates or in global settings. > >> > > >> > Two isolated networks ("Client" and "Server") > >> > - Each has a vrouter with a public and private address > >> > - One Windows 2016 VM on each network (running the latest virtio > >> drivers) > >> > - each node running latest version of Iperf3 to test throughput > >> > > >> > Testing/Observation: > >> > > >> > If the Client VM and the vrouter for the isolated Client network are > on > >> the > >> > same physical host, we see symmetrical throughput in the 2 Gbps range, > >> > whether we run iperf in regular mode or in reverse mode (iperf -R). > >> > > >> > If the Client VM and the vrouter for the isolated Client network are > on > >> > different physical hosts, we are seeing 25% of the throughput running > >> iperf > >> > in regular mode vs running it in reverse mode. > >> > > >> > Has anyone encountered this issue before? If we change the Client VM > to > >> > Linux (either CentOS 7 or Ubuntu) OR we use the E1000 driver, we see > >> > symmetrical throughput in our tests, no matter where the vrouter is in > >> > relation to the Client VM. > >> > > >> > -- > >> > Steve Fuller > >> > [email protected] > >> > >> > >> -- > >> This message is intended only for the use of the individual or entity to > >> which it is addressed and may contain confidential and/or privileged > >> information. If you are not the intended recipient, please delete the > >> original message and any copy of it from your computer system. You are > >> hereby notified that any dissemination, distribution or copying of this > >> communication is strictly prohibited unless proper authorization has > been > >> obtained for such action. If you have received this communication in > >> error, > >> please notify the sender immediately. Although IndiQus attempts to sweep > >> e-mail and attachments for viruses, it does not guarantee that both are > >> virus-free and accepts no liability for any damage sustained as a result > >> of > >> viruses. > >> > > > > > > -- > > Steve Fuller > > [email protected] > > > > > -- > Steve Fuller > [email protected] > -- Steve Fuller [email protected]
