3:11 a.m.
Hi,
is there any best-practice how to keep VM definitions in sync across a couple
of hosts? Is it reasonable to put /etc/libvirt/qemu/ on a NFS share? Or are
there better ways? How does oVirt solve that?
I'm asking because I'm currently setting up a four node "cluster" with
KVM and
libvirt. Previously, with Xen, I used libvirt only for changing currently
running VMs (setmem, migrate etc.), but with KVM, I'd like to use libvirt the
way it is intented to ;-)
So I assume that VM definitions are required to be available and in sync among
all nodes for doing live migration. I don't want to rsync them or wrap the
virsh URI edit inside a for-loop, as I assume there are better ways? I'd like
to do virsh URI edit once and have the changes propagated automagically.
kr,tom
11:07 a.m.
2009/11/14 Thomas Treutner <thomas(a)scripty.at>:
Hi,
is there any best-practice how to keep VM definitions in sync across a couple
of hosts? Is it reasonable to put /etc/libvirt/qemu/ on a NFS share? Or are
there better ways? How does oVirt solve that?
There was a similar question some weeks ago. The short answer is: No,
it's not safe to share /etc/libvirt/qemu/.
https://www.redhat.com/archives/libvir-list/2009-October/msg00031.html
I'm asking because I'm currently setting up a four node
"cluster" with KVM and
libvirt. Previously, with Xen, I used libvirt only for changing currently
running VMs (setmem, migrate etc.), but with KVM, I'd like to use libvirt the
way it is intented to ;-)
So I assume that VM definitions are required to be available and in sync among
all nodes for doing live migration. I don't want to rsync them or wrap the
virsh URI edit inside a for-loop, as I assume there are better ways? I'd like
to do virsh URI edit once and have the changes propagated automagically.
Why do you think the domain configs have to be available to all nodes?
The default migration semantic of libvirt is to "blame" here. A
migrated domain stays defined on the source node and is transient on
the destination node. A transient domain has no persistent config on
its node and is lost when destroyed.
Chris Lalancette committed a patch a month ago that adds two new
migration flags. This commit was applied after the release of 0.7.2,
it will be part of release 0.7.3.
https://www.redhat.com/archives/libvir-list/2009-October/msg00318.html
VIR_MIGRATE_PERSIST_DEST makes a domain persistent on the destination
node, libvirt writes a config to disk.
VIR_MIGRATE_UNDEFINE_SOURCE removes the domain config on the source node.
If you migrate a domain using this two flags then the domain takes its
config with it. So there is no need to have the domain configs
available on all nodes.
Matthias
1:19 p.m.
On Saturday 14 November 2009 18:07:48 Matthias Bolte wrote:
2009/11/14 Thomas Treutner <thomas(a)scripty.at>:
> Hi,
>
> is there any best-practice how to keep VM definitions in sync across a
> couple of hosts? Is it reasonable to put /etc/libvirt/qemu/ on a NFS
> share? Or are there better ways? How does oVirt solve that?
There was a similar question some weeks ago. The short answer is: No,
it's not safe to share /etc/libvirt/qemu/.
https://www.redhat.com/archives/libvir-list/2009-October/msg00031.html
Ah, thx for the pointer!
Why do you think the domain configs have to be available to all
nodes?
Because I'm coming from Xen and now finally had time to switch to KVM and
there's no regretting anything, but some rethinking neccessary :)
When using Xen, it's AFAIK necessary to have the domain configs available at
all nodes which one wants to migrate a VM to.
The default migration semantic of libvirt is to "blame"
here. A
migrated domain stays defined on the source node and is transient on
the destination node. A transient domain has no persistent config on
its node and is lost when destroyed.
Thats very cool! Just to be on the secure side of life: I assume a transient
VM can be target of setmem, etc.pp., be migrated again (and of course will be
transient at the target again), ... , and the only "shortcome" is that its
config is lost when it is destroyed?
Chris Lalancette committed a patch a month ago that adds two new
migration flags. This commit was applied after the release of 0.7.2,
it will be part of release 0.7.3.
https://www.redhat.com/archives/libvir-list/2009-October/msg00318.html
VIR_MIGRATE_PERSIST_DEST makes a domain persistent on the destination
node, libvirt writes a config to disk.
VIR_MIGRATE_UNDEFINE_SOURCE removes the domain config on the source node.
If you migrate a domain using this two flags then the domain takes its
config with it. So there is no need to have the domain configs
available on all nodes.
Thanks again - very interesting. I'm really impressed by the features of
libvirt more and more.
I think the second reason (beneath live migration) for thinking about keeping
domain configs in sync was the necessity to be able to *start* VMs at an
arbitrary host (hardware failures, whatever), but for that, I can use svn
etc. and do a virsh define before starting.
kr,
tom
5522
days inactive
5523
days old
2 comments
2 participants
participants (2)
-
Matthias Bolte -
Thomas Treutner