[Libvir] [PATCH] Fix the value of XEN_V2_OP_GETDOMAININFOLIST

[Daniel P. Berrange]

On Tue, May 08, 2007 at 11:01:04AM +0900, Saori Fukuta wrote:
> Here is a result of a comparing between "xend_internal.c" and "xen_internal.c".
> 
> # xm list
> Name                                      ID   Mem VCPUs      State   Time(s)
> Domain-0                                   0   729     2     r-----    483.5
> HVM_RH5_sda6                               5   195     2     ------  10294.2
> 
> # virsh setmaxmem HVM_RH5_sda6 500000
> 
> # xm list -l HVM_RH5_sda6 | grep mem
>     (maxmem 400)
>     (memory 195)
>     (shadow_memory 6)
> 
> # ./virsh dominfo HVM_RH5_sda6
> [DEBUG] using: xenDaemonDomainGetInfo
> State:          no state
> CPU(s):         5
> CPU time:       10202.0s
> Max memory:     409600 kB <---
> Used memory:    199680 kB <---
> 
> # ./virsh dominfo HVM_RH5_sda6
> [DEBUG] using: xenHypervisorGetDomainInfo
> State:          no state
> CPU(s):         5
> CPU time:       10214.1s
> Max memory:     500000 kB <---
> Used memory:    207744 kB <---
> 
> I think the value is correct when using "xenDaemonDomainGetInfo".
> So I want to use only "xenDaemonDomainGetInfo" for Xen when executing 
> "virsh dominfo" command. How does that sound ?

Hmm, this is interesting. So what your example is showing is that the
current & max-memory settings disagree between the hypervisor and XenD.
Whether the HV is more correct, or whether XenD is more correct is a
difficult question to decide upon !

What has happened in this scenario I think is that the guest was booted
with maxmem == 500, hence the Hypervisor shows '500000 kB'. Later the
guest's max memory was reduced to 400 using XenD, however, since you 
can't truely change the max-memory maps of the guest, the HV still shows
500, while XenD now shows the reduced 400 MV limit. IMHO, XenD is wrong
here because it is showing an artificially low limit which the HV has
no intention of enforcing. xm list is merely showing the info it gets back
from XenD, so if XenD disagrees with the HV, then so will xm list.

Making libvirt always use xenDaemonDomainGetInfo is also not practical,
since the virDomainGetInfo is the single most performance critical API
in libvirt. If we used always called xenDaemonDomainGetInfo  instead of
xenHypervisorGetDomainInfo, then we reduce the performance of this API
by at least x1000 which is not really acceptable.

Since we have the libvirt_proxy, even when running as non-root apps will
(indirectly) be calling xenHypervisorGetDomainInfo, so it will be very
rare that libvirt ever calls xenDaemonDomainGetInfo.  

So I think we just need to accept that  virsh dominfo, will disagree with
xm list in some scenarios & document this difference to explain to people
why libvirt is more correct ;-)

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|