> On Tue, Aug 27, 2013 at 9:08 AM, arun abhinay <
arun.abhinay@gmail.com>wrote:
>
>> Hi Martin,
>>
>> Thanks for your reply. I have already posted this query to libvirt list.
>>
https://www.redhat.com/archives/libvirt-users/2013-August/msg00114.html>>
>>>> Wanting to post the link here, I've found
>>>> that even the machine name is the same, so it shouldn't be a problem for
>>>> you to find it.
>>
>> Were you talking of the same link which is mentioned above.
>>
>> Since the change of converting it from error to warning was done by you, i
>> have mailed a seperate query to you. Yes we will make sure that such
>> queries are addresed to libvirt user list from next time.
>>
>>>> This basically means that you have old qemu that doesn't support (I'm
>>>> guesing the command now) "query-vcpus" QMP command.
>>
>> I have got below information from the file "qapi-schema.json" in qemu code.
>> ##
>> # @query-cpus:
>> #
>> # Returns a list of information about each virtual CPU.
>> #
>> # Returns: a list of @CpuInfo for each virtual CPU
>> #
>> # Since: 0.14.0
>> ##
>> { 'command': 'query-cpus', 'returns': ['CpuInfo'] }
>> ##
>>
>> We were ealier using libvirt-1.0.2 and qemu-kvm-0.14.1-1, and the
>> "cpu-stats" command was working fine. We are facing this issue after
>> upgrading the libvirt version to 1.0.6. But anyways it can be a problem
>> with old qemu version. We are trying to compile the new libvirt 1.0.6 with
>> qemu-1.6.0 but we are facing some compiling issues because of
>> depedencies between latest qemu code with glib.
>>
>> Please let us know your comments. Thanks in advance.
>>
>> BR
>> Abhinay
>>
>>
>>
>> On Tue, Aug 27, 2013 at 8:06 AM, Martin Kletzander <
mkletzan@redhat.com>wrote:
>>
>>> [cc'ing libvir-list]
>>>
>>> On 08/26/2013 05:59 PM, arun abhinay wrote:
>>>> Hi,
>>>>
>>>> Can you please consider this is an gentle reminder for my below request.
>>>>
>>>> Thanks
>>>> Abhinay
>>>>
>>>> On Fri, Aug 23, 2013 at 1:01 PM, arun abhinay <
arun.abhinay@gmail.com
>>>> wrote:
>>>>
>>>>> Hi Martin/Peter,
>>>>>
>>>
>>> Hi,
>>>
>>> firstly, feel free to write to the list, not just particular people.
>>> There are many more people on the list that may help you. Not
>>> mentioning that those people you write might not be available, don't
>>> have time etc.
>>>
>>> There was a similar question to the one you've asked, you could have
>>> checked that out before as well and reply on it. There's also a patch
>>> fixing cpu-stats command, check it that helps.
>>>
>>>>> In reference to
>>>>>
http://comments.gmane.org/gmane.comp.emulators.libvirt/62451
>>>>>
>>>>> We have created a VM on a qemu-kvm emulator using the domain.xml as
>>>>> mentioned in attachment. The starting of the VM is sucessful but we are
>>>>> facing issue while executing the command "cpu-stats <domain>". While
>>>>> analysis we found below below log in libvirtd.log
>>>>>
>>>>> 2013-08-22 12:45:44.326+0000: 17554: warning :
>>> qemuSetupCgroupForVcpu:953
>>>>> : Unable to get vcpus' pids
>>>>>
>>>
>>> This basically means that you have old qemu that doesn't support (I'm
>>> guesing the command now) "query-vcpus" QMP command. The problem
>>> probably lies somewhere else, even though my change might have caused
>>> the other part to behave differently.
>>>
>>>>> The complete logs while starting VM and while executing the "cpu-stats"
>>>>> command are attached with this mail for reference. Can you please
>>> check and
>>>>> provide us some inputs or pointers to get "cpu-stats" command working.
>>>>>
>>>>> I am new to using libvirt. Your inputs would be of great help to us.
>>>>>
>>>>> Libvrit and qemu-kvm verisons used are mentioned below
>>>>> libvirt-1.0.6-1
>>>>> qemu-kvm-0.14.1-1
>>>>>
>>>>> <<CLA_new-0.xml >> --> Domain.xml used to define VM
>>>>> << libvirt_testing_starting_VG.log >> --> Log while staring VM
>>>>> <<libvirt_testing_cpu_stats.log >> ---> Log while executing command
>>>>> cpu_stats.
>>>>>
>>>
>>> According to the logs, it looks like it's completely the same like a
>>> question already asked... Wanting to post the link here, I've found
>>> that even the machine name is the same, so it shouldn't be a problem for
>>> you to find it.
>>>
>>> I'm looking at the issue now, so I'll see what I can do, but maybe in
>>> the meantime sombody else will reply.
>>>
>>> Martin
>>>
>>
>>
>