Skip to contentSkip to conversation

qemu-kvm-0.10.5, kvm-kmod-2.6.30, libvirt-0.6.4 - save/restore still unreliable

libvirt Nikola Ciprich 3 participants 7 messages Jun 12, 2009 – Jun 16, 2009 1 message not in the archive KVM

lore
Share & tools
lore
#0 lore raw

Hi,
I'm very sorry for crossposting, but I'm not sure whether my problem
is related to libvirt or kvm itself.
I've spent some time testing save/restore and it seems it's still not really reliable. Starting guest, loading it with some applications
(ie kernel compilation) and saving/restoring it for few times usually leads to error:

[root@vbox4 hibernated]# virsh save vmroo55 /home/LVS/hibernated/vmroo55.vm Domain vmroo55 saved to /home/LVS/hibernated/vmroo55.vm

[root@vbox4 hibernated]# virsh restore /home/LVS/hibernated/vmroo55.vm Domain restored from /home/LVS/hibernated/vmroo55.vm

[root@vbox4 hibernated]# virsh save vmroo55 /home/LVS/hibernated/vmroo55.vm Domain vmroo55 saved to /home/LVS/hibernated/vmroo55.vm

[root@vbox4 hibernated]# virsh restore /home/LVS/hibernated/vmroo55.vm
error: Failed to restore domain from /home/LVS/hibernated/vmroo55.vm
error: internal error unable to start guest: char device redirected to /dev/pts/2

in /var/log/messages, i see:

Jun 12 15:18:30 vbox4 libvirtd: 15:18:30.793: error : qemudReadMonitorOutput:696 : internal error Timed out while reading monitor startup output
Jun 12 15:18:30 vbox4 libvirtd: 15:18:30.820: error : qemudWaitForMonitor:994 : internal error unable to start guest: char device redirected to /dev/pts/2

/var/log/libvirt/vmroo55.log:
LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin HOME=/ /usr/bin/qemu-kvm -S -M pc -m 768 -smp 2 -name vmroo55 -uuid 987e7a85-0e15-11de-a522-00304892f672 -monitor pty -boot c -kernel /home/LVS/boot/vmlinuz-2.6.29lb.00_01_PRE14-x86_64 -initrd /home/LVS/boot/kvm-initrd-2.6.29lb.00_01_PRE14-x86_64.cpio.gz -append root=/dev/sda ro vmhostname=vmroo55 -drive file=/dev/vgshared/vmroo55-1,if=ide,index=0,boot=on -drive file=/dev/vgshared/vmroo55-2,if=ide,index=1 -drive file=/dev/vgshared/vmroo55-3,if=virtio,index=0 -net nic,macaddr=00:16:3e:18:37:00,vlan=0,model=virtio -net tap,fd=15,vlan=0 -serial none -parallel none -usb -vnc 0.0.0.0:24155 -incoming exec:cat char device redirected to /dev/pts/2
qemu_popen: returning result of qemu_fopen_ops
qemu_popen: returning result of qemu_fopen_ops

I wanted to try it using just kvm, but for some reason, I can't figure the proper way to execute it, is the -incoming exec:cat somewhere properly documented? I tried doing cat .../img.vm | qemu-kvm ... -incoming exec:cat but this doesn't seem to be the proper way.

Could somebody give me a hint on how to debug this?

thanks a lot in advance!

nik

Signature · 13 lines
-------------------------------------
Nikola CIPRICH
LinuxBox.cz, s.r.o.
28. rijna 168, 709 01 Ostrava

tel.:   +420 596 603 142
fax:    +420 596 621 273
mobil:  +420 777 093 799
www.linuxbox.cz

mobil servis: +420 737 238 656
email servis: [email protected]
-------------------------------------
#1 lore raw
Quoted 3 lines · Nikola Ciprich

I wanted to try it using just kvm, but for some reason, I can't figure the proper way to execute it, is the -incoming exec:cat somewhere properly documented? I tried doing cat .../img.vm | qemu-kvm ... -incoming exec:cat but this doesn't seem to be the proper way.

That should work fine. Your "..." sets up the drives, memory amount, etc., right? Why do you say it "doesn't seem to be the proper way"? What fails?

BTW, you might also do this: -incoming 'exec:cat .../img.vm', avoiding the need to pipe through stdin.

#2 lore raw

Hello Charlie,
thanks for the reply

Quoted 3 lines

That should work fine. Your "..." sets up the drives, memory amount, etc., right? Why do you say it "doesn't seem to be the proper way"? What fails?

sure, I'm (hopefully) providing all the needed arguments.

Quoted 3 lines

BTW, you might also do this: -incoming 'exec:cat .../img.vm', avoiding the need to pipe through stdin.

yup, I tried that, but it allways ends with following:

cat /home/LVS/hibernated/vmroo55.vm | /usr/bin/qemu-kvm -M pc -m 768 -smp 2 -name vmroo55 -uuid 987e7a85-0e15-11de-a522-00304892f672 -monitor pty -boot c -kernel /home/LVS/boot/vmlinuz-2.6.29lb.00_01_PRE14-x86_64 -initrd /home/LVS/boot/kvm-initrd-2.6.29lb.00_01_PRE14-x86_64.cpio.gz -append "root=/dev/sda ro vmhostname=vmroo55" -drive file=/dev/vgshared/vmroo55-1,if=ide,index=0,boot=on -drive file=/dev/vgshared/vmroo55-2,if=ide,index=1 -drive file=/dev/vgshared/vmroo55-3,if=virtio,index=0 -net nic,macaddr=00:16:3e:18:37:00,vlan=0,model=virtio -net tap,script=/etc/qemu-ifup.sh,vlan=0 -serial none -parallel none -usb -vnc0.0.0.0:24155 -incoming exec:cat

Executing /etc/qemu-ifup
Bringing up tap0 for bridged mode... Adding tap0 to br0...
char device redirected to /dev/pts/7
qemu_popen: returning result of qemu_fopen_ops load of migration failed
cat: write error: Broken pipe /etc/qemu-ifdown: could not launch network script

using
... -incoming exec:cat /home/...image.vm
seems to start the machine, but it seems to be stuck, even though I removed -S parameter.

Quoted 6 lines

--
Libvir-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/libvir-list

Signature · 14 lines
-------------------------------------
Nikola CIPRICH
LinuxBox.cz, s.r.o.
28. rijna 168, 709 01 Ostrava

tel.:   +420 596 603 142
fax:    +420 596 621 273
mobil:  +420 777 093 799

www.linuxbox.cz

mobil servis: +420 737 238 656
email servis: [email protected]
-------------------------------------
#3 lore raw
Quoted 2 lines · Nikola Ciprich

using ... -incoming exec:cat /home/...image.vm
seems to start the machine, but it seems to be stuck, even though I removed -S parameter.

That may well be a guest issue rather than a qemu migration problem -- I've seen similar difficulties for guests being resumed via incoming migration when using guest kernels with TSC as their clocksource.

You might try interrogating the monitor to see your guest's state.

#4 lore raw

Hmm,
I just noticed that dump file saved using virsh contains some libvirt related headers, so I guess I can't just feed it directly to qemu-kvm. So I guess best way to test save/restore without libvirt is to save vm state using monitor and then restore it again.
But I can't find any clear documentation on how to do this. Could anyone give me a hint?
thanks a lot!
nik

Quoted 11 lines · Charles Duffy

That may well be a guest issue rather than a qemu migration problem -- I've seen similar difficulties for guests being resumed via incoming migration when using guest kernels with TSC as their clocksource.

You might try interrogating the monitor to see your guest's state.

--
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Signature · 14 lines
-------------------------------------
Nikola CIPRICH
LinuxBox.cz, s.r.o.
28. rijna 168, 709 01 Ostrava

tel.:   +420 596 603 142
fax:    +420 596 621 273
mobil:  +420 777 093 799

www.linuxbox.cz

mobil servis: +420 737 238 656
email servis: [email protected]
-------------------------------------
#5 lore raw
Quoted 7 lines · Nikola Ciprich

Hmm,
I just noticed that dump file saved using virsh contains some libvirt related headers, so I guess I can't just feed it directly to qemu-kvm. So I guess best way to test save/restore without libvirt is to save vm state using monitor and then restore it again. But I can't find any clear documentation on how to do this.
Could anyone give me a hint?
thanks a lot!

There's savevm and loadvm in the monitor.

Signature · 1 line
error compiling committee.c: too many arguments to function

A message that is not in the archive (sent off-list or not yet received): 9E5B4A2291F9AD418AB1A2E89090064785B7EE@ausx3mpc124.aus.amer.dell.com

#7 lore raw

Re: [libvirt] qemu-kvm-0.10.5, kvm-kmod-2.6.30, libvirt-0.6.4 -save/restore still unreliable

Hello Charles,

Quoted 1 line

Otherwise -- at the monitor, migrate "exec:cat >somefile.out"

I tried that, saving seems to work OK,

but if I restore the domain, kvm always seems to be stuck, I'm not able to swith to monitor to do anything. running strace on the kvm process show that following is repeating:

clock_gettime(CLOCK_MONOTONIC, {453254, 437209647}) = 0 clock_gettime(CLOCK_MONOTONIC, {453254, 437244463}) = 0 clock_gettime(CLOCK_MONOTONIC, {453254, 437295938}) = 0
select(20, [5 10 17 19], [], [], {1, 0}) = 1 (in [5], left {0, 999998})
read(5, "\0", 512) = 1
read(5, 0x7fff60506840, 512) = -1 EAGAIN (Resource temporarily unavailable)
clock_gettime(CLOCK_MONOTONIC, {453254, 437458602}) = 0 clock_gettime(CLOCK_MONOTONIC, {453254, 437492440}) = 0
timer_gettime(0, {it_interval={0, 0}, it_value={0, 0}}) = 0
timer_settime(0, 0, {it_interval={0, 0}, it_value={0, 30000000}}, NULL) = 0 clock_gettime(CLOCK_MONOTONIC, {453254, 437605596}) = 0 clock_gettime(CLOCK_MONOTONIC, {453254, 437639489}) = 0
select(20, [5 10 17 19], [], [], {1, 0}) = 1 (in [19], left {0, 970104})
read(19, "\16\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 128) = 128 rt_sigaction(SIGALRM, NULL, {0x4083b0, ~[KILL STOP RTMIN RT_1], SA_RESTORER, 0x7f25576e94c0}, 8) = 0
write(6, "\0", 1) = 1
read(19, 0x7fff605069c0, 128) = -1 EAGAIN (Resource temporarily unavailable)

I guess I maybe need to unfreeze the domain somehow after loading it?

Quoted 53 lines

Replace cat with gzip -c or other compression tool (and reverse on migrate in) for more efficient on-disk storage.

-----Original Message-----
From: Nikola Ciprich [mailto:[email protected]]
Sent: Saturday, June 13, 2009 1:32 AM
To: CHARLESDUFFY
Cc: [email protected]; [email protected]
Subject: Re: [libvirt] qemu-kvm-0.10.5, kvm-kmod-2.6.30, libvirt-0.6.4 -save/restore still unreliable

Hmm,
I just noticed that dump file saved using virsh contains some libvirt related headers, so I guess I can't just feed it directly to qemu-kvm. So I guess best way to test save/restore without libvirt is to save vm state using monitor and then restore it again.
But I can't find any clear documentation on how to do this. Could anyone give me a hint?
thanks a lot!
nik

Quoted 12 lines · Charles Duffy

That may well be a guest issue rather than a qemu migration problem --

I've seen similar difficulties for guests being resumed via incoming migration when using guest kernels with TSC as their clocksource.

You might try interrogating the monitor to see your guest's state.

--
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Signature · 14 lines
-------------------------------------
Nikola CIPRICH
LinuxBox.cz, s.r.o.
28. rijna 168, 709 01 Ostrava

tel.:   +420 596 603 142
fax:    +420 596 621 273
mobil:  +420 777 093 799

www.linuxbox.cz

mobil servis: +420 737 238 656
email servis: [email protected]
-------------------------------------
Signature · 14 lines
-------------------------------------
Nikola CIPRICH
LinuxBox.cz, s.r.o.
28. rijna 168, 709 01 Ostrava

tel.:   +420 596 603 142
fax:    +420 596 621 273
mobil:  +420 777 093 799

www.linuxbox.cz

mobil servis: +420 737 238 656
email servis: [email protected]
-------------------------------------