[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Question on QEMU restore process





On Tue, May 26, 2015 at 5:49 PM, Ian Campbell <ian.campbell@xxxxxxxxxx> wrote:
On Tue, 2015-05-26 at 17:38 +0200, Lengyel, Tamas wrote:
> Hi all,
>
> I'm wondering if someone can point me in the right direction. I'm
> trying to understand the process around domain save/restore using XL.
> I can see the xl save format and how its appended with the QEMU state
> aquired via the xen-save-devices-state qmp command (this is for
> upstream QEMU).
>
> However, I have a hard time locating the exact point where that save
> state is being loaded into the new QEMU process. I see in libxc that
> it should be dumped into "/var/lib/xen/qemu-resume" appended by the
> domain id of the newly created domain. It seems this was passed to
> QEMU via the -loadvm flag at one point, but on Xen 4.4 I don't see
> that flag on my QEMU processes when I restore a domain.

libxl__build_device_model_args_new appears to pass it as "-incoming
fd:N" where N is an open file descriptor which qemu will inherit from
its parent (libxl).

Ian.

Hi Ian,
thanks for the info. What I'm trying to do is full HVM cloning of domains where I would also load up the correct QEMU save state for a clone domain. For this I was thinking of simply creating a clone domain paused (xl create -p -e <clone config>), copy over hvm+vcpu context of the origin domain and dedup memory using memsharing. Afterwards, I would kill the QEMU instance for the clone that was automatically created by xl, and replace it with a qemu instance that loads the state using -loadvm.

Now, this loading of the QEMU instance via -loadvm doesn't seem to work. I tried restoring a saved domain (xl restore -p -e <savefile>), dumped its QEMU state via QMP, killed the QEMU process and restarted it exactly as it was running before, except with -loadvm <qemu-save> instead of the -incoming fd option. I get the following error:

/usr/local/lib/xen/bin/qemu-system-i386 -xen-domid 8 -chardev socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-8,server,nowait -no-shutdown -mon chardev=libxl-cmd,mode=control -chardev socket,id=libxenstat-cmd,path=/var/run/xen/qmp-libxenstat-8,server,nowait -mon chardev=libxenstat-cmd,mode=control -nodefaults -name windows7-sp1-x86 -vnc 0.0.0.0:0,to=99 -display none -device cirrus-vga,vgamem_mb=8 -boot order=cd -usb -usbdevice tablet -device e1000,id=nic0,netdev=net0,mac=00:06:5b:ba:7c:02 -netdev type=tap,id=net0,ifname=vif8.0-emu,script=no,downscript=no -loadvm ./qemu-save -machine xenfv -m 1016 -drive file=/dev/l1vg/windows7-sp1-x86,if=ide,index=0,media=disk,format=raw,cache=writeback -daemonize
xen be: vkbd-0: initial backend state is wrong (InitWait)
qemu: hardware error: xen: failed to populate ram at 3f800000
CPU #0:
EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000663
ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 00000000 0000ffff 00009300
CS =f000 ffff0000 0000ffff 00009b00
SS =0000 00000000 0000ffff 00009300
DS =0000 00000000 0000ffff 00009300
FS =0000 00000000 0000ffff 00009300
GS =0000 00000000 0000ffff 00009300
LDT=0000 00000000 0000ffff 00008200
TR =0000 00000000 0000ffff 00008b00
GDT=ÂÂÂÂ 00000000 0000ffff
IDT=ÂÂÂÂ 00000000 0000ffff
CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
DR6=ffff0ff0 DR7=00000400
EFER=0000000000000000
FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000

What step am I missing in here for the (re)creation of the QEMU process?

--

www.novetta.com

Tamas K Lengyel

Senior Security Researcher


7921 Jones Branch Drive

McLean VA 22102

Email Âtlengyel@novetta.com

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.