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
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
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
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
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
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
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
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
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
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
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
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
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
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 -
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
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
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
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
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
19 matches
Mail list logo
