Re: [Xen-devel] [PATCH] Fix xm commands for inactive domains

["Daniel P. Berrange" <berrange@xxxxxxxxxx>]

On Wed, Dec 13, 2006 at 03:38:09PM +0000, Daniel P. Berrange wrote:
> 
> The commands 'mem-set' 'mem-max' and 'vcpu-set' are all broken when used 
> against an inactive domain. The backend implementation of these commands
> typically updates the in-memory config held by XenD, and does a hypercall
> or xenstore write to update the live guest. Obviously the latter part fails
> with inactive guests. The changes are also not persisted to disk.
> 
> The attached patch ensures that the hypercalls/xenstore writes are not
> tried for inactive guests. It will also write out the changes to disk
> so config changes to inactive guests are preserved across XenD restarts.
> 
> Normally memory_dynamic_min/max  and online_vcpus are picked up from the
> running domain state. This doesn't apply for inactive guests, so when 
> changing config for inactive guests, we also update those 3 parameters to
> match the new settings. 
> 
> So, at the end of all this, I can do:
> 
> 1. Define an inactive domain...
> 
>   # xm new demo
>   # xm list demo
>   Name                                      ID   Mem VCPUs      State   
> Time(s)
>   demo                                           410     1                 0.0
>   # xm list --long demo | grep mem
>       (memory 410)
>       (maxmem 800)
>       (shadow_memory 0)
>       (memory_dynamic_min 410)
>       (memory_dynamic_max 800)
> 
> 2. Change its memory config...
> 
>   # xm mem-set demo 500
>   # xm mem-max demo 1000
>   # xm list --long demo | grep mem
>       (memory 500)
>       (maxmem 1000)
>       (shadow_memory 0)
>       (memory_dynamic_min 500)
>       (memory_dynamic_max 1000)
>   # xm list demo
>   Name                                      ID   Mem VCPUs      State   
> Time(s)
>   demo                                           500     1                 0.0
> 
> 3. Change its cpu config...
> 
>   # xm vcpu-set demo 8
>   # xm list --long demo | grep vcpu
>       (vcpus 8)
>       (online_vcpus 8)
>   # xm list demo
>   Name                                      ID   Mem VCPUs      State   
> Time(s)
>   demo                                           500     8                 0.0
> 
> 4. Start it with new settings...
> 
>   # xm start demo
>   # xm list demo
>   Name                                      ID   Mem VCPUs      State   
> Time(s)
>   demo                                      22   500     8     -b----      0.7
> 
> NB, the patch is structured so there is no functional change for active
> guests, to minimise risk of regression in this 3.0.4 freeze. I think this
> is really important to get working in 3.0.4 since inactive domain support
> is of pretty limited usefullness as it currently stands.  Hopefully in 3.0.5
> the XenAPI will make it possible to change all aspects of an inactive guest
> config.
> 
>   Signed-off-by: Daniel P. Berrange  <berrange@xxxxxxxxxx>

There was one final problem I've just also fixed - for some reason the
SEXPR api to change max memory was calling into XenDomain instead of
XenDomainInfo directly. This meant it needed a domid - which doesn't
exist in inactive domain case. So this updated version of the patch also
fixed SrvDomain.py  to call the XenDomainInfo object it already has 
directly - this matches the style of the rest of the method in SrvDomain.py

The attached patch contains my original patch + this SrvDomain.py fix.
Now, not only does 'xm' work correctly, but libvirt can manage inactive
domains & their config settings too.

 Signed-off-by: Daniel P. Berrange  <berrange@xxxxxxxxxx>

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  -=|

Attachment: xen-3.0.4-inactive-config-change-2.patch
Description: Text document

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel