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

Re: [Xen-devel] Re: [PATCH][HVM] fix VNIF restore failure on HVMguestwith heavy workload




Just FYI - this is something I tested successfully last week. Not sure
if anything has been changed in recent changesets but worth checking
up - can you post the output from /var/log/xen/xend.log ?

Secondly: there is a known issue with save/restore of ballooned domains
(HVM or PV) where the balloning is done from within the guest (e.g.
by echoing to /proc/xen/balloon). Since this doesn't update the memory
target within xenstore, you'll end up 'reverting' the guest memory size to
that last set via xm mem-set. The 'fix' is not to do that, i.e. only use the
xm or XenAPI to request ballooning.


cheers,

S.




----- Original Message ----- From: "Zhao, Fan" <fan.zhao@xxxxxxxxx>
To: "Keir Fraser" <keir@xxxxxxxxxxxxx>; "Zhai, Edwin" <edwin.zhai@xxxxxxxxx>
Cc: "Tim Deegan" <Tim.Deegan@xxxxxxxxxxxxx>; "Ian Pratt" <Ian.Pratt@xxxxxxxxxxxx>; <xen-devel@xxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, April 11, 2007 5:24 PM
Subject: RE: [Xen-devel] Re: [PATCH][HVM] fix VNIF restore failure on HVMguestwith heavy workload


Hi Keir,
I noticed that with cset 14773, if I use xm mem-set to adjust the memory of hvm guest with balloon driver by xm mem-set, and then save the guest, the xm save will fail, so does xm migrate. A white window will pop up, and the guest still exists through xm li. So will your great fixes also include the fixing for this issue? Thanks!

Best regards,
Fan

-----Original Message-----
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Keir Fraser
Sent: 2007Äê4ÔÂ11ÈÕ 16:57
To: Zhai, Edwin
Cc: Tim Deegan; Ian Pratt; xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] Re: [PATCH][HVM] fix VNIF restore failure on HVMguest with heavy workload


FYI, the next changeset worth testing or fixing is r14795:6e7ef794cdbc. I've
made a *lot* of changes in the last 24 hours. I've tried a few save/restores
under block and net load with no observed problems.

-- Keir

On 11/4/07 08:20, "Zhai, Edwin" <edwin.zhai@xxxxxxxxx> wrote:

On Tue, Apr 10, 2007 at 08:16:04PM +0100, Keir Fraser wrote:
On 10/4/07 17:47, "Zhai, Edwin" <edwin.zhai@xxxxxxxxx> wrote:

[PATCH][HVM] fix VNIF restore failure on HVM guest with heavy workload

Signed-off-by: Zhai Edwin <edwin.zhai@xxxxxxxxx>

VNIF has many intrs when save/restore with net workload, so need keep
handler
from intrs

What happens if an interrupt is being processed during save/restore? It
would be nice to know what the underlying bug is!

If an pseudo PCI intr occurred after xen_suspend on cpu0, there is definitely
a
crash. I copy this code from original PV driver code.


That said, it may well make sense to somehow disable interrupt handling
across save/restore. Unfortunately your patch is insufficient since we could
handle event-channel interrupts on any VCPU (the irq's affinity can be
changed outside our control if it is routed through the virtual IOAPIC, and
if e.g. the userspace irqbalance daemon is running).

I wanted to use stop_machine_run() but unfortunately it isn't exported to
modules. :-( irq_disable() may do the right thing for us though.

SMP is a headache for PV drv save/restore on HVM. Even we disable intr on all
cpus, PV driver on other cpu may still access low level service after
xen_suspend on cpu0.

smp_suspend is used for PV drv on PV domain, which is not suitable for HVM as
we
need the transparency to guest.

Do we need lightweight stop_machine_run in this case, i.e. make other cpu
sleep?



 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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