[libvirt] virsh migrate
Hi, I would like to use this command to backup my virtual machine on my secondary server virsh migrate --live --suspend --copy-storage-inc virtual_machine qemu+ssh://root@secondary_server/system But we don't have option to disable shut off the virtual machine on the source server. Would you add an option to offer this functionality ? Best regards Nicolas Chateigner http://www.inserm.fr -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] virsh migrate: sometimes command line cannot exit until manually press ENTER key
On 8/8/2014 at 12:18 AM, in message
CAAfHSJvP1P20kBFD9ZgYy=0JVvG5oiS0eVCfGZc+k39=eha...@mail.gmail.com,
Shivaprasad bhat shivaprasadb...@gmail.com wrote:
On Thu, Aug 7, 2014 at 11:02 AM, Chun Yan Liu cy...@suse.com wrote:
Hi, List,
Do you meet the same problem? Host is kvm, doing: (e.g.)
#virsh migrate sles11 qemu+ssh://147.2.207.55/system --live --unsafe
password:
Sometimes, VM is already running on the target host and disappears
from source host, but the command line still hangs there, if pressing
ENTER, it will exit.
I debugged the code, but found the result is weird. The code hangs at
tools/virsh-domain.c - cmdMigrate -vshWatchJob-poll():
poll() is trying to select pipe_fd, which is used to receive message from
doMigrate thread. In debugging, found that doMigrate finishes and at
the end it does call safewrite() to write the retval ('0' or '1') to
pipe_fd,
and the write is completed. But cmdMigrate poll() cannot get the event.
Then after pressing ENTER key, poll() can get the event and select
pipe_fd, then command line can exit.
Any ideas about the possible reason?
It is because, the authentication thread is independently waiting for the
password on virsh. I see that the virWatchJob interferes with authentication
thread and the password is never taken successfully. The virWatchJob
probably needs to wait till the authentication thread completes taking the
password after which it should start watching the job.
Agree. Although in my testing password can be taken successfully, and I
don't know how to explain why pressing ENTER then poll() can get
the pipe_fd event, I do think both authentication thread and main process
uses stdin might have some bad affect.
I'd like to adjust the code a little to move the authentication before poll().
Thanks!
Moreover, I see
that --p2p
migration doesnt work at all when auto login is not configured.
Thanks,
Chunyan
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Thanks,
Shiva
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] virsh migrate: sometimes command line cannot exit until manually press ENTER key
On Thu, Aug 7, 2014 at 11:02 AM, Chun Yan Liu cy...@suse.com wrote:
Hi, List,
Do you meet the same problem? Host is kvm, doing: (e.g.)
#virsh migrate sles11 qemu+ssh://147.2.207.55/system --live --unsafe
password:
Sometimes, VM is already running on the target host and disappears
from source host, but the command line still hangs there, if pressing
ENTER, it will exit.
I debugged the code, but found the result is weird. The code hangs at
tools/virsh-domain.c - cmdMigrate -vshWatchJob-poll():
poll() is trying to select pipe_fd, which is used to receive message from
doMigrate thread. In debugging, found that doMigrate finishes and at
the end it does call safewrite() to write the retval ('0' or '1') to pipe_fd,
and the write is completed. But cmdMigrate poll() cannot get the event.
Then after pressing ENTER key, poll() can get the event and select
pipe_fd, then command line can exit.
Any ideas about the possible reason?
It is because, the authentication thread is independently waiting for the
password on virsh. I see that the virWatchJob interferes with authentication
thread and the password is never taken successfully. The virWatchJob
probably needs to wait till the authentication thread completes taking the
password after which it should start watching the job. Moreover, I see
that --p2p
migration doesnt work at all when auto login is not configured.
Thanks,
Chunyan
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Thanks,
Shiva
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] virsh migrate: sometimes command line cannot exit until manually press ENTER key
Hi, List,
Do you meet the same problem? Host is kvm, doing: (e.g.)
#virsh migrate sles11 qemu+ssh://147.2.207.55/system --live --unsafe
password:
Sometimes, VM is already running on the target host and disappears
from source host, but the command line still hangs there, if pressing
ENTER, it will exit.
I debugged the code, but found the result is weird. The code hangs at
tools/virsh-domain.c - cmdMigrate -vshWatchJob-poll():
poll() is trying to select pipe_fd, which is used to receive message from
doMigrate thread. In debugging, found that doMigrate finishes and at
the end it does call safewrite() to write the retval ('0' or '1') to pipe_fd,
and the write is completed. But cmdMigrate poll() cannot get the event.
Then after pressing ENTER key, poll() can get the event and select
pipe_fd, then command line can exit.
Any ideas about the possible reason?
Thanks,
Chunyan
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Virsh migrate --live fails
Subba Rao, Sandeep M (STSD) wrote: Hi, I'm trying to live move a domU using virsh migrate command: [r...@rhel53xen1 ~]# xm list Name ID Mem(MiB) VCPUs State Time(s) Copy_RHELVM3 1 511 1 -b898.3 Domain-0 0 1507 4 r- 133702.5 [r...@rhel53xen1 ~]# virsh migrate --live Copy_RHELVM3 xen+ssh://15.154.102.20 error: server closed connection Often this is because libvirtd crashed. After this command, check that libvirtd is still running, and if not, you might want to collect the core dump from it and get the output of thread apply all bt. [r...@rhel53xen1 ~]# However the same works using xm migrate --live. The source and the destination are RHEL 5.3 Xen hosts. Libvirt: [r...@rhel53xen1 ~]# rpm -qa | grep libvirt libvirt-0.3.3-14.el5 libvirt-devel-0.3.3-14.el5 libvirt-cim-0.5.1-4.el5 libvirt-python-0.3.3-14.el5 At this point, though, this is an ancient libvirt. I would suggest at least upgrading to the RHEL-5.4 version of libvirt, and see if you can reproduce the issue. If you can, then I would try again with the recently released 0.7.1, and if you are still having problems, then collect the information like I mentioned above. -- Chris Lalancette -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] virsh migrate with libvirt-0.6.2: failed to start listening VM
David Wilcox wrote: On the other machine, the log file that gets created under /var/log/libvirt/qemo/windowsxp.log LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin /usr/bin/qemu-kvm -S -M pc -m 512 -smp 1 -name windowsxp -uuid 24d2fd62-ed4f-a321-e264-200b347cfa6c -monitor pty -pidfile /var/run/libvirt/qemu//windowsxp.pid -localtime -no-acpi -boot c -drive file=/var/lib/libvirt/images/windowsxp.img,if=ide,index=0,boot=on -drive file=/aml/iso/windows_xp_sp3.iso,if=ide,media=cdrom,index=2 -net nic,macaddr=54:52:00:01:f1:06,vlan=0 -net tap,fd=19,vlan=0 -serial pty -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:0 http://127.0.0.1:0 -soundhw es1370 -incoming tcp:0.0.0.0:49159 http://0.0.0.0:49159 qemu: could not open disk image /var/lib/libvirt/images/windowsxp.img I would think that the virtual machine should copy from the one machine to the other. Isn't libvirt supposed to copy the image file? No. The underlying storage needs to be shared at exactly the same location. That is, if on the source machine your file is located at /var/lib/libvirt/images/windowsxp.img, then you need to nfs share /var/lib/libvirt/images, and mount it on the destination machine as /var/lib/libvirt/images. Then the file windowsxp.img will be available on both sides, and the migration should work. What's even stranger, I've been trying this for awhile. It's failed every time, except once when it succeded. I don't know what made it succeed in that case and fail in all the other cases. That makes no sense, unless you have been moving the location of your NFS mount around. It can't work without the storage being in the same place on the source and the destination. Note that patches have been recently posted to qemu upstream that *does* do a copy of the entire storage along with the memory. If and when those are applied to qemu, it's something we could think about enabling in libvirt. Note, however, that this will quite a long time to migrate, since you have to copy the entire disk image as well as all of the memory. -- Chris Lalancette -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] virsh migrate with libvirt-0.5.1: failed to start listening VM
Hello, I was trying to migrate a KVM/QEMU VM running on a Fedora 10 host to another F10 host. Both machines have identical architectures (x86_64) and are running identical versions of libvirt and KVM (libvirt-0.5.1-2.fc10.x86_64, kvm-74-10.fc10.x86_64). However, the migration fails: # virsh migrate jhrozek-f11-minimal qemu+ssh://someothersystem.example.com/system libvir: QEMU error : operation failed: failed to start listening VM On the target host, the logfile /var/log/libvirt/qemu/jhrozek-f11-minimal.log says: qemu: could not open disk image /var/lib/libvirt/images/jhrozek-f11-minimal.img Which seems rather odd, isn't libvirt supposed to copy the image file? Is this supposed to work? Is there any way to debug the problem? I skimmed through RH Bugzilla and googled a bit but haven't found much clue. Help is appreciated, Jakub -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] virsh migrate with libvirt-0.5.1: failed to start listening VM
On 07/14/2009 10:11 AM, Jakub Hrozek wrote: Hello, I was trying to migrate a KVM/QEMU VM running on a Fedora 10 host to another F10 host. Both machines have identical architectures (x86_64) and are running identical versions of libvirt and KVM (libvirt-0.5.1-2.fc10.x86_64, kvm-74-10.fc10.x86_64). However, the migration fails: # virsh migrate jhrozek-f11-minimal qemu+ssh://someothersystem.example.com/system libvir: QEMU error : operation failed: failed to start listening VM On the target host, the logfile /var/log/libvirt/qemu/jhrozek-f11-minimal.log says: qemu: could not open disk image /var/lib/libvirt/images/jhrozek-f11-minimal.img Which seems rather odd, isn't libvirt supposed to copy the image file? Is this supposed to work? Is there any way to debug the problem? I skimmed through RH Bugzilla and googled a bit but haven't found much clue. You're supposed to have /var/lib/libvirt/images mounted via shared storage (nfs/cifs/etc) on both machines. -- Scott Baker - Canby Telcom System Administrator - RHCE - 503.266.8253 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] virsh migrate with libvirt-0.5.1: failed to start listening VM
Scott Baker wrote: You're supposed to have /var/lib/libvirt/images mounted via shared storage (nfs/cifs/etc) on both machines. I've heard of folks having trouble doing live migration over NFS -- something with stronger concurrency guarantees (GFS, a shared iSCSI or FC mount [possibly with cLVM to partition it up], etc) is likely to be a safer bet. (Indeed, looking at the documented preferred environment for VMware's VMotion is probably a good guideline for anything that's going to be trusted with real production usage -- a separate bonded pair of NICs on each host, connected to a dedicated network for communication with the SAN hosting the backing store). -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] virsh migrate with libvirt-0.5.1: failed to start listening VM
On Tue, Jul 14, 2009 at 01:13:03PM -0500, Charles Duffy wrote: Scott Baker wrote: You're supposed to have /var/lib/libvirt/images mounted via shared storage (nfs/cifs/etc) on both machines. I've heard of folks having trouble doing live migration over NFS -- something with stronger concurrency guarantees (GFS, a shared iSCSI or FC mount [possibly with cLVM to partition it up], etc) is likely to be a safer bet. (Indeed, looking at the documented preferred environment for VMware's VMotion is probably a good guideline for anything that's going to be trusted with real production usage -- a separate bonded pair of NICs on each host, connected to a dedicated network for communication with the SAN hosting the backing store). A method I'm going to be trying out very shortly is using DRBD in dual-primary mode. DRBD will keep LVM volumes (block devices) for each VM in sync between two nodes. Upon migration, writes will cease on node A and when ready, begin on node B. You won't have concurrent writes, so it will be safe to use DRBD directly without a clustering FS on top (GFS, OCFS2, etc...). DRBD has scripts for Xen that take care of the details for you. Haven't seen the same for KVM/QEMU yet, but I imagine it would be pretty similar. -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
