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

Re: [Xen-devel] Broken changing of config parameters for inactive domains



On Thu, Dec 07, 2006 at 06:34:47PM +0000, Daniel P. Berrange wrote:
> On Thu, Dec 07, 2006 at 06:09:11PM +0000, Daniel P. Berrange wrote:
> > I've been testing out the inactive domain support in more depth, and looking
> > for any odd interactions with xm and/or libvirt. In doing so I seem to have
> > found some problems with changing the configuration of existing domains.
> > 
> > Since the config files are no longer in /etc/xen, users will no longer 
> > simply
> > be able to edit them to tweak parameters before booting. Changing the files
> > under /var/lib/xend/domains is not practical because XenD won't see the
> > changed files (unless it uses Inotify - which it doesn't).
> > 
> > I don't think we need to worry about changing every single parameter at this
> > time, but the basic set of memory, max memory, vcpu count should definitely
> > be made to work with 'xm' / XMLRPC / SEXPR  apis.  If it was practical I'd
> > also like to see the network & block device add/remove APIs work for 
> > inactive
> > domains too.
> > 
> > 
> > Currently, this sort of works, but results in very wierd bugs. eg changing
> > the VCPUs for a guest:
> > 
> > So, I have a guest with 2 vcpus:
> > 
> >   # xm list
> >   Name                                      ID   Mem VCPUs      State   
> > Time(s)
> >   Domain-0                                   0  2981     2     r-----   
> > 2381.2
> >   demo                                           410     2                 
> > 0.0
> > 
> > 
> > And want to change it to have 8:
> > 
> >   # xm set-vcpus demo 8
> >   Command set-vcpus is deprecated.  Please use xm vcpu-set instead.
> >   Error: 
> >   Usage: xm <subcommand> [args]
> >   [sniped rest of error]
> > 
> > So it apparently failed, but it actualy succeeded....
> > 
> >   # xm list
> >   Name                                      ID   Mem VCPUs      State   
> > Time(s)
> >   Domain-0                                   0  2981     2     r-----   
> > 2381.7
> >   demo                                           410     8                 
> > 0.0
> > 
> > What's even wierder, is if I now go and try to start the guest I end up
> > with 2 copies of it !!
> > 
> >   # xm start demo
> >   # xm list
> >   Name                                      ID   Mem VCPUs      State   
> > Time(s)
> >   Domain-0                                   0  2981     2     r-----   
> > 2382.9
> >   demo                                      45   410     8     -b----      
> > 0.8
> >   demo                                      45   410     8     -b----      
> > 0.8
> 
> After a little more debugging, this duplicate domains problem seems to be
> unrelated to the changing of config params.
> 
> I defined an inactive guest with a UUID of 
> '66857c70-9898-fdfc-ed53-8eee3ba294bf'
> which got stored on disk as 
> 
>   /var/lib/xend/domains/66857c70-9898-fdfc-ed53-8eee3ba294bf/config.sxp 
> 
> When starting the guest, however, it got a UUID of 
> 66857c709898fdfced538eee3ba294bf
> so it thought there was a dup.  So, XenD needs to normalize UUIDs to remove 
> any
> embedded '-' when saving the inactive domain config to avoid this duplicate
> domains issue.


Just tested

  changeset:   12810:28403de6c415
  user:        Alastair Tse <atse@xxxxxxxxxxxxx>
  date:        Fri Dec 08 13:28:22 2006 +0000
  summary:     [XEND] Make sure UUID is in the right format.

And this has resolved the duplicate domain problems I was seeing - thanks
Alastair.

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

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.