[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] (v2) Design proposal for RMRR fix
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx] > Sent: Monday, January 12, 2015 5:33 PM > > >>> On 12.01.15 at 09:46, <kevin.tian@xxxxxxxxx> wrote: > >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx] > >> Sent: Friday, January 09, 2015 6:35 PM > >> >>> On 09.01.15 at 11:10, <kevin.tian@xxxxxxxxx> wrote: > >> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx] > >> >> The question isn't about migrating with devices assigned, but about > >> >> assigning devices after migration (consider a dual vif + SR-IOV NIC > >> >> guest setup where the SR-IOV NIC gets hot-removed before > >> >> migration and a new one hot-plugged afterwards). > >> >> > >> >> Furthermore any tying of the guest memory layout to the host's > >> >> where the guest first boots is awkward, as post-migration there's > >> >> not going to be any reliable correlation between the guest layout > >> >> and the new host's. > >> > > >> > how can you solve this? like above example, a NIC on node-A leaves > >> > a reserved region in guest e820. now it's hot-removed and then > >> > migrated to node-b. there's no way to update e820 again since it's > >> > only boot structure. then user will still see such awkward regions. > >> > since it's not avoidable, report-all in the summary mail looks not > >> > causing a new problem. > >> > >> The solution to this are reserved regions specified in the guest config, > >> independent of host characteristics. > > > > I don't think how reserved regions are specified matter here. My point > > is that when a region is reserved in e820 at boot time, there's no way > > to erase that knowledge in the guest even when devices causing that > > reservation are hot removed later. > > I don't think anyone ever indicated that such erasure would be > needed/wanted - I'm not sure how you ended up there. > I ended here to indicate that report-all which gives user more reserved regions than necessary is not a weird case since above scenario can also create such fact. User shouldn't set expectation about reserved region layout. and this argument is necessary to support our proposal of using report-all. :-) Thanks Kevin _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |