On Sun, Aug 22, 2010 at 12:13:16PM -0400, Perry Myers wrote:
On 08/19/2010 01:23 PM, David Teigland wrote:
On Thu, Aug 19, 2010 at 11:12:25AM -0400, David Teigland wrote:
I'm only aware of one goal, and the current plan is to implement it
correctly and completely. That goal is to lock vm
On 08/19/2010 01:23 PM, David Teigland wrote:
On Thu, Aug 19, 2010 at 11:12:25AM -0400, David Teigland wrote:
I'm only aware of one goal, and the current plan is to implement it
correctly and completely. That goal is to lock vm images so if the vm
happens to run on two hosts, only one
- Perry Myers pmy...@redhat.com wrote:
From: Perry Myers pmy...@redhat.com
To: David Teigland teigl...@redhat.com
Cc: libvir-list@redhat.com
Sent: Sunday, August 22, 2010 12:13:16 PM GMT -05:00 US/Canada Eastern
Subject: Re: [libvirt] using sync_manager with libvirt
On 08/19
On Wed, Aug 18, 2010 at 07:44:18PM -0400, Perry Myers wrote:
On 08/11/2010 05:27 PM, Daniel P. Berrange wrote:
On Wed, Aug 11, 2010 at 03:37:12PM -0400, David Teigland wrote:
On Wed, Aug 11, 2010 at 05:59:55PM +0100, Daniel P. Berrange wrote:
On Tue, Aug 10, 2010 at 12:44:06PM -0400, David
On Thu, Aug 19, 2010 at 11:12:25AM -0400, David Teigland wrote:
I'm only aware of one goal, and the current plan is to implement it
correctly and completely. That goal is to lock vm images so if the vm
happens to run on two hosts, only one instance can access the image.
(That's slightly
On 08/11/2010 05:27 PM, Daniel P. Berrange wrote:
On Wed, Aug 11, 2010 at 03:37:12PM -0400, David Teigland wrote:
On Wed, Aug 11, 2010 at 05:59:55PM +0100, Daniel P. Berrange wrote:
On Tue, Aug 10, 2010 at 12:44:06PM -0400, David Teigland wrote:
...
There's two different, but related problems
From: libvir-list-boun...@redhat.com [mailto:libvir-list-
boun...@redhat.com] On Behalf Of Daniel P. Berrange
...
A command would be something like this:
sync_manager daemon -i host_id -n vm_id -l lease -c command
args
host_id is integer between 1 and 2000 that is statically
functional, and the next big step is using it through libvirt.
sync_manager wraps a process, i.e. acquires a lease, forksexecs a
process, renews the lease wile the process runs, and releases the lease
when the process exits. While the process runs, it has exclusive access
to whatever resource was named
multiple disks). The latter requires a lease per
VM and can ignore specifices of what disks are configured.
IIUC, sync-manager is aiming for the latter.
It's functional, and the next big step is using it through libvirt.
sync_manager wraps a process, i.e. acquires a lease, forksexecs
. sync_manager
itself aims to be agnostic about what it's managing.
It's functional, and the next big step is using it through libvirt.
sync_manager wraps a process, i.e. acquires a lease, forksexecs a
process, renews the lease wile the process runs, and releases the lease
when the process
On 08/11/2010 02:53 PM, Chris Lalancette wrote:
Unfortunately, this is not how migration works in qemu/kvm. Using your
nomenclature above, it's more like the following:
A guest is running on S. A migration is then initiated, at which point D
fires up a qemu process with a -incoming
On Wed, Aug 11, 2010 at 04:53:20PM -0400, Chris Lalancette wrote:
1. sm-S holds the lease, and is monitoring qemu
2. migration begins from S to D
3. libvirt-D runs sm-D: sync_manager -c qemu with the addition of a new
sync_manager option --receive-lease
4. sm-D writes its hostid D to
to pass more info to the SM callbacks
so it knows what disks QEMU has, instead of just its name
It's functional, and the next big step is using it through libvirt.
sync_manager wraps a process, i.e. acquires a lease, forksexecs a
process, renews the lease wile the process runs
On Wed, Aug 11, 2010 at 03:07:29PM -0600, Eric Blake wrote:
On 08/11/2010 02:53 PM, Chris Lalancette wrote:
Unfortunately, this is not how migration works in qemu/kvm. Using your
nomenclature above, it's more like the following:
A guest is running on S. A migration is then initiated,
On Wed, Aug 11, 2010 at 05:19:27PM -0400, David Teigland wrote:
On Wed, Aug 11, 2010 at 04:53:20PM -0400, Chris Lalancette wrote:
1. sm-S holds the lease, and is monitoring qemu
2. migration begins from S to D
3. libvirt-D runs sm-D: sync_manager -c qemu with the addition of a new
15 matches
Mail list logo
