[libvirt] Migrate not running guests

Hi In an exercise to use more libvirt, I am trying to use libvirt with my normal use. First, I will explain how I normally run my guests. I install guests on a machine with virt-install <....> I store all my guests images in a shared directory that is mounted in all my hosts. Now, it is trivial for me to launch qemu-kvm <options> on any machine, it don't matters if I have to use a rhel5, rhel6, fedora13 host. Everything works as expected. Except for the little fact that I have to remember the whole command line when I go from one machine to other, to use ide/virtio/rtl8139/.... You get the idea. And thing got worse the more guests that I have. Now I can run virt-manager on my desktop (machine A). Connect to host B. And launch my guests VM1 (on host B). No problem so far. I can indeed migrate my guests to machine C. No problem so far. And now I can start my guest VM1 in both host B and host C. It is there on virt-manager, one click away of launching. The functionality that I would really like is a "way" to store my guest information on my desktop (machine A), and be able to launch the guest on any host. I.e. a menu option when I click on the guest, that let me launch it in a different host, not in the one that it is defined. If that is difficult to implement for now, a "migrate" for a shut off guest will do by now. It should be something like virsh dumpxml foo > foo.xml virsh define foo.xml (this is the way that I do it by hand now). Why do I need this? because I have hosts with RHEL5/RHEL6/F13/.... And just now, I have to reinstall, do the previous dumpxml/define each time that I have to reproduce one bug in one host or another. To make things worse, sometimes RHEL5.4 and RHEL6.0 xml's are not completely compatible and I have to fix it by hand. Any better ideas about how to do this? Notice that I think that RHEV-M does something like this, but debugging on a RHEV-M host is an exercise on pain (everything is read only, ...) Later, Juan.

On Mon, Jul 05, 2010 at 08:37:33PM +0200, Juan Quintela wrote:
Hi
In an exercise to use more libvirt, I am trying to use libvirt with my normal use. First, I will explain how I normally run my guests.
I install guests on a machine with virt-install <....> I store all my guests images in a shared directory that is mounted in all my hosts.
Now, it is trivial for me to launch qemu-kvm <options> on any machine, it don't matters if I have to use a rhel5, rhel6, fedora13 host. Everything works as expected.
Except for the little fact that I have to remember the whole command line when I go from one machine to other, to use ide/virtio/rtl8139/.... You get the idea. And thing got worse the more guests that I have.
Now I can run virt-manager on my desktop (machine A). Connect to host B. And launch my guests VM1 (on host B). No problem so far. I can indeed migrate my guests to machine C. No problem so far.
And now I can start my guest VM1 in both host B and host C. It is there on virt-manager, one click away of launching.
The functionality that I would really like is a "way" to store my guest information on my desktop (machine A), and be able to launch the guest on any host. I.e. a menu option when I click on the guest, that let me launch it in a different host, not in the one that it is defined.
If that is difficult to implement for now, a "migrate" for a shut off guest will do by now. It should be something like virsh dumpxml foo > foo.xml virsh define foo.xml
(this is the way that I do it by hand now).
Why do I need this? because I have hosts with RHEL5/RHEL6/F13/....
And just now, I have to reinstall, do the previous dumpxml/define each time that I have to reproduce one bug in one host or another. To make things worse, sometimes RHEL5.4 and RHEL6.0 xml's are not completely compatible and I have to fix it by hand.
Any better ideas about how to do this?
I think this is a great idea... we would simply need to give virt-manager the ability to start transient guests off a local libvirt XML definition. I don't even think this would require that much code, especially if we didn't get worked up about making it super-robust (i.e. if the nfs path in your guest definition is wrong for the host you've tried to run your guest on, tough luck). Cole? Dan? Take care, --Hugh
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
participants (2)
-
Hugh O. Brock
-
Juan Quintela