[libvirt] Safe? /etc/libvirt/qemu on shared storage?
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
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
On Fri, Oct 2, 2009 at 11:22 AM, Chris Lalancette <clalance@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.
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.
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
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 :|
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
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
participants (5)
-
Chris Lalancette -
Daniel P. Berrange -
James Brackinshaw -
Maximilian Wilhelm -
Paolo Bonzini