Re: [Libvir] Re: Next features and target for development

2007-07-11 Thread Anthony Liguori
Dan Smith wrote: AL> It completely ignores issues like authentication and AL> authorization. Excellent point. For that reason, a libvirt connection to the remote makes sense to me. AL> virDomainSend(dom, "url://"); Don't you not want a connection to the remote machine here? Sure. Re

Re: [Libvir] Re: Next features and target for development

2007-07-11 Thread Daniel P. Berrange
On Wed, Jul 11, 2007 at 11:57:28AM -0500, Anthony Liguori wrote: > Dan Smith wrote: > >DV> you really want a pointer to an existing connection, not an URI > >DV> and hostname. Sure you could get the virConnectPtr based on the > >DV> URI, but it's better to rely on the user to do that step > >DV> in

Re: [Libvir] Re: Next features and target for development

2007-07-11 Thread Dan Smith
AL> It completely ignores issues like authentication and AL> authorization. Excellent point. For that reason, a libvirt connection to the remote makes sense to me. AL> virDomainSend(dom, "url://"); Don't you not want a connection to the remote machine here? virDomainSend(dom, rconn, "url

Re: [Libvir] Re: Next features and target for development

2007-07-11 Thread Anthony Liguori
Dan Smith wrote: DV> you really want a pointer to an existing connection, not an URI DV> and hostname. Sure you could get the virConnectPtr based on the DV> URI, but it's better to rely on the user to do that step DV> independantly. So that implies that in order to perform a migration with libvi

Re: [Libvir] Re: Next features and target for development

2007-07-11 Thread Anthony Liguori
Daniel Veillard wrote: On Wed, Jul 11, 2007 at 08:07:48AM -0700, Dan Smith wrote: AL> The goal is to eliminate the distinction between savevm/migrate since AL> they are really the same thing (savevm just pauses the VM first). But from a high level, there are (at least) two distinct managemen

Re: [Libvir] Re: Next features and target for development

2007-07-11 Thread Daniel Veillard
On Wed, Jul 11, 2007 at 09:05:11AM -0700, Dan Smith wrote: > DV> you really want a pointer to an existing connection, not an URI > DV> and hostname. Sure you could get the virConnectPtr based on the > DV> URI, but it's better to rely on the user to do that step > DV> independantly. > > So that imp

Re: [Libvir] Re: Next features and target for development

2007-07-11 Thread Dan Smith
DV> you really want a pointer to an existing connection, not an URI DV> and hostname. Sure you could get the virConnectPtr based on the DV> URI, but it's better to rely on the user to do that step DV> independantly. So that implies that in order to perform a migration with libvirt, the user will n

Re: [Libvir] Re: Next features and target for development

2007-07-11 Thread Daniel Veillard
On Wed, Jul 11, 2007 at 08:07:48AM -0700, Dan Smith wrote: > AL> The goal is to eliminate the distinction between savevm/migrate since > AL> they are really the same thing (savevm just pauses the VM first). > > But from a high level, there are (at least) two distinct management > operations in my

Re: [Libvir] Re: Next features and target for development

2007-07-11 Thread Dan Smith
AL> The goal is to eliminate the distinction between savevm/migrate since AL> they are really the same thing (savevm just pauses the VM first). But from a high level, there are (at least) two distinct management operations in my mind: relocation and checkpointing. Relocation implies that a guest

Re: [Libvir] Re: Next features and target for development

2007-07-11 Thread Daniel P. Berrange
On Wed, Jul 11, 2007 at 09:26:38AM -0500, Anthony Liguori wrote: > Daniel P. Berrange wrote: > >On Wed, Jul 11, 2007 at 08:59:08AM -0500, Anthony Liguori wrote: > > > >>Till Maas wrote: > >> > >>>On Mi Juli 11 2007, Richard W.M. Jones wrote: > >>> > >>> > I'm interested to know how

Re: [Libvir] Re: Next features and target for development

2007-07-11 Thread Anthony Liguori
Daniel P. Berrange wrote: On Wed, Jul 11, 2007 at 08:59:08AM -0500, Anthony Liguori wrote: Till Maas wrote: On Mi Juli 11 2007, Richard W.M. Jones wrote: I'm interested to know how VirtualBox / VMWare deal with disk storage. Do they provide their own storage subsystems which su

Re: [Libvir] Re: Next features and target for development

2007-07-11 Thread Daniel P. Berrange
On Wed, Jul 11, 2007 at 08:59:08AM -0500, Anthony Liguori wrote: > Till Maas wrote: > >On Mi Juli 11 2007, Richard W.M. Jones wrote: > > > >>I'm interested to know how VirtualBox / VMWare deal with disk storage. > >>Do they provide their own storage subsystems which support this or do > >>they inte

[Libvir] Re: Next features and target for development

2007-07-11 Thread Anthony Liguori
Till Maas wrote: On Mi Juli 11 2007, Richard W.M. Jones wrote: I'm interested to know how VirtualBox / VMWare deal with disk storage. Do they provide their own storage subsystems which support this or do they interact with things like LVM? The use their own subsystem. VMWare uses .vmdk files

[Libvir] Re: Next features and target for development

2007-07-11 Thread Anthony Liguori
Dan Smith wrote: DL> This question comes up in other contexts than migration, too, for DL> example, when you want to start an image you just downloaded. I DL> think it would make sense if there was a common baseline in DL> libvirt that could tell you if a VM has any chance of running at DL> all -

[Libvir] Re: Next features and target for development

2007-07-11 Thread Anthony Liguori
Dan Smith wrote: RJ> Some issues around migration which are up for discussion: Something else to consider is whether or not we "undefine" hosts leaving one machine during a migration. Last time I checked, Xen left a domain in "powered-off" state on the source. It seems to make more sense to me

[Libvir] Re: Next features and target for development

2007-07-11 Thread Anthony Liguori
Dan Smith wrote: AL> Processor revision is an artificial restriction. Just because AL> you're going from an AMD rev F to a rev 10 doesn't mean that your AL> application will stop working. In this particular case, it's AL> actually pretty unlikely that it would stop working. What I really meant

[Libvir] Re: Next features and target for development

2007-07-10 Thread Dan Smith
AL> Okay, flags is a subset of the common cpuid features. This is not by AL> any means exhaustive of the features supported by a particular CPU but AL> it is a reasonable starting point. Right, ok. AL> No, it may be safe. Consider the case where you're migrating from a AL> core duo to a core so

[Libvir] Re: Next features and target for development

2007-07-10 Thread Dan Smith
AL> For KVM, the guest isn't destroyed explicitly after a migration is AL> successful. Instead, the source guest is left in a paused state. AL> The main reason for not destroying the guest was so that a AL> management tool could still interact with the guest's monitor to AL> obtain statistics on t

[Libvir] Re: Next features and target for development

2007-07-10 Thread Dan Smith
AL> Processor revision is an artificial restriction. Just because AL> you're going from an AMD rev F to a rev 10 doesn't mean that your AL> application will stop working. In this particular case, it's AL> actually pretty unlikely that it would stop working. What I really meant was something alon