3:15 a.m.
Hello,
I have a directory /mnt/shared-storage where the disk files for kvm
live. Live migration works well, but I have a problem: after a
migration I see two guests, one on the original host "shutoff" and one
on the new host "running".
I'd like to see the guest only on the host it is running on.
Would it be safe/recommended to put the /etc/libvirt/qemu directory on
shared storage? What would the best way of doing this be?
Is this lock safe?
Thanks
JB
4:22 a.m.
James Brackinshaw wrote:
Hello,
I have a directory /mnt/shared-storage where the disk files for kvm
live. Live migration works well, but I have a problem: after a
migration I see two guests, one on the original host "shutoff" and one
on the new host "running".
I'd like to see the guest only on the host it is running on.
Would it be safe/recommended to put the /etc/libvirt/qemu directory on
shared storage? What would the best way of doing this be?
Is this lock safe?
No, this is not safe, and won't do what you expect either. This will almost
certainly corrupt your guest config files.
Currently, the migration code assumes that you want to leave the migrated guest
defined but not running on the "source" of the migration, and that you want to
leave it running but not defined (transient) on the "destination" of the
migration.
I have some upcoming patches to the migration code that allow you to tweak the
behavior. That is, they allow you to undefine the guest on the source if you
wish, and/or permanently define the guest on the destination if you wish.
--
Chris Lalancette
4:36 a.m.
On Fri, Oct 2, 2009 at 11:22 AM, Chris Lalancette <clalance(a)redhat.com> wrote:
James Brackinshaw wrote:
> Hello,
>
> I have a directory /mnt/shared-storage where the disk files for kvm
> live. Live migration works well, but I have a problem: after a
> migration I see two guests, one on the original host "shutoff" and one
> on the new host "running".
>
> I'd like to see the guest only on the host it is running on.
>
> Would it be safe/recommended to put the /etc/libvirt/qemu directory on
> shared storage? What would the best way of doing this be?
> Is this lock safe?
No, this is not safe, and won't do what you expect either. This will almost
certainly corrupt your guest config files.
Currently, the migration code assumes that you want to leave the migrated guest
defined but not running on the "source" of the migration, and that you want to
leave it running but not defined (transient) on the "destination" of the
migration.
I have some upcoming patches to the migration code that allow you to tweak the
behavior. That is, they allow you to undefine the guest on the source if you
wish, and/or permanently define the guest on the destination if you wish.
This sounds excellent, just what I need. Looking forward to it.
12:39 p.m.
New subject: Migration procedure (was: Re: [libvirt] Safe? /etc/libvirt/qemu on shared storage?)
Anno domini 2009 Chris Lalancette scripsit:
Hi!
[...]
Currently, the migration code assumes that you want to leave the
migrated guest
defined but not running on the "source" of the migration, and that you want to
leave it running but not defined (transient) on the "destination" of the
migration.
I have some upcoming patches to the migration code that allow you to
tweak the
behavior. That is, they allow you to undefine the guest on the source if you
wish, and/or permanently define the guest on the destination if you wish.
I just today stumbled accross this in my cluster management library
and am highly interested in these features. (So I don't have to fiddle
around this by myself :))
What is your ETA for these patches?
If you need assistance in any kind - even testing - I would be glad to help!
Thanks!
Ciao
Max
--
If it doesn't work, force it.
If it breaks, it needed replacing anyway.
5:26 a.m.
New subject: [libvirt] Re: Migration procedure
Maximilian Wilhelm wrote:
Anno domini 2009 Chris Lalancette scripsit:
Hi!
[...]
> Currently, the migration code assumes that you want to leave the migrated guest
> defined but not running on the "source" of the migration, and that you want
to
> leave it running but not defined (transient) on the "destination" of the
migration.
> I have some upcoming patches to the migration code that allow you to tweak the
> behavior. That is, they allow you to undefine the guest on the source if you
> wish, and/or permanently define the guest on the destination if you wish.
I just today stumbled accross this in my cluster management library
and am highly interested in these features. (So I don't have to fiddle
around this by myself :))
What is your ETA for these patches?
If you need assistance in any kind - even testing - I would be glad to help!
There really isn't much to it; I just need to clean them up, test them again,
and post. I'll try to get to it this week to get it into the next release.
--
Chris Lalancette
4:47 a.m.
On Fri, Oct 02, 2009 at 10:15:09AM +0200, James Brackinshaw wrote:
Hello,
I have a directory /mnt/shared-storage where the disk files for kvm
live. Live migration works well, but I have a problem: after a
migration I see two guests, one on the original host "shutoff" and one
on the new host "running".
I'd like to see the guest only on the host it is running on.
Would it be safe/recommended to put the /etc/libvirt/qemu directory on
shared storage? What would the best way of doing this be?
Is this lock safe?
Absolutely NOT safe. It is only intended for single host use
If you're going to have a cluster of hosts between which you can move
guests, you should really aim to store all your master configs elsewhere
in shared storage, and either use transient guests (which have no
config in /etc/libvirt), or persistent guests and only have configs in
/etc/libvirt for the guests which happens to be running on that node
Using some kind of cluster management software is a good idea to safely
deal with this
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
5 a.m.
If you're going to have a cluster of hosts between which you can
move
guests, you should really aim to store all your master configs elsewhere
in shared storage, and either use transient guests (which have no
config in /etc/libvirt), or persistent guests and only have configs in
/etc/libvirt for the guests which happens to be running on that node
So transient doesn't store the configs in /etc/libvirt - where are
they stored? and what happens if the guest is shutdown?
If persistent guests only store the config on that node, what is the
normal mode called?
I can't find any documentation on this, can you point me somewhere on
how I can use this and read up on it?
Using some kind of cluster management software is a good idea to
safely
deal with this
Would you mind elaborating on this? What would the cluster management
software do here?
JB
5:14 a.m.
On 10/02/2009 12:00 PM, James Brackinshaw wrote:
> If you're going to have a cluster of hosts between which you
can move
> guests, you should really aim to store all your master configs elsewhere
> in shared storage, and either use transient guests (which have no
> config in /etc/libvirt), or persistent guests and only have configs in
> /etc/libvirt for the guests which happens to be running on that node
So transient doesn't store the configs in /etc/libvirt - where are
they stored?
In memory only.
and what happens if the guest is shutdown?
It just goes away. You can try using "virsh create" instead of "virsh
define" + "virsh start".
Paolo
5526
days inactive
5529
days old
7 comments
5 participants
participants (5)
-
Chris Lalancette -
Daniel P. Berrange -
James Brackinshaw -
Maximilian Wilhelm -
Paolo Bonzini