similar to: xen hotplug cpu/ram questions

My dom0 is uing Centos 5.2 x64. I have just upgraded Xen from 3.3.0 to 3.3.1. After upgraded, I find that I cannot hotplug additional vcpu anymore. I have a domU "linux1" which is a paravirtualized vm with centos 5.2. I try to "xm vcpu-set linux1 4", it does not have any error message, but those vcpu cannot be displayed. I also tried to add vcpu using "virsh setvcpus

Hello, I have installed rpm version of xen 3.4.3+ libvirt 0.7.0-6 on my server with Centos 5.4 (kernel 2.6.18-238.12.1.el5xen) When I run reboot a domU (para virtualized Linux) by command "virsh reboot [vm]", sometimes domU cannot be rebooted but sometimes can, pattern is random. Also sometimes when domU reboots by "virsh reboot [vm]" , my ssh connection to dom0

Jason Wang <jasowang at redhat.com> writes: > We're trying to re-configure the affinity unconditionally in cpu hotplug > callback. This may lead the issue during resuming from s3/s4 since > > - virt queues haven't been allocated at that time. > - it's unnecessary since thaw method will re-configure the affinity. > > Fix this issue by checking the

"Michael S. Tsirkin" <mst at redhat.com> writes: > On Thu, Oct 17, 2013 at 09:57:41AM +1030, Rusty Russell wrote: >> Jason Wang <jasowang at redhat.com> writes: >> > We're trying to re-configure the affinity unconditionally in cpu hotplug >> > callback. This may lead the issue during resuming from s3/s4 since >> > >> > - virt

Pull necessary Linux CPU hotplug logic into Xen. Due to distinct difference on basic hierarchy and features, this pull is done on function level. Signed-off-by Kevin Tian <kevin.tian@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Hello, Does KVM support hotadd memory and hot-plug cpu? I checked it using the virsh command but I can only increase the memory to the maximum memory that is initially set But setmaxmem command is failing. Which means this require a reboot of the guest # virsh setmaxmem 4 1048576 error: Unable to change MaxMemorySize error: Requested operation is not valid: cannot resize the maximum memory on

On Thu, Oct 17, 2013 at 09:57:41AM +1030, Rusty Russell wrote: > Jason Wang <jasowang at redhat.com> writes: > > We're trying to re-configure the affinity unconditionally in cpu hotplug > > callback. This may lead the issue during resuming from s3/s4 since > > > > - virt queues haven't been allocated at that time. > > - it's unnecessary since thaw

On Thu, Oct 17, 2013 at 09:57:41AM +1030, Rusty Russell wrote: > Jason Wang <jasowang at redhat.com> writes: > > We're trying to re-configure the affinity unconditionally in cpu hotplug > > callback. This may lead the issue during resuming from s3/s4 since > > > > - virt queues haven't been allocated at that time. > > - it's unnecessary since thaw

From: Rusty Russell <rusty at rustcorp.com.au> Date: Fri, 18 Oct 2013 11:30:15 +1030 > Asking people to express 'CC: stable' in words is error-prone; if Dave > wants to filter it, he's quite capable. Filtering it one time is one thing. Potentially acting on that filter 100 or so times a day... That's completely another.

David Miller <davem at davemloft.net> writes: > From: Rusty Russell <rusty at rustcorp.com.au> > Date: Fri, 18 Oct 2013 11:30:15 +1030 > >> Asking people to express 'CC: stable' in words is error-prone; if Dave >> wants to filter it, he's quite capable. > > Filtering it one time is one thing. > > Potentially acting on that filter 100 or so

From: Rusty Russell <rusty at rustcorp.com.au> Date: Fri, 18 Oct 2013 11:30:15 +1030 > Asking people to express 'CC: stable' in words is error-prone; if Dave > wants to filter it, he's quite capable. Filtering it one time is one thing. Potentially acting on that filter 100 or so times a day... That's completely another.

I am wondering  what would happen when attempt to create Debian PV DomU at Xen 3.3.1  Suse 11.1 Dom0 via debootstrap , the native way of install  Debian (Ubuntu)  PV Guests  for Xen Systems. I beleve deboostrap RPM for Suse should be on the Net Boris. --- On Sat, 7/11/09, cmasmas cmasmas <cmasmas10@gmail.com> wrote: From: cmasmas cmasmas <cmasmas10@gmail.com> Subject: Re:

# HG changeset patch # User Ian Campbell <ian.campbell at citrix.com> # Date 1341941699 -3600 # Node ID efb7fee3573b68e895de0341dd67df83cb68acc6 # Parent ca5c306052791edf6d96da3f80aecd750b86a5e4 hotplug: vif: fail if a duplicate vifname is used. This is based on a patch from Hans van Kranenburg in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658305. Quoting that bug report: When

xen_play_dead calls cpu_bringup() which looks weird, because xen_play_dead() is invoked in the cpu down path, whereas cpu_bringup() (as the name suggests) is useful in the cpu bringup path. Getting rid of xen_play_dead()'s dependency on cpu_bringup() helps in hooking on to the generic SMP booting framework. Also remove the extra call to preempt_enable() added by commit 41bd956 (xen/smp: Fix

xen_play_dead calls cpu_bringup() which looks weird, because xen_play_dead() is invoked in the cpu down path, whereas cpu_bringup() (as the name suggests) is useful in the cpu bringup path. Getting rid of xen_play_dead()'s dependency on cpu_bringup() helps in hooking on to the generic SMP booting framework. Also remove the extra call to preempt_enable() added by commit 41bd956 (xen/smp: Fix

We're trying to re-configure the affinity unconditionally in cpu hotplug callback. This may lead the issue during resuming from s3/s4 since - virt queues haven't been allocated at that time. - it's unnecessary since thaw method will re-configure the affinity. Fix this issue by checking the config_enable and do nothing is we're not ready. The bug were introduced by commit

We're trying to re-configure the affinity unconditionally in cpu hotplug callback. This may lead the issue during resuming from s3/s4 since - virt queues haven't been allocated at that time. - it's unnecessary since thaw method will re-configure the affinity. Fix this issue by checking the config_enable and do nothing is we're not ready. The bug were introduced by commit

We're trying to re-configure the affinity unconditionally in cpu hotplug callback. This may lead the issue during resuming from s3/s4 since - virt queues haven't been allocated at that time. - it's unnecessary since thaw method will re-configure the affinity. Fix this issue by checking the config_enable and do nothing is we're not ready. The bug were introduced by commit

We're trying to re-configure the affinity unconditionally in cpu hotplug callback. This may lead the issue during resuming from s3/s4 since - virt queues haven't been allocated at that time. - it's unnecessary since thaw method will re-configure the affinity. Fix this issue by checking the config_enable and do nothing is we're not ready. The bug were introduced by commit

> -----Original Message----- > From: Ewan Mellor [mailto:ewan@xensource.com] > Sent: Tuesday, December 06, 2005 5:25 AM > To: Dave Thompson (davetho) > Cc: Xen Mailing List > Subject: Re: [Xen-devel] Hotplug scripts not working... > xen/ia64 domU stoppedworking > > On Mon, Dec 05, 2005 at 03:03:54PM -0500, Dave Thompson > (davetho) wrote: > > > >