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ć
