Re: [PATCH] RFC: virsh setmem: configure inactive domains' memory size

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Eric,

  Thank you for reply.

(2011/02/25 6:43), Eric Blake wrote:
> On 02/24/2011 03:25 AM, Taku Izumi wrote:
>>
>> Currently "virsh setmem" is not allowed to use against inactive domains.
>> By applying this patch, we can change the memory size of inactive domains
>> by "virsh setmem".
>>
>>
>> -    if (virDomainSetMemory(dom, kilobytes) != 0) {
>> -        ret = FALSE;
>> +    if (virDomainIsActive(dom) == 1) {
>> +        if (virDomainSetMemory(dom, kilobytes) == 0)
> 
> This is slightly racy - in between the time that you probe if the domain
> is active and actually request to set memory, the domain may have gone
> inactive (or vice versa, in between the time you see that it is inactive
> and start modifying the xml, it may have become active).
> 
> I think the better fix here would be to add a new API,
> virDomainSetMemoryFlags, similar to virDomainUpdateDeviceFlags, where
> the flags can request whether you want to affect running, persistent, or
> both configurations all from a single API.  Falling back to XML editing
> when the new API is not present is reasonable, but not an excuse for not
> providing the right interface to begin with.
> 
> So, I'm debating whether to apply this now or whether to add the better
> API first; anyone else want to chime in?
> 

 I also want to use not only "virsh setmem" command, but the following
 commands against inactive domains:
   - virsh setmaxmem
   - virsh vcpupin
   - virsh attach-device, detach-device
   - virsh setvcpus (already done)

 However, virDomainSetMemory, virDomainSetMaxMemory and virDomainPinVcpu
 are not allowed to use against inactive domains, so we need to extend
 those APIs like virDomainSetMemoryFlags. But although new APIs
 obsoletes old APIs, we can't of-course clear old APIs away for compatibility.
 I am concerned the number of APIs increases and the source codes become complex
 (and a little ugly), so I selected the method like this patch instead.

 If you say new APIs should be introduced, I have no objection.

Taku Izumi

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]