[...]
> >
> > Differences from QEMU/Xen:
> >
> > * ID and name are same
>
> So open VZ has no kind of unique identifier aside from its ID numbers ?
Yeah, true.
>
> > * Not possible to create temporary domains and do away with them.
> > Creating a domain will involve untarring a template cache
This patch is the first step towards supporting USB devices in libvirt
XML format. As per the original thread some months back[1], I'm the
grouping is being done based on device classes, rather than bus types.
So this first patch is actually introducing the concept of 'input'
devices. This is best
On Mon, Jul 16, 2007 at 02:32:01PM +0100, Daniel P. Berrange wrote:
> On Mon, Jul 16, 2007 at 03:50:07AM -0400, Daniel Veillard wrote:
> > On Fri, Jul 13, 2007 at 05:07:03PM +0100, Daniel P. Berrange wrote:
> > > The attached patch introduces a new XML element for specifying information
> > > about
On Mon, Jul 16, 2007 at 01:58:41PM +0530, Shuveb Hussain wrote:
> Hi,
> Here are the OpenVZ support patches. The .c and .h files go into src/
> This is being released in the spirit of releasing early. Only the basic
> stuff is done and development is continuing.
>
> What works:
>
> * Getting numb
On Mon, Jul 16, 2007 at 10:29:36PM +0100, Richard W.M. Jones wrote:
> I think the conversation is heading towards a consensus around an API
> looking like that below. Let me know overnight if there are problems,
> otherwise I'll produce an implementation for consideration tomorrow morning.
>
>
I think the conversation is heading towards a consensus around an API
looking like that below. Let me know overnight if there are problems,
otherwise I'll produce an implementation for consideration tomorrow morning.
A hypervisor-agnostic call would look like this:
ddom =
virDomainMigra
On Mon, Jul 16, 2007 at 03:57:19PM -0400, Daniel Veillard wrote:
> On Mon, Jul 16, 2007 at 06:52:15PM +0100, Richard W.M. Jones wrote:
> > Daniel P. Berrange wrote:
> > >On Mon, Jul 16, 2007 at 04:56:53PM +0100, Richard W.M. Jones wrote:
> > >>Dan Berrange wrote:
> > >>>I don't see the point in thi
On Mon, Jul 16, 2007 at 06:52:15PM +0100, Richard W.M. Jones wrote:
> Daniel P. Berrange wrote:
> >On Mon, Jul 16, 2007 at 04:56:53PM +0100, Richard W.M. Jones wrote:
> >>Dan Berrange wrote:
> >>>I don't see the point in this. Libvirt already knows both hostnames
> >>>of the source & destination.
>
Daniel P. Berrange wrote:
On Mon, Jul 16, 2007 at 02:23:32PM -0500, Anthony Liguori wrote:
Daniel P. Berrange wrote:
On Mon, Jul 16, 2007 at 06:34:57PM +0100, Richard W.M. Jones wrote:
Daniel P. Berrange wrote:
On Mon, Jul 16, 2007 at 11:30:33AM -0500, Anthony Li
On Mon, Jul 16, 2007 at 02:23:32PM -0500, Anthony Liguori wrote:
> Daniel P. Berrange wrote:
> >On Mon, Jul 16, 2007 at 06:34:57PM +0100, Richard W.M. Jones wrote:
> >
> >>Daniel P. Berrange wrote:
> >>
> >>>On Mon, Jul 16, 2007 at 11:30:33AM -0500, Anthony Liguori wrote:
> >>>
> Ri
Daniel P. Berrange wrote:
On Mon, Jul 16, 2007 at 06:34:57PM +0100, Richard W.M. Jones wrote:
Daniel P. Berrange wrote:
On Mon, Jul 16, 2007 at 11:30:33AM -0500, Anthony Liguori wrote:
Richard W.M. Jones wrote:
Anthony Liguori wrote:
For instance, let's say
On Mon, Jul 16, 2007 at 06:34:57PM +0100, Richard W.M. Jones wrote:
> Daniel P. Berrange wrote:
> >On Mon, Jul 16, 2007 at 11:30:33AM -0500, Anthony Liguori wrote:
> >>Richard W.M. Jones wrote:
> >>>Anthony Liguori wrote:
> For instance, let's say at a university they use an ldap directory to
Richard W.M. Jones wrote:
Daniel P. Berrange wrote:
On Mon, Jul 16, 2007 at 11:30:33AM -0500, Anthony Liguori wrote:
Richard W.M. Jones wrote:
Anthony Liguori wrote:
For instance, let's say at a university they use an ldap directory
to authenticate users and they decide to implement a migrati
Daniel P. Berrange wrote:
On Mon, Jul 16, 2007 at 04:56:53PM +0100, Richard W.M. Jones wrote:
Dan Berrange wrote:
I don't see the point in this. Libvirt already knows both hostnames
of the source & destination.
It's really very hard for libvirt to accurately determine the hostname
of the desti
On Mon, Jul 16, 2007 at 04:56:53PM +0100, Richard W.M. Jones wrote:
> Dan Berrange wrote:
> >I don't see the point in this. Libvirt already knows both hostnames
> >of the source & destination.
>
> It's really very hard for libvirt to accurately determine the hostname
> of the destination as seen
On Mon, Jul 16, 2007 at 03:43:48PM +0100, Richard W.M. Jones wrote:
> Dan Smith wrote:
> >RJ> * Params is a linked list of hypervisor-specific parameters. Each
> >RJ> * element is a virMigrateParamPtr containing the following fields:
> >RJ> * name Parameter name being set.
> >RJ
Daniel P. Berrange wrote:
On Mon, Jul 16, 2007 at 11:30:33AM -0500, Anthony Liguori wrote:
Richard W.M. Jones wrote:
Anthony Liguori wrote:
For instance, let's say at a university they use an ldap directory to
authenticate users and they decide to implement a migration handler
that uses that
On Mon, Jul 16, 2007 at 10:58:18AM -0500, Anthony Liguori wrote:
> John Levon wrote:
> >On Mon, Jul 16, 2007 at 10:47:59AM -0500, Anthony Liguori wrote:
> >
> >
> >>>If we need to express some choice of data channel, TCP, vs SSH, vs
> >>>SSL/TLS
> >>>then figure out a way to expose that in the A
On Mon, Jul 16, 2007 at 11:30:33AM -0500, Anthony Liguori wrote:
> Richard W.M. Jones wrote:
> >Anthony Liguori wrote:
> >>For instance, let's say at a university they use an ldap directory to
> >>authenticate users and they decide to implement a migration handler
> >>that uses that for authentic
Richard W.M. Jones wrote:
Anthony Liguori wrote:
For instance, let's say at a university they use an ldap directory to
authenticate users and they decide to implement a migration handler
that uses that for authentication. They may name this "uni://" and
it'll just work. How would they get at
Anthony Liguori wrote:
For instance, let's say at a university they use an ldap directory to
authenticate users and they decide to implement a migration handler that
uses that for authentication. They may name this "uni://" and it'll
just work. How would they get at this in libvirt without ex
John Levon wrote:
On Mon, Jul 16, 2007 at 04:56:53PM +0100, Richard W.M. Jones wrote:
* @resource: (optional) specify resource limit in Mbps
*
* The maximum bandwidth (in Mbps) that will be used to do migration
* can be specified with the resource parameter. If set to 0,
* libvirt will
On Mon, Jul 16, 2007 at 05:09:28PM +0100, Richard W.M. Jones wrote:
> >Will there be another way to find this out? It would be unfortunate if
> >the only way was to actually attempt it.
>
> virConnectGetCapabilities should return something to say whether this is
> supported. I'll add that to my
John Levon wrote:
On Mon, Jul 16, 2007 at 04:56:53PM +0100, Richard W.M. Jones wrote:
* @resource: (optional) specify resource limit in Mbps
*
* The maximum bandwidth (in Mbps) that will be used to do migration
* can be specified with the resource parameter. If set to 0,
* libvirt will ch
Daniel P. Berrange wrote:
On Mon, Jul 16, 2007 at 10:47:59AM -0500, Anthony Liguori wrote:
Its depends where you need to expose it. For any single deployment of
do you need to be able to use all possible transports ? I think that
some people will choose SSH, others will choose SSL, other's so
On Mon, Jul 16, 2007 at 04:56:53PM +0100, Richard W.M. Jones wrote:
> * @resource: (optional) specify resource limit in Mbps
> *
> * The maximum bandwidth (in Mbps) that will be used to do migration
> * can be specified with the resource parameter. If set to 0,
> * libvirt will choose a suit
John Levon wrote:
On Mon, Jul 16, 2007 at 10:47:59AM -0500, Anthony Liguori wrote:
If we need to express some choice of data channel, TCP, vs SSH, vs SSL/TLS
then figure out a way to expose that in the API with an hypervisor agnostic
way. Exposing raw QEMU migration URIs is *not* hypervisor
Dan Berrange wrote:
I don't see the point in this. Libvirt already knows both hostnames
of the source & destination.
It's really very hard for libvirt to accurately determine the hostname
of the destination as seen from the source. Consider the case where you
have a multi-homed host with a g
On Mon, Jul 16, 2007 at 10:47:59AM -0500, Anthony Liguori wrote:
> Daniel P. Berrange wrote:
> >On Mon, Jul 16, 2007 at 08:20:54AM -0700, Dan Smith wrote:
> >>DB> I don't. The API should be hypervisor agnostic. Needing to pass
> >>DB> HV specific attributes to make it works shows we have failed.
>
On Mon, Jul 16, 2007 at 10:47:59AM -0500, Anthony Liguori wrote:
> >If we need to express some choice of data channel, TCP, vs SSH, vs SSL/TLS
> >then figure out a way to expose that in the API with an hypervisor agnostic
> >way. Exposing raw QEMU migration URIs is *not* hypervisor agnostic.
>
>
Daniel P. Berrange wrote:
On Mon, Jul 16, 2007 at 08:20:54AM -0700, Dan Smith wrote:
DB> I don't. The API should be hypervisor agnostic. Needing to pass
DB> HV specific attributes to make it works shows we have failed.
In that case, haven't we already failed with virDomainCreate() since
it tak
On Mon, Jul 16, 2007 at 11:40:30AM -0400, Daniel Veillard wrote:
> On Mon, Jul 16, 2007 at 08:20:54AM -0700, Dan Smith wrote:
> > DB> I don't. The API should be hypervisor agnostic. Needing to pass
> > DB> HV specific attributes to make it works shows we have failed.
> >
> > In that case, haven't
On Mon, Jul 16, 2007 at 08:20:54AM -0700, Dan Smith wrote:
> DB> I don't. The API should be hypervisor agnostic. Needing to pass
> DB> HV specific attributes to make it works shows we have failed.
>
> In that case, haven't we already failed with virDomainCreate() since
> it takes hypervisor-speci
On Mon, Jul 16, 2007 at 08:20:54AM -0700, Dan Smith wrote:
> DB> I don't. The API should be hypervisor agnostic. Needing to pass
> DB> HV specific attributes to make it works shows we have failed.
>
> In that case, haven't we already failed with virDomainCreate() since
> it takes hypervisor-speci
DB> I don't. The API should be hypervisor agnostic. Needing to pass
DB> HV specific attributes to make it works shows we have failed.
In that case, haven't we already failed with virDomainCreate() since
it takes hypervisor-specific XML? Doesn't the presence of
VIR_DEVICE_RW_FORCE imply knowledge
Richard W.M. Jones wrote:
To cut to the chase, this is the proposed additional libvirt call to
support migration. Please also read my explanation below.
/**
* virDomainMigrate:
* @domain: a domain object
* @dconn: destination host (a connection object)
* @flags: flags
* @dname: (optional)
On Mon, Jul 16, 2007 at 07:22:27AM -0700, Dan Smith wrote:
> RJ> * Params is a linked list of hypervisor-specific parameters. Each
> RJ> * element is a virMigrateParamPtr containing the following fields:
> RJ> * name Parameter name being set.
> RJ> * value A unio
On Mon, Jul 16, 2007 at 01:47:38PM +0100, Richard W.M. Jones wrote:
> To cut to the chase, this is the proposed additional libvirt call to
> support migration. Please also read my explanation below.
>
> /**
> * virDomainMigrate:
> * @domain: a domain object
> * @dconn: destination host (a con
Dan Smith wrote:
RJ> * Params is a linked list of hypervisor-specific parameters. Each
RJ> * element is a virMigrateParamPtr containing the following fields:
RJ> * name Parameter name being set.
RJ> * value A union expressing the value.
RJ> * value.strv
RJ> * Params is a linked list of hypervisor-specific parameters. Each
RJ> * element is a virMigrateParamPtr containing the following fields:
RJ> * name Parameter name being set.
RJ> * value A union expressing the value.
RJ> * value.strv A string valu
On Mon, Jul 16, 2007 at 03:50:07AM -0400, Daniel Veillard wrote:
> On Fri, Jul 13, 2007 at 05:07:03PM +0100, Daniel P. Berrange wrote:
> > The attached patch introduces a new XML element for specifying information
> > about the guest (BIOS) clock. For Xen HVM, and QEMU / KVM guests this is
> > used
This is a test program. You can fiddle with the various strings to
control what domain it migrates. (If you leave the program as-is, then
it will do a Xen migration from localhost to localhost, which screws up
xend).
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Re
To cut to the chase, this is the proposed additional libvirt call to
support migration. Please also read my explanation below.
/**
* virDomainMigrate:
* @domain: a domain object
* @dconn: destination host (a connection object)
* @flags: flags
* @dname: (optional) rename domain to this at d
This is a patch which adds virDomainMigrate. It is incomplete (only
supports Xen, no remote support, no qemu support), but I hope you'll
look at the proposed interface and discuss the parameters.
More in the following two emails.
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com
Hi,
Here are the OpenVZ support patches. The .c and .h files go into src/
This is being released in the spirit of releasing early. Only the basic
stuff is done and development is continuing.
What works:
* Getting number of active/inactive domains
* Listing active/inactive domains
* Creating a dom
On Fri, Jul 13, 2007 at 05:07:03PM +0100, Daniel P. Berrange wrote:
> The attached patch introduces a new XML element for specifying information
> about the guest (BIOS) clock. For Xen HVM, and QEMU / KVM guests this is
> used to specifyc whether the guest clock should be in UTC, or localtime.
> Th
46 matches
Mail list logo
