Re: [libvirt] [PATCH 1/2] Parallels: add domainGetVcpus().
Re-adding the mailing list - please don't drop the list CC when replying. On Mon, Jun 02, 2014 at 09:22:35PM +0400, aburluka wrote:
Hmm, what error did you get from openstack ? The two uses of the 'dom.vcpus' function are both wrapped in try/except so that it is considered non-fatal if libvirt doesn't provide this. I have caught this error on Havana release. I would try to reproduce this error, but it will take some short time to test it on Icehouse.
Ok, then I think you should find the lack of this API is non-fatal in Icehouse / Juno now.
Are you talking about container based virt here or full machine based virt ? IIUC Parallels can do both ? With container based virt, does parallels have the concept of 'vcpus' at all ? We don't have that in LXC at least. Parallels Cloud Server has that concept in both types of virt.
With the full machine virt does Parallels have a separate process or thread for each vCPU, and if so can we identify the PIDs for the vCPUs to let us do proper pCPU<->vCPU mapping & reporting. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Ok, then I think you should find the lack of this API is non-fatal in Icehouse / Juno now. You're perfectly right, this error is non-fatal anymore. With the full machine virt does Parallels have a separate process or thread for each vCPU, and if so can we identify the PIDs for the vCPUs to let us do proper pCPU<->vCPU mapping & reporting. Every vCPU uses its own thread. A proper mapping pCPU<->vCPU is not available at the moment. Due to distributed architecture of our product, implementation of this feature may take some efforts. Is it really necessary to have this mapping?
-- Regards, Alexander Burluka
On Tue, Jun 03, 2014 at 04:55:43PM +0400, aburluka wrote:
Ok, then I think you should find the lack of this API is non-fatal in Icehouse / Juno now. You're perfectly right, this error is non-fatal anymore. With the full machine virt does Parallels have a separate process or thread for each vCPU, and if so can we identify the PIDs for the vCPUs to let us do proper pCPU<->vCPU mapping & reporting. Every vCPU uses its own thread. A proper mapping pCPU<->vCPU is not available at the moment. Due to distributed architecture of our product, implementation of this feature may take some efforts. Is it really necessary to have this mapping?
No, it isn't mandatory - I'm just trying to understand what your HV is capable of to help me review the patch. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
participants (2)
-
aburluka -
Daniel P. Berrange