Thanks Paolo, So are you saying that if I am running a very latency sensitive, real-time, voice and video over IP application, then fundamentally KVM is not the best way to go? I would be better off going with XEN? If Xen, then would you suggest a PVM or PVHVM? (This application has proven to run well in Amazon, and I believe we used their PVHVM offering. Still we are striving to work in KVM (also openstack-KVM one day) thanks -----Original Message----- From: Paolo Bonzini [mailto:paolo.bonzini@xxxxxxxxx] On Behalf Of Paolo Bonzini Sent: Sunday, April 02, 2017 3:40 PM To: James Okken; kvm@xxxxxxxxxxxxxxx; kvm-owner@xxxxxxxxxxxxxxx Subject: Re: CentOS 7.2 HVM, PVM and/or PVHVM On 31/03/2017 23:20, James Okken wrote: > Oh wow.!? Is that really the case? > I'm surprised because I see these things in my centos7 KVM VMs (aren't they signs of a PVM or at least a PVHVM? No, because: > dmesg | grep -i virtual > [ 0.000000] Booting paravirtualized kernel on KVM > [ 0.398931] systemd[1]: Detected virtualization 'kvm'. "Paravirtualized kernel" here means that the kernel knows it's running on KVM and is using some services from the hypervisor to improve performance or functionality. This is not the same as Xen PV or PVH guests. For example, Xen PV and and PVH guests access the PCI bus through the hypervisor (or don't have a PCI bus at all), have a Xen-specific mechanism to deliver interrupts, and so on. None of this is true for KVM. A KVM guest is a superset of what PC hardware looks like (albeit pretty old PC hardware). Note that Xen HVM is also a superset of PC hardware, and the extra hardware includes a special PCI device that exposes Xen constructs for interrupts and shared memory (grant tables). Likewise, this: > lsmod | grep virt > virtio_balloon 13664 0 > virtio_blk 18156 5 > virtio_console 28114 0 > virtio_net 28024 0 > virtio_pci 22913 0 > virtio_ring 21524 5 virtio_blk,virtio_net,virtio_pci,virtio_balloon virtio_console > virtio 15008 5 virtio_blk,virtio_net,virtio_pci,virtio_balloon virtio_console is just a set of PCI devices whose design was optimized for virtualization. But you don't need to use them, and in fact nothing would stop a hardware manufacturer from taking the same design and implement it as a real board. Again, this is unlike Xen PV, PVH or even HVM where the disks, NICs etc. are not PCI devices and are tied to Xen's interrupt delivery mechanisms and to grant tables. Thanks, Paolo > > lspci | grep -i virt > 00:03.0 Ethernet controller: Red Hat, Inc Virtio network device > 00:04.0 Communication controller: Red Hat, Inc Virtio console > 00:06.0 SCSI storage controller: Red Hat, Inc Virtio block device > 00:07.0 Unclassified device [00ff]: Red Hat, Inc Virtio memory balloon > 00:09.0 Ethernet controller: Red Hat, Inc Virtio network device > > Not to doubt anyone, I am just wanting to understand this fully., > > Thanks > > --Jim > > > > > -----Original Message----- > From: Paolo Bonzini [mailto:paolo.bonzini@xxxxxxxxx] On Behalf Of > Paolo Bonzini > Sent: Friday, March 31, 2017 7:14 AM > To: James Okken; kvm@xxxxxxxxxxxxxxx; kvm-owner@xxxxxxxxxxxxxxx > Subject: Re: CentOS 7.2 HVM, PVM and/or PVHVM > > > > On 30/03/2017 17:44, James Okken wrote: >> Sorry I just hijacked that thread, I meant to change the subject before I sent! >> >>>>>>>> >> hi all, >> >> I have this nagging question I'm hoping someone could clear up for me. There is so much information and discussion out there regarding HVM, PVM and PVHVM it is hard to get any concrete understanding of what I'm actually using. >> >> I thought I understood that my KVM deployment on CentOS 7.2 was creating PVM VMs. > > KVM only has HVM. PVM and PVHVM are Xen concepts. > > Paolo > >> Checking dmesg, lspci, lsmod of the running centos7 VMs all indications show the VMs are PVMs. >> >> But when I look at the XML of the VMs I see: <type arch='x86_64' >> machine='pc-i440fx-rhel7.0.0'>hvm</type> >> >> Does that <type>hvm</type> mean I am mistaken? >> >> Thanks >> <<<<<< >> >
