Mailing List Archive

xen-api-bounces@lists.xensource.com wrote on 10/08/2006 05:00:13 PM:

> All,
>
> I have put a tree on Xenbits containing our work-in-progress regarding a
> Xend that supports the new Xen-API. You may pull from this tree using
>
> hg clone http://xenbits.xensource.com/ext/xen-api.hg

I will supply a patch for xend to reflect the previously submitted Xen-API
changes for vTPM support. I want to separate the vTPM support into an
extra class for having the possibility to extend that class in the future.

After looking at the implementation it looks like virtual machine
configurations will live on the CIM client side and through a sequence of
create methods are going to create a VM. Is this correct?

Stefan

On Mon, Oct 09, 2006 at 10:42:52AM -0400, Stefan Berger wrote:

> xen-api-bounces@lists.xensource.com wrote on 10/08/2006 05:00:13 PM:
>
> > All,
> >
> > I have put a tree on Xenbits containing our work-in-progress regarding a
> > Xend that supports the new Xen-API. You may pull from this tree using
> >
> > hg clone http://xenbits.xensource.com/ext/xen-api.hg
>
> I will supply a patch for xend to reflect the previously submitted Xen-API
> changes for vTPM support. I want to separate the vTPM support into an
> extra class for having the possibility to extend that class in the future.

How do you expect this to differ from the vTPM support in Xend today?

> After looking at the implementation it looks like virtual machine
> configurations will live on the CIM client side and through a sequence of
> create methods are going to create a VM. Is this correct?

No, not at all. VM configurations are stored on the server side -- the
appropriate details are passed in to a constructor, and then persisted by Xend
on its side. What gave you the impression that configurations would live on
the client side?

Ewan.

_______________________________________________
xen-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

Ewan Mellor <ewan@xensource.com> wrote on 10/09/2006 12:38:08 PM:

> On Mon, Oct 09, 2006 at 10:42:52AM -0400, Stefan Berger wrote:
>
> > xen-api-bounces@lists.xensource.com wrote on 10/08/2006 05:00:13 PM:
> >
> > > All,
> > >
> > > I have put a tree on Xenbits containing our work-in-progress
regarding a
> > > Xend that supports the new Xen-API. You may pull from this tree
using
> > >
> > > hg clone http://xenbits.xensource.com/ext/xen-api.hg
> >
> > I will supply a patch for xend to reflect the previously submitted
Xen-API
> > changes for vTPM support. I want to separate the vTPM support into an
> > extra class for having the possibility to extend that class in the
future.
>
> How do you expect this to differ from the vTPM support in Xend today?

The move of aspects of this device into its own class puts it line with
all the other devices in regards to handling of properties: uuid,
driver_type, VM reference to where backend is located, its instance number
etc.. If I now interpret the usage of for example the VTPM.create() method
correctly, then a VM with an associated vTPM needs to have this method for
getting an approriate entry written into its VM configuration file.

In the future extensions could be used to manage the actual state of a
TPM, for example its owner password etc.

Stefan

On Sun, Oct 08, 2006 at 10:00:13PM +0100, Ewan Mellor wrote:
> All,
>
> I have put a tree on Xenbits containing our work-in-progress regarding a
> Xend that supports the new Xen-API. You may pull from this tree using
>
> hg clone http://xenbits.xensource.com/ext/xen-api.hg
>
> This tree contains the new lifecycle work (from the patches sent to
> xen-devel as an RFC a few months ago), and the major part of the work
> required to support the new API and new configuration file format.

Excellant, thanks for making this available.

> Please note that there are a few instances where the old protocol is
> currently broken, or has subtly changed in semantics. The intention for
> Xen 3.0.4 is to preserve the existing XML-RPC protocol, and to support
> all the existing configuration file formats, so rest assured that if
> this tree shows any breakages at the moment, they will be fixed by the
> time Xen 3.0.4 is released. We would appreciate it if you let us know
> about any such breakages.

I've not tested your new tree directly yet, but here's some feedback on
the lifecycle patches based on the last set which were sent to xen-devel
(which I assume are same as those in your new tree)

With the lifecycle patches, 'xm list' and 'GET /xend/domains' will now
include inactive domains as well as active domains. eg

# xm list
Name ID Mem(MiB) VCPUs State Time(s)
Domain-0 0 594 2 r----- 22.2
guest3 -1 400 1 ------ 14.7

This can cause a slight compatability problem because there has previously
been the tacit assumption that "ID" is a unique way to refer to a domain
running on a box. With all inactive domains now returning '-1' this is no
longer valid. So I think that returning inactive domains by default for
commands line 'xm list' or the raw 'GET /xend/domains' may well cause
compatability problems for existing users of this command / API.

Libvirt at least would need to be modified to deal with this change off the
/xend/domains request.

At the same time though, its clearly desirable to have a single API to list
all domains. So I'd like to propose a very slight modification, thus:

1. /xend/domains - only returns active domains, as per current semantics
2. Add support for an optional parameter '?scope=XXXX' where XXX can be
one of 'active', 'inactive', 'all'. eg, 'GET /xend/domains?scope=inactive'

If we follow this through to 'xm list' we could allow

xm list --scope=all
xm list --scope=inactive
xm list --scope=active

Or simplify a little further

xm list --all
xm list --inactive
xm list --active


In the actual listing of domains in XM, I think its probably more desirable
to just have a '-' in the ID column for inactive domains, rather than -1,s
since this indicates more clearly that there is no effective ID for inactive
domains, eg

# xm list
Name ID Mem(MiB) VCPUs State Time(s)
Domain-0 0 594 2 r----- 22.2
guest3 - 400 1 ------ 14.7

Finally, I'd also like to see the 'xend_config_version' field for 'xm info'
incremented from '2' to '3' to allow clients to easily detect that the XenD
they're talking to has this new capability for configs.

There was one other issue, but I can't remember it right now & I don't
think it was a compatability issue anyway.

So aside from the listing of domains stuff the lifecycle patches look pretty
reasonable to me, thus far.

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

_______________________________________________
xen-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

On Mon, Oct 09, 2006 at 06:47:37PM +0100, Daniel P. Berrange wrote:

> With the lifecycle patches, 'xm list' and 'GET /xend/domains' will now
> include inactive domains as well as active domains. eg
>
> # xm list
> Name ID Mem(MiB) VCPUs State Time(s)
> Domain-0 0 594 2 r----- 22.2
> guest3 -1 400 1 ------ 14.7
>
> This can cause a slight compatability problem because there has previously
> been the tacit assumption that "ID" is a unique way to refer to a domain
> running on a box. With all inactive domains now returning '-1' this is no
> longer valid. So I think that returning inactive domains by default for
> commands line 'xm list' or the raw 'GET /xend/domains' may well cause
> compatability problems for existing users of this command / API.

Note that the domain ID is a unique identifier for the domain, but _not_ a
unique identifier for a VM. If a VM is migrating to localhost, for example,
then a given VM may have two different domain IDs.

That said, I certainly agree that the change in semantics of the old protocol
is inappropriate, and I'll put that on the list to be fixed. Your
proposal for a flag to xm list sounds fine to me also (though I'm
tempted to word it as "state=Running" rather than "scope=active", to
reuse the existing VM state mechanisms). Regardless of the details, the
basic idea is sound, and we'll put that in certainly.

> In the actual listing of domains in XM, I think its probably more desirable
> to just have a '-' in the ID column for inactive domains, rather than -1,s
> since this indicates more clearly that there is no effective ID for inactive
> domains, eg
>
> # xm list
> Name ID Mem(MiB) VCPUs State Time(s)
> Domain-0 0 594 2 r----- 22.2
> guest3 - 400 1 ------ 14.7

Sure, sounds fine.

> Finally, I'd also like to see the 'xend_config_version' field for 'xm info'
> incremented from '2' to '3' to allow clients to easily detect that the XenD
> they're talking to has this new capability for configs.

Definitely.

Thanks for that,

Ewan.

_______________________________________________
xen-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

On Mon, Oct 09, 2006 at 11:45:35PM +0100, Ewan Mellor wrote:
> On Mon, Oct 09, 2006 at 06:47:37PM +0100, Daniel P. Berrange wrote:
>
> > With the lifecycle patches, 'xm list' and 'GET /xend/domains' will now
> > include inactive domains as well as active domains. eg
> >
> > # xm list
> > Name ID Mem(MiB) VCPUs State Time(s)
> > Domain-0 0 594 2 r----- 22.2
> > guest3 -1 400 1 ------ 14.7
> >
> > This can cause a slight compatability problem because there has previously
> > been the tacit assumption that "ID" is a unique way to refer to a domain
> > running on a box. With all inactive domains now returning '-1' this is no
> > longer valid. So I think that returning inactive domains by default for
> > commands line 'xm list' or the raw 'GET /xend/domains' may well cause
> > compatability problems for existing users of this command / API.
>
> Note that the domain ID is a unique identifier for the domain, but _not_ a
> unique identifier for a VM. If a VM is migrating to localhost, for example,
> then a given VM may have two different domain IDs.

Ah yes, good point.

> That said, I certainly agree that the change in semantics of the old protocol
> is inappropriate, and I'll put that on the list to be fixed. Your
> proposal for a flag to xm list sounds fine to me also (though I'm
> tempted to word it as "state=Running" rather than "scope=active", to
> reuse the existing VM state mechanisms). Regardless of the details, the
> basic idea is sound, and we'll put that in certainly.

Yeah, 'state' sounds like a better parameter name to me.

> > Finally, I'd also like to see the 'xend_config_version' field for 'xm info'
> > incremented from '2' to '3' to allow clients to easily detect that the XenD
> > they're talking to has this new capability for configs.
>
> Definitely.

Thanks!

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

_______________________________________________
xen-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

Hi Ewan,

I see the XenAPI work has been merged into xen-devel now, but none of
the 3 issues detailed below have been addressed which is going to cause
some compatability problems for existing clients.

Regards,
Dan.

On Mon, Oct 09, 2006 at 11:45:35PM +0100, Ewan Mellor wrote:
> On Mon, Oct 09, 2006 at 06:47:37PM +0100, Daniel P. Berrange wrote:
>
> > With the lifecycle patches, 'xm list' and 'GET /xend/domains' will now
> > include inactive domains as well as active domains. eg
> >
> > # xm list
> > Name ID Mem(MiB) VCPUs State Time(s)
> > Domain-0 0 594 2 r----- 22.2
> > guest3 -1 400 1 ------ 14.7
> >
> > This can cause a slight compatability problem because there has previously
> > been the tacit assumption that "ID" is a unique way to refer to a domain
> > running on a box. With all inactive domains now returning '-1' this is no
> > longer valid. So I think that returning inactive domains by default for
> > commands line 'xm list' or the raw 'GET /xend/domains' may well cause
> > compatability problems for existing users of this command / API.
>
> Note that the domain ID is a unique identifier for the domain, but _not_ a
> unique identifier for a VM. If a VM is migrating to localhost, for example,
> then a given VM may have two different domain IDs.
>
> That said, I certainly agree that the change in semantics of the old protocol
> is inappropriate, and I'll put that on the list to be fixed. Your
> proposal for a flag to xm list sounds fine to me also (though I'm
> tempted to word it as "state=Running" rather than "scope=active", to
> reuse the existing VM state mechanisms). Regardless of the details, the
> basic idea is sound, and we'll put that in certainly.
>
> > In the actual listing of domains in XM, I think its probably more desirable
> > to just have a '-' in the ID column for inactive domains, rather than -1,s
> > since this indicates more clearly that there is no effective ID for inactive
> > domains, eg
> >
> > # xm list
> > Name ID Mem(MiB) VCPUs State Time(s)
> > Domain-0 0 594 2 r----- 22.2
> > guest3 - 400 1 ------ 14.7
>
> Sure, sounds fine.
>
> > Finally, I'd also like to see the 'xend_config_version' field for 'xm info'
> > incremented from '2' to '3' to allow clients to easily detect that the XenD
> > they're talking to has this new capability for configs.
>
> Definitely.
>
> Thanks for that,
>
> Ewan.

--
|=- 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-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api