This is most probably due to the Qemu versions (all Debian's should be with VirtIO)
Best, On Wed, 20 May 2020 at 00:55, Sean Lair <sl...@ippathways.com> wrote: > Just for feedback, we are 4.11.3 and run KVM on CentOS 7. Our 4.11.3 > template is set to Debian GNU/Linux 8 (64-bit). Our lspci is shown below: > > root@r-281-VM:~# lspci > 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev > 02) > 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] > 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton > II] > 00:01.2 USB controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton > II] (rev 01) > 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) > 00:02.0 VGA compatible controller: Cirrus Logic GD 5446 > 00:03.0 Ethernet controller: Red Hat, Inc Virtio network device > 00:04.0 Communication controller: Red Hat, Inc Virtio console > 00:05.0 SCSI storage controller: Red Hat, Inc Virtio block device > 00:06.0 System peripheral: Intel Corporation 6300ESB Watchdog Timer > 00:07.0 Ethernet controller: Red Hat, Inc Virtio network device > 00:08.0 Ethernet controller: Red Hat, Inc Virtio network device > 00:09.0 Ethernet controller: Red Hat, Inc Virtio network device > > > -----Original Message----- > From: Andrija Panic <andrija.pa...@gmail.com> > Sent: Saturday, May 16, 2020 7:12 AM > To: users <users@cloudstack.apache.org> > Subject: Re: VirtIO Network Adapter for system vms on KVM Hypervisor > > Thanks for the feedback on that one, Rafal. > > Regards > > On Sat, 16 May 2020 at 12:58, Rafal Turkiewicz <tur...@turexy.com> wrote: > > > Just for a record > > > > I have tested this with Debian GNU/Linux 7.0 (64-bit) OS Type and it > > also worked. It basically breaks as soon as I pick Debian GNU/Linux 8 > (64-bit). > > > > Thanks > > > > On 2020/05/15 14:00:53, Rafal Turkiewicz <tur...@turexy.com> wrote: > > > Andrija, > > > > > > You are the man! I have changed the OS Type to the default Debian 5 > > > x64 > > and boom! All sorted. > > > > > > It's really odd that picking older OS Type solved the issue where in > > fact the systemVM is running Debian 9. Is this a BUG of some sort? > > > > > > I might try and experiment with other OS Type Debian version X to > > > see > > where it falls but for now I'm all happy! > > > > > > Once again thank you very much for the pointer! > > > > > > Raf > > > > > > On 2020/05/15 13:51:01, Andrija Panic <andrija.pa...@gmail.com> wrote: > > > > In the upgrade guide, we always advise (when registering the new > > systeVM > > > > template) to go as: > > > > > > > > OS Type: Debian GNU/Linux 7.0 (64-bit) (or the highest > > > > Debian > > release > > > > number available in the dropdown) > > > > > > > > That being said, in the clean 4.13 installation, the OS type is > > > > set to Debian 5 x64 - so try each version and in between destroy VR > (i.e. > > restart > > > > the network with cleanup) and observe "lspci" if virtio or intel > > > > NICs > > - but > > > > also make sure that each time the VR is created on KVM host (i.e. > > > > not > > on > > > > XEN). > > > > > > > > In order to change OS type for systemVM template, you will have to > > > > use > > DB > > > > - modify the "vm_template" table - update the "guest_os_id" field > > value for > > > > that specific template, to the ID from the "guest_os" table where > > > > name=Debian XXX 64. > > > > > > > > Hope that solves the issue - should by all means. > > > > > > > > Regards > > > > Andrija > > > > > > > > > > > > On Fri, 15 May 2020 at 15:33, Rafal Turkiewicz <tur...@turexy.com> > > wrote: > > > > > > > > > Hello Andrija, > > > > > > > > > > Thanks for your input the OS Type for the systemVM template is > > > > > set to "Debian GNU/Linux 8 (64-bit)" > > > > > > > > > > I think I forgot to mention a very important aspect of my setup. > > > > > This Cloudstack instance is powering XenServer and KVM where KVM > > > > > was added recently. > > > > > > > > > > Your message made me think and look at my other (test lab) setup > > where > > > > > CloudStack is only powering KVM hypervisors. I can confirm all > > > > > VRs > > are > > > > > running with virtio which implies there got to be something on > > > > > the > > my mixed > > > > > HV CloudStack. > > > > > > > > > > I will keep looking into this but if you have any further > > > > > thoughts > > on this > > > > > please let me know. > > > > > > > > > > Raf > > > > > > > > > > On 2020/05/15 11:14:37, Andrija Panic <andrija.pa...@gmail.com> > > wrote: > > > > > > Rafal, > > > > > > > > > > > > what is the OS type you defined for the systemVM template? > > > > > > > > > > > > In my env, VR (VPC) - all interfaces are VirtIO. > > > > > > > > > > > > Best > > > > > > Andrija > > > > > > > > > > > > On Fri, 15 May 2020 at 12:14, Rafal Turkiewicz > > > > > > <tur...@turexy.com> > > > > > wrote: > > > > > > > > > > > > > Platform: > > > > > > > CloudStack 4.11.2 on CentOS 7 KVM Hypervisor on CentOS 7 > > > > > > > > > > > > > > I have found some throughput issues on our VirtualRuters and > > > > > > > I've > > > > > tracked > > > > > > > it down to CPU IRQ hitting 99% on the VR which was related > > > > > > > to NIC interrupts. > > > > > > > > > > > > > > I decided to lookup what NIC is being emulated on the VRs; > > > > > > > lsmod > > listed > > > > > > > three Intel NICs: > > > > > > > > > > > > > > 00:03.0 Ethernet controller: Intel Corporation 82540EM > > > > > > > Gigabit > > Ethernet > > > > > > > Controller (rev 03) > > > > > > > 00:04.0 Ethernet controller: Intel Corporation 82540EM > > > > > > > Gigabit > > Ethernet > > > > > > > Controller (rev 03) > > > > > > > 00:05.0 Ethernet controller: Intel Corporation 82540EM > > > > > > > Gigabit > > Ethernet > > > > > > > Controller (rev 03) > > > > > > > > > > > > > > All my regular VMs are using Virtio network devices as > > > > > > > specified > > within > > > > > > > template settings nicAdapter=virtio > > > > > > > > > > > > > > When I manually updated the user_vm_details table for a VR > > > > > > > with nicAdapter=virtio and restarted the VR everything came > > > > > > > up as > > expected, > > > > > the > > > > > > > VR was started with virtio NICs and the IRQ issue was gone, > > > > > > > also > > the > > > > > > > throughput doubled. Now lspci on the VR was showing: > > > > > > > > > > > > > > 00:03.0 Ethernet controller: Red Hat, Inc Virtio network > > > > > > > device > > > > > > > 00:04.0 Ethernet controller: Red Hat, Inc Virtio network > > > > > > > device > > > > > > > 00:05.0 Ethernet controller: Red Hat, Inc Virtio network > > > > > > > device > > > > > > > > > > > > > > The problem I have is getting the nicAdapter setting at > > > > > > > systemvm > > > > > template > > > > > > > level like I do for regular VMs so that all VRs are deployed > > > > > > > with > > > > > virtio > > > > > > > network adapter. I don't want to set this manually for every > > network I > > > > > > > deploy. So I went to Templates -> Mysystemvm template -> > > Settings -> > > > > > Add > > > > > > > Setting > > > > > > > > > > > > > > Name: nicAdapter > > > > > > > Value: virtio > > > > > > > > > > > > > > BUT it just looks to me like systemvms don't honour > > vm_template_details > > > > > > > table where nicAdapter is specified. When a VR gets created, > > > > > > > I > > looked > > > > > up > > > > > > > content of the user_vm_details for the VR and found > > nicAdapter=virio is > > > > > > > missing but I would expect it to be there. > > > > > > > > > > > > > > If there is anyone running CloudStack with KVM who could > > > > > > > help on > > this > > > > > that > > > > > > > would be great. It might well be a BUG and needs to be > > > > > > > reported > > as > > > > > such not > > > > > > > sure at this stage. > > > > > > > > > > > > > > If any of the above is not entirely clear please let me know > > > > > > > and > > I > > > > > will try > > > > > > > my best to explain in more detail. > > > > > > > > > > > > > > Thanks > > > > > > > Raf > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > Andrija Panić > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Andrija Panić > > > > > > > > > > > > -- > > Andrija Panić > -- Andrija Panić
