Xen devel - Nov 2006 - An Introduction to the Xen-API Work

All,

As you may have noticed, the Xen-API development tree has been merged into
xen-unstable.  The work in this tree has been ongoing since June, and is now
ready for wider distribution.  I''d like to take a few minutes to
describe
these changes, and then I''ll follow up this email with a more detailed
design
document.

The Xen-API tree has been released to xen-unstable now, so that it can be
stabilised for release as part of Xen 3.0.4.  The interfaces discussed below
are still open to change, and will only be frozen when Xen 3.0.4 is released.


The Xen-API work had a number of goals:

  1.  Support the Xen-CIM project in its development of CIM providers for
      managing Xen-based hosts.  DMTF''s CIM is the accepted standard
for the
      monitoring and management of hetrogenous clusters, and the Xen-CIM team
      are working to integrate Xen-based hosts into these environments through
      the development of a CIM -> Xen bridge.

  2.  Encourage the development of third-party clients for managing Xen
      directly.  For enterprise-level hetrogeneous environments, the best
      management interface to use is CIM, but for small, simple deployments,
      direct lightweight management may be preferred.  To this end, we wish
      to support third parties in the production of clients, by providing
      an interface that they can use.

  3.  Integrate the remote management of Xen systems, and make remote
      management both easy to use and secure.


To this end, the major effort for the Xen-API project has been to provide a
interface into Xend that is stable and can be supported in the long term.
This will give a solid foundation for the CIM providers, and a guaranteed
interface for direct management tools.

This interface is XML-RPC based, with a data-model and message semantics
layered on top.  The wire-protocol will be guaranteed for the long term,
ensuring that clients using it will be binary-compatible with all Xen releases
after Xen 3.0.4.

As well as fixing the wire protocol, we will be providing bindings written in
a number of languages, and making these available in-tree.  tools/libxen
contains the new C bindings to this API, and the Python clients can get
up-and-running immediately with reflective bindings using xmlrpclib2.

The intention for the bindings is that they will be a thin layer on top of the
wire protocol and data model, with little in the way of moving parts.  On top
of this, we expect libraries such as RedHat''s libvirt to add the richer
functionality.  This split allows the libraries in the Xen tree to be stable
and widely used, and allows third parties to innovate on top of that platform.


Lifecycle Changes
-----------------

To manage a VM properly over its whole lifetime, Xend needs to understand more
about VMs than it has traditionally done.  Xend used to understand VMs only
when they were running, receiving configuration parameters for those VMs from
the outside, and removing the configuration details again as soon as the VM
shut down.  This meant that external systems were needed in order to record VM
details over the long term, such as the xendomains script.  In order to
properly manage VMs remotely, this has to be improved, with Xend becoming
responsible for tracking VM configuration even once the VM has been shut down.

To this end, there are some new xm commands:

  o  xm new     - Introduces a new VM to Xend
  o  xm delete  - Removes a specified VM
  o  xm start   - Boot a named VM
  o  xm create  - Does what it always did, which now makes it equivalent to
                 "xm new ; xm start"
  o  xm suspend - Save a VM to a location under Xend''s management
  o  xm resume  - Resume a VM from that same location

xm list will report non-running VMs, if you ask it to, as well as running
ones.


Authentication
--------------

Remote management needs proper authentication.  At the moment, you must run xm
as root if you want to make any changes to the system, and that''s the
only
authentication we have.  For Xen 3.0.4, Xend will be enhanced so that it is
able to authenticate users through PAM, giving administrators the power to
allow Xend operations to be performed, without giving away the root password.


What We''ve Got
--------------

  o  Many changes to Xend (xen-unstable.hg/tools/python/xen)
  o  New C bindings to the Xen-API (xen-unstable.hg/tools/libxen)
  o  Scripts for experimenting with the Xen-API, much of which will be rolled
     into xm in time (xen-unstable.hg/tools/python/scripts)
  o  A document describing the Xen-API (xen-unstable.hg/docs/xen-api)


What We Need
------------

  o  Tests for the new xm commands, through xm-test.
  o  Lots of people trying the new API and the new C bindings, to see whether
     they meet your needs.
  o  Implementation of the remaining API functions, in particular the
     network-related ones, and those on the to-do list in the documentation.
  o  Documentation improvements.
  o  A Xend bug-squash.
  o  Lots of feedback!


Thanks, and have fun,

Ewan.

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

Hello Ewan,

   something must have broken while moving the API code into the 
xen-unstable repository. I can create multiple Gentoo domains using 
xapi.py and xapi.domcfg.py, but cannot delete any of  them.

   Stefan

xen-devel-bounces@lists.xensource.com wrote on 11/04/2006 10:29:07 AM:
> All,
> 
> As you may have noticed, the Xen-API development tree has been merged 
into
> xen-unstable.  The work in this tree has been ongoing since June, and is 
now
> ready for wider distribution.  I''d like to take a few minutes to 
describe
> these changes, and then I''ll follow up this email with a more
detailed
design
> document.
> 
> The Xen-API tree has been released to xen-unstable now, so that it can 
be
> stabilised for release as part of Xen 3.0.4.  The interfaces discussed 
below
> are still open to change, and will only be frozen when Xen 3.0.4 is 
released.
> 
> 
> The Xen-API work had a number of goals:
> 
>   1.  Support the Xen-CIM project in its development of CIM providers 
for
>       managing Xen-based hosts.  DMTF''s CIM is the accepted
standard for
the
>       monitoring and management of hetrogenous clusters, and the Xen-CIM 
team
>       are working to integrate Xen-based hosts into these environments 
through
>       the development of a CIM -> Xen bridge.
> 
>   2.  Encourage the development of third-party clients for managing Xen
>       directly.  For enterprise-level hetrogeneous environments, the 
best
>       management interface to use is CIM, but for small, simple 
deployments,
>       direct lightweight management may be preferred.  To this end, we 
wish
>       to support third parties in the production of clients, by 
providing
>       an interface that they can use.
> 
>   3.  Integrate the remote management of Xen systems, and make remote
>       management both easy to use and secure.
> 
> 
> To this end, the major effort for the Xen-API project has been to 
provide a
> interface into Xend that is stable and can be supported in the long 
term.
> This will give a solid foundation for the CIM providers, and a 
guaranteed
> interface for direct management tools.
> 
> This interface is XML-RPC based, with a data-model and message semantics
> layered on top.  The wire-protocol will be guaranteed for the long term,
> ensuring that clients using it will be binary-compatible with all Xen 
releases
> after Xen 3.0.4.
> 
> As well as fixing the wire protocol, we will be providing bindings 
written in
> a number of languages, and making these available in-tree.  tools/libxen
> contains the new C bindings to this API, and the Python clients can get
> up-and-running immediately with reflective bindings using xmlrpclib2.
> 
> The intention for the bindings is that they will be a thin layer on top 
of the
> wire protocol and data model, with little in the way of moving parts. On 
top
> of this, we expect libraries such as RedHat''s libvirt to add the
richer
> functionality.  This split allows the libraries in the Xen tree to be 
stable
> and widely used, and allows third parties to innovate on top of 
thatplatform.
> 
> 
> Lifecycle Changes
> -----------------
> 
> To manage a VM properly over its whole lifetime, Xend needs to 
understand more
> about VMs than it has traditionally done.  Xend used to understand VMs 
only
> when they were running, receiving configuration parameters for those VMs 
from
> the outside, and removing the configuration details again as soon as the 
VM
> shut down.  This meant that external systems were needed in order 
torecord VM
> details over the long term, such as the xendomains script.  In order to
> properly manage VMs remotely, this has to be improved, with Xend 
becoming
> responsible for tracking VM configuration even once the VM has been shut 
down.
> 
> To this end, there are some new xm commands:
> 
>   o  xm new     - Introduces a new VM to Xend
>   o  xm delete  - Removes a specified VM
>   o  xm start   - Boot a named VM
>   o  xm create  - Does what it always did, which now makes it equivalent 
to
>                  "xm new ; xm start"
>   o  xm suspend - Save a VM to a location under Xend''s management
>   o  xm resume  - Resume a VM from that same location
> 
> xm list will report non-running VMs, if you ask it to, as well as 
running
> ones.
> 
> 
> Authentication
> --------------
> 
> Remote management needs proper authentication.  At the moment, you must 
run xm
> as root if you want to make any changes to the system, and that''s
the
only
> authentication we have.  For Xen 3.0.4, Xend will be enhanced so that it 
is
> able to authenticate users through PAM, giving administrators the power 
to
> allow Xend operations to be performed, without giving away the root 
password.
> 
> 
> What We''ve Got
> --------------
> 
>   o  Many changes to Xend (xen-unstable.hg/tools/python/xen)
>   o  New C bindings to the Xen-API (xen-unstable.hg/tools/libxen)
>   o  Scripts for experimenting with the Xen-API, much of which will be 
rolled
>      into xm in time (xen-unstable.hg/tools/python/scripts)
>   o  A document describing the Xen-API (xen-unstable.hg/docs/xen-api)
> 
> 
> What We Need
> ------------
> 
>   o  Tests for the new xm commands, through xm-test.
>   o  Lots of people trying the new API and the new C bindings, to see 
whether
>      they meet your needs.
>   o  Implementation of the remaining API functions, in particular the
>      network-related ones, and those on the to-do list in the 
documentation.
>   o  Documentation improvements.
>   o  A Xend bug-squash.
>   o  Lots of feedback!
> 
> 
> Thanks, and have fun,
> 
> Ewan.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

On Mon, Nov 06, 2006 at 03:44:16PM -0500, Stefan Berger wrote:
> Hello Ewan,
> 
>    something must have broken while moving the API code into the
> xen-unstable repository. I can create multiple Gentoo domains using
> xapi.py and xapi.domcfg.py, but cannot delete any of  them.
It wouldn''t surprise me if there were a few breakages.  What do you get
in the logs?

Ewan.


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

xen-devel-bounces@lists.xensource.com wrote on 11/06/2006 06:46:03 PM:
> On Mon, Nov 06, 2006 at 03:44:16PM -0500, Stefan Berger wrote:
> 
> > Hello Ewan,
> > 
> >    something must have broken while moving the API code into the
> > xen-unstable repository. I can create multiple Gentoo domains using
> > xapi.py and xapi.domcfg.py, but cannot delete any of  them.
> 
> It wouldn''t surprise me if there were a few breakages.  What do
you get
> in the logs?
Here''s the log. I also made some modfifications to the password
checking
so I can just press enter  twice, but that should not have effects on the 
domain creation.

[2006-11-07 13:46:33 xend 8500] WARNING (XendAuthSessions:27) python-pam 
is required for XenAPI support.
[2006-11-07 13:46:33 xend 8512] INFO (SrvDaemon:295) Xend Daemon started
[2006-11-07 13:46:33 xend 8512] INFO (SrvDaemon:299) Xend changeset: 
unavailable.
[2006-11-07 13:46:33 xend 8512] INFO (SrvDaemon:306) Xend version: 
Unknown.
[2006-11-07 13:46:33 xend.XendDomainInfo 8512] DEBUG (XendDomainInfo:174) 
XendDomainInfo.recreate({''paused'': 0,
''cpu_time'': 1120748141145L,
''ssidref'': 0, ''hvm'': 0,
''shutdown_reason'': 0, ''dying'': 0,
''mem_kb'':
595968, ''domid'': 0, ''name'':
''Domain-0'', ''max_vcpu_id'': 1,
''crashed'': 0,
''running'': 1, ''maxmem_kb'': -4,
''shutdown'': 0, ''online_vcpus'': 2,
''handle'':
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], ''blocked'':
0})
[2006-11-07 13:46:33 xend 8512] DEBUG (XendConfig:299) XendConfig:
{''hvm'':
0, ''shutdown_reason'': 0, ''paused'': 0,
''crashed'': 0, ''running'': 1,
''maxmem_kb'': -4, ''shutdown'': 0,
''mem_kb'': 595968, ''handle'': [0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], ''blocked'': 0,
''cpu_time'':
1120748141145L, ''ssidref'': 0, ''name'':
''Domain-0'', ''dying'': 0,
''domid'': 0,
''max_vcpu_id'': 1, ''online_vcpus'': 2}
[2006-11-07 13:46:33 xend.XendDomainInfo 8512] INFO (XendDomainInfo:189) 
Recreating domain 0, UUID 00000000-0000-0000-0000-000000000000. at 
/local/domain/0
[2006-11-07 13:46:33 xend 8512] DEBUG (XendDomain:389) Adding Domain: 0
[2006-11-07 13:46:33 xend 8512] DEBUG (XendDomain:348) number of vcpus to 
use is 0
[2006-11-07 13:46:33 xend.XendDomainInfo 8512] DEBUG (XendDomainInfo:759) 
XendDomainInfo.handleShutdownWatch
[2006-11-07 13:47:00 xend 8512] DEBUG (XendConfig:299) XendConfig: 
{''kernel_kernel'':
''/boot/vmlinuz-2.6.16.29-xen'',
''on_poweroff'': ''destroy'',
''name'': ''GentooAPI'',
''kernel_args'': '''',
''on_reboot'': ''restart'',
''image'':
''(linux\n    (kernel /boot/vmlinuz-2.6.16.29-xen)\n    (ramdisk 
/boot/initrd-2.6.16.29-xen.img)\n)\n'',
''kernel_initrd'':
''/boot/initrd-2.6.16.29-xen.img'',
''on_crash'': ''restart'',
''vif_refs'': [],
''memory'': 32, ''device'': {},
''vtpm_refs'': [], ''bootloader'':
'''', ''maxmem'':
32, ''vbd_refs'': []}
[2006-11-07 13:47:00 xend.XendDomainInfo 8512] DEBUG (XendDomainInfo:270) 
XendDomainInfo.createDormant({''on_xend_stop'':
''ignore'', ''features'': '''',
''image'': [''linux'',
[''kernel'', ''/boot/vmlinuz-2.6.16.29-xen''],
[''ramdisk'',
''/boot/initrd-2.6.16.29-xen.img'']],
''kernel_initrd'':
''/boot/initrd-2.6.16.29-xen.img'', ''cpus'':
[], ''vcpu_avail'': 1, ''backend'':
[], ''uuid'':
''db5359b2-3ab2-edb2-c09c-662f1f88c828'',
''kernel_args'': '''',
''on_reboot'': ''restart'',
''cpu_weight'': 256, ''online_vcpus'': 1,
''memory'':
32, ''cpu_cap'': 0, ''kernel_kernel'':
''/boot/vmlinuz-2.6.16.29-xen'',
''on_poweroff'': ''destroy'',
''on_xend_start'': ''ignore'',
''on_crash'':
''restart'', ''vbd_refs'': [],
''device'': {}, ''bootloader'':
'''', ''maxmem'': 32,
''shadow_memory'': 0, ''name'':
''GentooAPI'', ''bootloader_args'': None,
''max_vcpu_id'': 0, ''vcpus'': 1,
''vif_refs'': [], ''vtpm_refs'': [],
''security'':
[]})
[2006-11-07 13:47:00 xend 8512] DEBUG (XendConfig:299) XendConfig: 
{''on_xend_stop'': ''ignore'',
''memory'': 32, ''on_poweroff'':
''destroy'',
''features'': '''', ''image'':
[''linux'', [''kernel'',
''/boot/vmlinuz-2.6.16.29-xen''], [''ramdisk'', 
''/boot/initrd-2.6.16.29-xen.img'']],
''kernel_initrd'':
''/boot/initrd-2.6.16.29-xen.img'', ''cpus'':
[], ''on_xend_start'': ''ignore'',
''kernel_kernel'':
''/boot/vmlinuz-2.6.16.29-xen'', ''vbd_refs'':
[],
''shadow_memory'': 0, ''vcpu_avail'': 1,
''device'': {}, ''on_crash'':
''restart'',
''backend'': [], ''bootloader'':
'''', ''uuid'':
''db5359b2-3ab2-edb2-c09c-662f1f88c828'',
''kernel_args'': '''',
''on_reboot'':
''restart'', ''bootloader_args'': None,
''name'': ''GentooAPI'',
''max_vcpu_id'': 0,
''vcpus'': 1, ''cpu_weight'': 256,
''vif_refs'': [], ''online_vcpus'': 1,
''cpu_cap'': 0, ''vtpm_refs'': [],
''security'': [], ''maxmem'': 32}
[2006-11-07 13:47:00 xend 8512] DEBUG (XendDomain:616) Creating new 
managed domain: GentooAPI: db5359b2-3ab2-edb2-c09c-662f1f88c828

First GentooAPI domain created.

[2006-11-07 13:47:02 xend 8512] DEBUG (XendConfig:299) XendConfig: 
{''kernel_kernel'':
''/boot/vmlinuz-2.6.16.29-xen'',
''on_poweroff'': ''destroy'',
''name'': ''GentooAPI'',
''kernel_args'': '''',
''on_reboot'': ''restart'',
''image'':
''(linux\n    (kernel /boot/vmlinuz-2.6.16.29-xen)\n    (ramdisk 
/boot/initrd-2.6.16.29-xen.img)\n)\n'',
''kernel_initrd'':
''/boot/initrd-2.6.16.29-xen.img'',
''on_crash'': ''restart'',
''vif_refs'': [],
''memory'': 32, ''device'': {},
''vtpm_refs'': [], ''bootloader'':
'''', ''maxmem'':
32, ''vbd_refs'': []}
[2006-11-07 13:47:02 xend.XendDomainInfo 8512] DEBUG (XendDomainInfo:270) 
XendDomainInfo.createDormant({''on_xend_stop'':
''ignore'', ''features'': '''',
''image'': [''linux'',
[''kernel'', ''/boot/vmlinuz-2.6.16.29-xen''],
[''ramdisk'',
''/boot/initrd-2.6.16.29-xen.img'']],
''kernel_initrd'':
''/boot/initrd-2.6.16.29-xen.img'', ''cpus'':
[], ''vcpu_avail'': 1, ''backend'':
[], ''uuid'':
''dfbab48d-c65b-6bf0-d078-b54e8eaee921'',
''kernel_args'': '''',
''on_reboot'': ''restart'',
''cpu_weight'': 256, ''online_vcpus'': 1,
''memory'':
32, ''cpu_cap'': 0, ''kernel_kernel'':
''/boot/vmlinuz-2.6.16.29-xen'',
''on_poweroff'': ''destroy'',
''on_xend_start'': ''ignore'',
''on_crash'':
''restart'', ''vbd_refs'': [],
''device'': {}, ''bootloader'':
'''', ''maxmem'': 32,
''shadow_memory'': 0, ''name'':
''GentooAPI'', ''bootloader_args'': None,
''max_vcpu_id'': 0, ''vcpus'': 1,
''vif_refs'': [], ''vtpm_refs'': [],
''security'':
[]})
[2006-11-07 13:47:02 xend 8512] DEBUG (XendConfig:299) XendConfig: 
{''on_xend_stop'': ''ignore'',
''memory'': 32, ''on_poweroff'':
''destroy'',
''features'': '''', ''image'':
[''linux'', [''kernel'',
''/boot/vmlinuz-2.6.16.29-xen''], [''ramdisk'', 
''/boot/initrd-2.6.16.29-xen.img'']],
''kernel_initrd'':
''/boot/initrd-2.6.16.29-xen.img'', ''cpus'':
[], ''on_xend_start'': ''ignore'',
''kernel_kernel'':
''/boot/vmlinuz-2.6.16.29-xen'', ''vbd_refs'':
[],
''shadow_memory'': 0, ''vcpu_avail'': 1,
''device'': {}, ''on_crash'':
''restart'',
''backend'': [], ''bootloader'':
'''', ''uuid'':
''dfbab48d-c65b-6bf0-d078-b54e8eaee921'',
''kernel_args'': '''',
''on_reboot'':
''restart'', ''bootloader_args'': None,
''name'': ''GentooAPI'',
''max_vcpu_id'': 0,
''vcpus'': 1, ''cpu_weight'': 256,
''vif_refs'': [], ''online_vcpus'': 1,
''cpu_cap'': 0, ''vtpm_refs'': [],
''security'': [], ''maxmem'': 32}
[2006-11-07 13:47:02 xend 8512] DEBUG (XendDomain:616) Creating new 
managed domain: GentooAPI: dfbab48d-c65b-6bf0-d078-b54e8eaee921

Second GentooAPI domain created.


   Stefan
> 
> Ewan.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

This here solves the problem.

diff -r 2408c042a276 tools/python/xen/xend/XendDomain.py
--- a/tools/python/xen/xend/XendDomain.py                Wed Nov  8 
11:13:50 2006
+++ b/tools/python/xen/xend/XendDomain.py                Wed Nov  8 
09:58:35 2006
@@ -472,7 +472,7 @@
         self.domains_lock.acquire()
         try:
             # lookup by name
-            match = [dom for dom in self.domains.values() \
+            match = [dom for dom in self.managed_domains.values() \
                      if dom.getName() == domid]
             if match:
                 return match[0]

 Stefan


xen-devel-bounces@lists.xensource.com wrote on 11/06/2006 06:46:03 PM:
> On Mon, Nov 06, 2006 at 03:44:16PM -0500, Stefan Berger wrote:
> 
> > Hello Ewan,
> > 
> >    something must have broken while moving the API code into the
> > xen-unstable repository. I can create multiple Gentoo domains using
> > xapi.py and xapi.domcfg.py, but cannot delete any of  them.
> 
> It wouldn''t surprise me if there were a few breakages.  What do
you get
> in the logs?
> 
> Ewan.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

Stefan Berger wrote:
>
> This here solves the problem.
>
> diff -r 2408c042a276 tools/python/xen/xend/XendDomain.py
> --- a/tools/python/xen/xend/XendDomain.py                 Wed Nov  8 
> 11:13:50 2006
> +++ b/tools/python/xen/xend/XendDomain.py                 Wed Nov  8 
> 09:58:35 2006
> @@ -472,7 +472,7 @@
>         self.domains_lock.acquire()
>         try:
>             # lookup by name
> -            match = [dom for dom in self.domains.values() \
> +            match = [dom for dom in self.managed_domains.values() \
>                      if dom.getName() == domid]
>             if match:
>                 return match[0]
>
>  Stefan
Ah, this is essentially the xend patch I was referring to in 
http://lists.xensource.com/archives/html/xen-devel/2006-11/msg00361.html.  
In domain_lookup_nr, it appears only ''non-inactive'' domains
are in the
domains dictionary, so this routine would not find the inactive domain 
that I was attempting to destroy.  I took a slightly different approach 
(patch attached), but given my knowledge of the code was not sure of any 
potential side affects.  Also I wasn''t sure why we are building a list 
only to return the first item.  Why not return the item when found?  I 
realize that names are not unique but the current code doesn''t handle 
duplicates anyway.

Ewan, can you comment on either of these patches?  This routine needs to 
accommodate inactive domains as well.

Regards,
Jim



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

On Wed, Nov 08, 2006 at 10:34:24AM -0700, Jim Fehlig wrote:
> Stefan Berger wrote:
> >
> >This here solves the problem.
> >
> >diff -r 2408c042a276 tools/python/xen/xend/XendDomain.py
> >--- a/tools/python/xen/xend/XendDomain.py                 Wed Nov  8 
> >11:13:50 2006
> >+++ b/tools/python/xen/xend/XendDomain.py                 Wed Nov  8 
> >09:58:35 2006
> >@@ -472,7 +472,7 @@
> >        self.domains_lock.acquire()
> >        try:
> >            # lookup by name
> >-            match = [dom for dom in self.domains.values() \
> >+            match = [dom for dom in self.managed_domains.values() \
> >                     if dom.getName() == domid]
> >            if match:
> >                return match[0]
> >
> > Stefan
> 
> Ah, this is essentially the xend patch I was referring to in 
> http://lists.xensource.com/archives/html/xen-devel/2006-11/msg00361.html.  
> In domain_lookup_nr, it appears only ''non-inactive''
domains are in the
> domains dictionary, so this routine would not find the inactive domain 
> that I was attempting to destroy.  I took a slightly different approach 
> (patch attached), but given my knowledge of the code was not sure of any 
> potential side affects.  Also I wasn''t sure why we are building a
list
> only to return the first item.  Why not return the item when found?  I 
> realize that names are not unique but the current code doesn''t
handle
> duplicates anyway.
> 
> Ewan, can you comment on either of these patches?  This routine needs to 
> accommodate inactive domains as well.
Yes, we certainly need to include both lists here -- Stefan''s patch
breaks
other things unfortunately.  Your patch looks OK to me, though I''ll
give
Alastair time to comment -- he''s worked on this more recently than me.

Ewan.

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

Ewan Mellor wrote:
>   o  xm suspend - Save a VM to a location under Xend''s management
>   o  xm resume  - Resume a VM from that same location
Does this preclude running Xen in an environment with no persistent 
storage?  For example we now suspend to pipe which actually results in 
the suspend image being stored off the Xen host.

Pat

-- 
Patrick O''Rourke
porourke@egenera.com

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

On Wed, Nov 08, 2006 at 01:29:49PM -0500, Patrick O''Rourke wrote:
> Ewan Mellor wrote:
> 
> >  o  xm suspend - Save a VM to a location under Xend''s
management
> >  o  xm resume  - Resume a VM from that same location
> 
> Does this preclude running Xen in an environment with no persistent 
> storage?  For example we now suspend to pipe which actually results in 
> the suspend image being stored off the Xen host.
We''ve not taken xm save and xm restore away, so you can still use them
if you
know what you''re doing.  We''re trying to encourage people not
to do that,
because of the non-obvious (but very real) risk to their data, but if
it''s
integrated into a wider protective framework, then that''s fine of
course.

Would you like an API call that better supported this use-case?  In the long
run, might your integration be easier if Xend supported "save to this
address/port" or something like that?

Ewan.

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

Jim Fehlig <jfehlig@novell.com> wrote on 11/08/2006 12:34:24 PM:
> Stefan Berger wrote:
> >
> > This here solves the problem.
> >
> > diff -r 2408c042a276 tools/python/xen/xend/XendDomain.py
> > --- a/tools/python/xen/xend/XendDomain.py                 Wed Nov  8 
> > 11:13:50 2006
> > +++ b/tools/python/xen/xend/XendDomain.py                 Wed Nov  8 
> > 09:58:35 2006
> > @@ -472,7 +472,7 @@
> >         self.domains_lock.acquire()
> >         try:
> >             # lookup by name
> > -            match = [dom for dom in self.domains.values() \
> > +            match = [dom for dom in self.managed_domains.values() \
> >                      if dom.getName() == domid]
> >             if match:
> >                 return match[0]
> >
> >  Stefan
> 
> Ah, this is essentially the xend patch I was referring to in 
> 
http://lists.xensource.com/archives/html/xen-devel/2006-11/msg00361.html.
> In domain_lookup_nr, it appears only ''non-inactive''
domains are in the
> domains dictionary, so this routine would not find the inactive domain 
> that I was attempting to destroy.  I took a slightly different approach 
> (patch attached), but given my knowledge of the code was not sure of any 
> potential side affects.  Also I wasn''t sure why we are building a
list
> only to return the first item.  Why not return the item when found?  I 
> realize that names are not unique but the current code doesn''t
handle
> duplicates anyway.
> 
> Ewan, can you comment on either of these patches?  This routine needs to 
> accommodate inactive domains as well.
Just another comment: For me it solves the problem of restricting domain 
creation to only allow one domain with a certain name *and* being able to 
destroy the domain afterwards...

  Stefan
> 
> Regards,
> Jim
> 
> diff -r 8eb8c0085604 tools/python/xen/xend/XendDomain.py
> --- a/tools/python/xen/xend/XendDomain.py   Mon Nov 06 16:36:51 2006 
+0000
> +++ b/tools/python/xen/xend/XendDomain.py   Wed Nov 08 10:32:26 2006 
-0700
> @@ -472,10 +472,9 @@ class XendDomain:
>          self.domains_lock.acquire()
>          try:
>              # lookup by name
> -            match = [dom for dom in self.domains.values() \
> -                     if dom.getName() == domid]
> -            if match:
> -                return match[0]
> +            for dom in self.domains.values() + 
self.managed_domains.values():
> +                if dom.getName() == domid:
> +                    return dom
> 
>              # lookup by id
>              try:

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

Ewan Mellor wrote:
> Would you like an API call that better supported this use-case?  In the
long
> run, might your integration be easier if Xend supported "save to this
> address/port" or something like that?
Yes, I believe that would suit our needs.

Pat

-- 
Patrick O''Rourke
porourke@egenera.com

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