Re: [libvirt] [PATCHv4 0/3] Add support for file memorybacking
On 01/31/2017 10:40 AM, Safka, JaroslavX wrote: > > >> -Original Message- >> From: Pavel Hrdina [mailto:phrd...@redhat.com] >> Sent: Monday, January 30, 2017 1:50 PM >> To: Safka, JaroslavX <jaroslavx.sa...@intel.com> >> Cc: Daniel P. Berrange <berra...@redhat.com>; Michal Privoznik >> <mpriv...@redhat.com>; libvir-list@redhat.com; Mooney, Sean K >> <sean.k.moo...@intel.com>; Ptacek, MichalX <michalx.pta...@intel.com> >> Subject: Re: [libvirt] [PATCHv4 0/3] Add support for file memorybacking >> >> On Mon, Jan 30, 2017 at 12:16:38PM +, Safka, JaroslavX wrote: >>> >>> >>>> -Original Message- >>>> From: Pavel Hrdina [mailto:phrd...@redhat.com] >>>> Sent: Monday, January 30, 2017 1:13 PM >>>> To: Safka, JaroslavX <jaroslavx.sa...@intel.com> >>>> Cc: Daniel P. Berrange <berra...@redhat.com>; Michal Privoznik >>>> <mpriv...@redhat.com>; libvir-list@redhat.com; Mooney, Sean K >>>> <sean.k.moo...@intel.com>; Ptacek, MichalX >>>> <michalx.pta...@intel.com> >>>> Subject: Re: [libvirt] [PATCHv4 0/3] Add support for file >>>> memorybacking >>>> >>>> On Mon, Jan 30, 2017 at 12:06:19PM +, Safka, JaroslavX wrote: >>>>> >>>>> >>>>>> -Original Message- >>>>>> From: Daniel P. Berrange [mailto:berra...@redhat.com] >>>>>> Sent: Monday, January 30, 2017 12:35 PM >>>>>> To: Michal Privoznik <mpriv...@redhat.com> >>>>>> Cc: Safka, JaroslavX <jaroslavx.sa...@intel.com>; >>>>>> libvir-list@redhat.com; Mooney, Sean K >>>>>> <sean.k.moo...@intel.com>; Ptacek, MichalX >>>>>> <michalx.pta...@intel.com> >>>>>> Subject: Re: [libvirt] [PATCHv4 0/3] Add support for file >>>>>> memorybacking >>>>>> >>>>>> On Sat, Jan 28, 2017 at 03:03:02PM +0100, Michal Privoznik wrote: >>>>>>> On 13.12.2016 13:12, Jaroslav Safka wrote: >>>>>>>> Hi, >>>>>>>> we would like to introduce 3 new elements source,access and >>>>>>>> allocation in >>>>>> memoryBacking element. >>>>>>>> For now it was made for numa topology. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> If allocation is immediate then -mem-prealloc should be >>>>>>>> added to the qemu >>>>>> commanline. >>>>>>>> If source is file then >>>>>>>> -object memory-backend-file,id=mem,size=1024M,mem-path=*lib >>>>>>>> dir >>>>>>>> path* -numa node,memdev=mem Will be added to the qemu >>>>>>>> commandline >>>>>>>> >>>>>>>> If access is shared then the "share=on" parameter will be >>>>>>>> added to the >>>>>> memory-backend-file e.g. >>>>>>>> -object >>>>>>>> memory-backend-file,id=mem,size=1024M,mem- >>>>>> path=/var/lib/libvirt/qemu >>>>>>>> ,share=on >>>>>>>> >>>>>>>> The access mode can be overriden by specifying token >>>>>>>> memAccess in numa >>>>>> cell. >>>>>>>> >>>>>>>> The test cpu-numa-memshared was removed, because behaviour >>>>>>>> was changed and is not needed anymore >>>>>>> >>>>>>> I beg to disagree. What if you don't have any ? >>>>>>> >>>>>>> I like these patches, but I'm not certainly sure about: >>>>>>> a) domain XML (in the past we used to require an ACK on schema >>>>>>> change from one of the Dans) >>>>>> >>>>>> What are you unsure about ? This XML is what I suggested in >>>>>> previous rounds of discussion. >>>>>> >>>>>>> b) the location for qemu to create its mmaped files (patch 3/3). >>>>>>> cfg->libDir looks very suspicious. >>>>>> >>>>>> Well we've got two possibilities - source=anonymous, should be >>>>>> using /dev/shm, similar to how we do huge pages. For >>>>>> source=file, we need a real filesystem. Something under /var/lib/libvirt >> is reasonable. >>>>>> Perhaps a dedicated dir is needed ? eg /var/lib/libvirt/ram in >>>>>> order to provide a point where the admin can mount a >>>>>> sufficiently large filesystem ? Or make it configurable in >>>>>> /etc/libvirt/qemu.conf >>>>>> >>>>> >>>>> [Jarek] It will be ok when I do something like libDir + "/ram". Or >>>>> It should be >>>> configurable on compilation time? >>>> >>>> Oh, I see that Dan already suggested to make it configurable. I would say >> both. >>>> Make it configurable in qemu.conf and use /var/lib/libvirt/ram as a >>>> default path. >>>> >>> [Jarek] will be ok to make it configurable in another patch set? Or it >>> should be >> all in one patch set? >>> Because it will take me some time, when I find out how to add this parameter >> as configurable. >> >> It's not that hard :) for example this commit 661887f5582 can be used as an >> example how to add a new configurable option into qemu.conf. We have >> whole month before next release so it would be nice to have it as part of the >> same patch series. >> >> Pavel > > [Jarek] Also I'm not sure where the config parameter put. Probably in the > "process_entry" ? I'd go with memory_backing_path and create new memory_entry. Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv4 0/3] Add support for file memorybacking
On Tue, Jan 31, 2017 at 09:09:25AM +, Safka, JaroslavX wrote: > > > > -Original Message- > > From: Pavel Hrdina [mailto:phrd...@redhat.com] > > Sent: Monday, January 30, 2017 1:50 PM > > To: Safka, JaroslavX <jaroslavx.sa...@intel.com> > > Cc: Daniel P. Berrange <berra...@redhat.com>; Michal Privoznik > > <mpriv...@redhat.com>; libvir-list@redhat.com; Mooney, Sean K > > <sean.k.moo...@intel.com>; Ptacek, MichalX <michalx.pta...@intel.com> > > Subject: Re: [libvirt] [PATCHv4 0/3] Add support for file memorybacking > > > > On Mon, Jan 30, 2017 at 12:16:38PM +, Safka, JaroslavX wrote: > > > > > > > > > > -Original Message- > > > > From: Pavel Hrdina [mailto:phrd...@redhat.com] > > > > Sent: Monday, January 30, 2017 1:13 PM > > > > To: Safka, JaroslavX <jaroslavx.sa...@intel.com> > > > > Cc: Daniel P. Berrange <berra...@redhat.com>; Michal Privoznik > > > > <mpriv...@redhat.com>; libvir-list@redhat.com; Mooney, Sean K > > > > <sean.k.moo...@intel.com>; Ptacek, MichalX > > > > <michalx.pta...@intel.com> > > > > Subject: Re: [libvirt] [PATCHv4 0/3] Add support for file > > > > memorybacking > > > > > > > > On Mon, Jan 30, 2017 at 12:06:19PM +, Safka, JaroslavX wrote: > > > > > > > > > > > > > > > > -Original Message- > > > > > > From: Daniel P. Berrange [mailto:berra...@redhat.com] > > > > > > Sent: Monday, January 30, 2017 12:35 PM > > > > > > To: Michal Privoznik <mpriv...@redhat.com> > > > > > > Cc: Safka, JaroslavX <jaroslavx.sa...@intel.com>; > > > > > > libvir-list@redhat.com; Mooney, Sean K > > > > > > <sean.k.moo...@intel.com>; Ptacek, MichalX > > > > > > <michalx.pta...@intel.com> > > > > > > Subject: Re: [libvirt] [PATCHv4 0/3] Add support for file > > > > > > memorybacking > > > > > > > > > > > > On Sat, Jan 28, 2017 at 03:03:02PM +0100, Michal Privoznik wrote: > > > > > > > On 13.12.2016 13:12, Jaroslav Safka wrote: > > > > > > > > Hi, > > > > > > > > we would like to introduce 3 new elements source,access and > > > > > > > > allocation in > > > > > > memoryBacking element. > > > > > > > > For now it was made for numa topology. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If allocation is immediate then -mem-prealloc should be > > > > > > > > added to the qemu > > > > > > commanline. > > > > > > > > If source is file then > > > > > > > > -object memory-backend-file,id=mem,size=1024M,mem-path=*lib > > > > > > > > dir > > > > > > > > path* -numa node,memdev=mem Will be added to the qemu > > > > > > > > commandline > > > > > > > > > > > > > > > > If access is shared then the "share=on" parameter will be > > > > > > > > added to the > > > > > > memory-backend-file e.g. > > > > > > > > -object > > > > > > > > memory-backend-file,id=mem,size=1024M,mem- > > > > > > path=/var/lib/libvirt/qemu > > > > > > > > ,share=on > > > > > > > > > > > > > > > > The access mode can be overriden by specifying token > > > > > > > > memAccess in numa > > > > > > cell. > > > > > > > > > > > > > > > > The test cpu-numa-memshared was removed, because behaviour > > > > > > > > was changed and is not needed anymore > > > > > > > > > > > > > > I beg to disagree. What if you don't have any ? > > > > > > > > > > > > > > I like these patches, but I'm not certainly sure about: > > > > > > > a) domain XML (in the past we used to require an ACK on schema > > > > > > > change from one of the Dans) >
Re: [libvirt] [PATCHv4 0/3] Add support for file memorybacking
> -Original Message- > From: Pavel Hrdina [mailto:phrd...@redhat.com] > Sent: Monday, January 30, 2017 1:50 PM > To: Safka, JaroslavX <jaroslavx.sa...@intel.com> > Cc: Daniel P. Berrange <berra...@redhat.com>; Michal Privoznik > <mpriv...@redhat.com>; libvir-list@redhat.com; Mooney, Sean K > <sean.k.moo...@intel.com>; Ptacek, MichalX <michalx.pta...@intel.com> > Subject: Re: [libvirt] [PATCHv4 0/3] Add support for file memorybacking > > On Mon, Jan 30, 2017 at 12:16:38PM +, Safka, JaroslavX wrote: > > > > > > > -Original Message- > > > From: Pavel Hrdina [mailto:phrd...@redhat.com] > > > Sent: Monday, January 30, 2017 1:13 PM > > > To: Safka, JaroslavX <jaroslavx.sa...@intel.com> > > > Cc: Daniel P. Berrange <berra...@redhat.com>; Michal Privoznik > > > <mpriv...@redhat.com>; libvir-list@redhat.com; Mooney, Sean K > > > <sean.k.moo...@intel.com>; Ptacek, MichalX > > > <michalx.pta...@intel.com> > > > Subject: Re: [libvirt] [PATCHv4 0/3] Add support for file > > > memorybacking > > > > > > On Mon, Jan 30, 2017 at 12:06:19PM +, Safka, JaroslavX wrote: > > > > > > > > > > > > > -Original Message- > > > > > From: Daniel P. Berrange [mailto:berra...@redhat.com] > > > > > Sent: Monday, January 30, 2017 12:35 PM > > > > > To: Michal Privoznik <mpriv...@redhat.com> > > > > > Cc: Safka, JaroslavX <jaroslavx.sa...@intel.com>; > > > > > libvir-list@redhat.com; Mooney, Sean K > > > > > <sean.k.moo...@intel.com>; Ptacek, MichalX > > > > > <michalx.pta...@intel.com> > > > > > Subject: Re: [libvirt] [PATCHv4 0/3] Add support for file > > > > > memorybacking > > > > > > > > > > On Sat, Jan 28, 2017 at 03:03:02PM +0100, Michal Privoznik wrote: > > > > > > On 13.12.2016 13:12, Jaroslav Safka wrote: > > > > > > > Hi, > > > > > > > we would like to introduce 3 new elements source,access and > > > > > > > allocation in > > > > > memoryBacking element. > > > > > > > For now it was made for numa topology. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If allocation is immediate then -mem-prealloc should be > > > > > > > added to the qemu > > > > > commanline. > > > > > > > If source is file then > > > > > > > -object memory-backend-file,id=mem,size=1024M,mem-path=*lib > > > > > > > dir > > > > > > > path* -numa node,memdev=mem Will be added to the qemu > > > > > > > commandline > > > > > > > > > > > > > > If access is shared then the "share=on" parameter will be > > > > > > > added to the > > > > > memory-backend-file e.g. > > > > > > > -object > > > > > > > memory-backend-file,id=mem,size=1024M,mem- > > > > > path=/var/lib/libvirt/qemu > > > > > > > ,share=on > > > > > > > > > > > > > > The access mode can be overriden by specifying token > > > > > > > memAccess in numa > > > > > cell. > > > > > > > > > > > > > > The test cpu-numa-memshared was removed, because behaviour > > > > > > > was changed and is not needed anymore > > > > > > > > > > > > I beg to disagree. What if you don't have any ? > > > > > > > > > > > > I like these patches, but I'm not certainly sure about: > > > > > > a) domain XML (in the past we used to require an ACK on schema > > > > > > change from one of the Dans) > > > > > > > > > > What are you unsure about ? This XML is what I suggested in > > > > > previous rounds of discussion. > > > > > > > > > > > b) the location for qemu to create its mmaped files (patch 3/3). > > > > > > cfg->libDir looks very suspicious. > > > > > > > > > > Well we've got two possibilities - source=anonymous, should be >
Re: [libvirt] [PATCHv4 0/3] Add support for file memorybacking
> -Original Message- > From: Pavel Hrdina [mailto:phrd...@redhat.com] > Sent: Monday, January 30, 2017 1:50 PM > To: Safka, JaroslavX <jaroslavx.sa...@intel.com> > Cc: Daniel P. Berrange <berra...@redhat.com>; Michal Privoznik > <mpriv...@redhat.com>; libvir-list@redhat.com; Mooney, Sean K > <sean.k.moo...@intel.com>; Ptacek, MichalX <michalx.pta...@intel.com> > Subject: Re: [libvirt] [PATCHv4 0/3] Add support for file memorybacking > > On Mon, Jan 30, 2017 at 12:16:38PM +, Safka, JaroslavX wrote: > > > > > > > -Original Message- > > > From: Pavel Hrdina [mailto:phrd...@redhat.com] > > > Sent: Monday, January 30, 2017 1:13 PM > > > To: Safka, JaroslavX <jaroslavx.sa...@intel.com> > > > Cc: Daniel P. Berrange <berra...@redhat.com>; Michal Privoznik > > > <mpriv...@redhat.com>; libvir-list@redhat.com; Mooney, Sean K > > > <sean.k.moo...@intel.com>; Ptacek, MichalX > > > <michalx.pta...@intel.com> > > > Subject: Re: [libvirt] [PATCHv4 0/3] Add support for file > > > memorybacking > > > > > > On Mon, Jan 30, 2017 at 12:06:19PM +, Safka, JaroslavX wrote: > > > > > > > > > > > > > -Original Message- > > > > > From: Daniel P. Berrange [mailto:berra...@redhat.com] > > > > > Sent: Monday, January 30, 2017 12:35 PM > > > > > To: Michal Privoznik <mpriv...@redhat.com> > > > > > Cc: Safka, JaroslavX <jaroslavx.sa...@intel.com>; > > > > > libvir-list@redhat.com; Mooney, Sean K > > > > > <sean.k.moo...@intel.com>; Ptacek, MichalX > > > > > <michalx.pta...@intel.com> > > > > > Subject: Re: [libvirt] [PATCHv4 0/3] Add support for file > > > > > memorybacking > > > > > > > > > > On Sat, Jan 28, 2017 at 03:03:02PM +0100, Michal Privoznik wrote: > > > > > > On 13.12.2016 13:12, Jaroslav Safka wrote: > > > > > > > Hi, > > > > > > > we would like to introduce 3 new elements source,access and > > > > > > > allocation in > > > > > memoryBacking element. > > > > > > > For now it was made for numa topology. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If allocation is immediate then -mem-prealloc should be > > > > > > > added to the qemu > > > > > commanline. > > > > > > > If source is file then > > > > > > > -object memory-backend-file,id=mem,size=1024M,mem-path=*lib > > > > > > > dir > > > > > > > path* -numa node,memdev=mem Will be added to the qemu > > > > > > > commandline > > > > > > > > > > > > > > If access is shared then the "share=on" parameter will be > > > > > > > added to the > > > > > memory-backend-file e.g. > > > > > > > -object > > > > > > > memory-backend-file,id=mem,size=1024M,mem- > > > > > path=/var/lib/libvirt/qemu > > > > > > > ,share=on > > > > > > > > > > > > > > The access mode can be overriden by specifying token > > > > > > > memAccess in numa > > > > > cell. > > > > > > > > > > > > > > The test cpu-numa-memshared was removed, because behaviour > > > > > > > was changed and is not needed anymore > > > > > > > > > > > > I beg to disagree. What if you don't have any ? > > > > > > > > > > > > I like these patches, but I'm not certainly sure about: > > > > > > a) domain XML (in the past we used to require an ACK on schema > > > > > > change from one of the Dans) > > > > > > > > > > What are you unsure about ? This XML is what I suggested in > > > > > previous rounds of discussion. > > > > > > > > > > > b) the location for qemu to create its mmaped files (patch 3/3). > > > > > > cfg->libDir looks very suspicious. > > > > > > > > > > Well we've
Re: [libvirt] [PATCHv4 0/3] Add support for file memorybacking
On Mon, Jan 30, 2017 at 12:16:38PM +, Safka, JaroslavX wrote: > > > > -Original Message- > > From: Pavel Hrdina [mailto:phrd...@redhat.com] > > Sent: Monday, January 30, 2017 1:13 PM > > To: Safka, JaroslavX <jaroslavx.sa...@intel.com> > > Cc: Daniel P. Berrange <berra...@redhat.com>; Michal Privoznik > > <mpriv...@redhat.com>; libvir-list@redhat.com; Mooney, Sean K > > <sean.k.moo...@intel.com>; Ptacek, MichalX <michalx.pta...@intel.com> > > Subject: Re: [libvirt] [PATCHv4 0/3] Add support for file memorybacking > > > > On Mon, Jan 30, 2017 at 12:06:19PM +, Safka, JaroslavX wrote: > > > > > > > > > > -Original Message- > > > > From: Daniel P. Berrange [mailto:berra...@redhat.com] > > > > Sent: Monday, January 30, 2017 12:35 PM > > > > To: Michal Privoznik <mpriv...@redhat.com> > > > > Cc: Safka, JaroslavX <jaroslavx.sa...@intel.com>; > > > > libvir-list@redhat.com; Mooney, Sean K <sean.k.moo...@intel.com>; > > > > Ptacek, MichalX <michalx.pta...@intel.com> > > > > Subject: Re: [libvirt] [PATCHv4 0/3] Add support for file > > > > memorybacking > > > > > > > > On Sat, Jan 28, 2017 at 03:03:02PM +0100, Michal Privoznik wrote: > > > > > On 13.12.2016 13:12, Jaroslav Safka wrote: > > > > > > Hi, > > > > > > we would like to introduce 3 new elements source,access and > > > > > > allocation in > > > > memoryBacking element. > > > > > > For now it was made for numa topology. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If allocation is immediate then -mem-prealloc should be added to > > > > > > the qemu > > > > commanline. > > > > > > If source is file then > > > > > > -object memory-backend-file,id=mem,size=1024M,mem-path=*lib dir > > > > > > path* -numa node,memdev=mem Will be added to the qemu > > > > > > commandline > > > > > > > > > > > > If access is shared then the "share=on" parameter will be added > > > > > > to the > > > > memory-backend-file e.g. > > > > > > -object > > > > > > memory-backend-file,id=mem,size=1024M,mem- > > > > path=/var/lib/libvirt/qemu > > > > > > ,share=on > > > > > > > > > > > > The access mode can be overriden by specifying token memAccess > > > > > > in numa > > > > cell. > > > > > > > > > > > > The test cpu-numa-memshared was removed, because behaviour was > > > > > > changed and is not needed anymore > > > > > > > > > > I beg to disagree. What if you don't have any ? > > > > > > > > > > I like these patches, but I'm not certainly sure about: > > > > > a) domain XML (in the past we used to require an ACK on schema > > > > > change from one of the Dans) > > > > > > > > What are you unsure about ? This XML is what I suggested in > > > > previous rounds of discussion. > > > > > > > > > b) the location for qemu to create its mmaped files (patch 3/3). > > > > > cfg->libDir looks very suspicious. > > > > > > > > Well we've got two possibilities - source=anonymous, should be using > > > > /dev/shm, similar to how we do huge pages. For source=file, we need > > > > a real filesystem. Something under /var/lib/libvirt is reasonable. > > > > Perhaps a dedicated dir is needed ? eg /var/lib/libvirt/ram in order > > > > to provide a point where the admin can mount a sufficiently large > > > > filesystem ? Or make it configurable in /etc/libvirt/qemu.conf > > > > > > > > > > [Jarek] It will be ok when I do something like libDir + "/ram". Or It > > > should be > > configurable on compilation time? > > > > Oh, I see that Dan already suggested to make it configurable. I would say > > both. > > Make it configurable in qemu.conf and use /var/lib/libvirt/ram as a default > > path. > > > [Jarek] will be ok to make it configurable in another patch set? Or it should > be all in one patch set? > Because it will take me some time, when I find out how to add this parameter > as configurable. It's not that hard :) for example this commit 661887f5582 can be used as an example how to add a new configurable option into qemu.conf. We have whole month before next release so it would be nice to have it as part of the same patch series. Pavel signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv4 0/3] Add support for file memorybacking
> -Original Message- > From: Pavel Hrdina [mailto:phrd...@redhat.com] > Sent: Monday, January 30, 2017 1:13 PM > To: Safka, JaroslavX <jaroslavx.sa...@intel.com> > Cc: Daniel P. Berrange <berra...@redhat.com>; Michal Privoznik > <mpriv...@redhat.com>; libvir-list@redhat.com; Mooney, Sean K > <sean.k.moo...@intel.com>; Ptacek, MichalX <michalx.pta...@intel.com> > Subject: Re: [libvirt] [PATCHv4 0/3] Add support for file memorybacking > > On Mon, Jan 30, 2017 at 12:06:19PM +, Safka, JaroslavX wrote: > > > > > > > -Original Message- > > > From: Daniel P. Berrange [mailto:berra...@redhat.com] > > > Sent: Monday, January 30, 2017 12:35 PM > > > To: Michal Privoznik <mpriv...@redhat.com> > > > Cc: Safka, JaroslavX <jaroslavx.sa...@intel.com>; > > > libvir-list@redhat.com; Mooney, Sean K <sean.k.moo...@intel.com>; > > > Ptacek, MichalX <michalx.pta...@intel.com> > > > Subject: Re: [libvirt] [PATCHv4 0/3] Add support for file > > > memorybacking > > > > > > On Sat, Jan 28, 2017 at 03:03:02PM +0100, Michal Privoznik wrote: > > > > On 13.12.2016 13:12, Jaroslav Safka wrote: > > > > > Hi, > > > > > we would like to introduce 3 new elements source,access and > > > > > allocation in > > > memoryBacking element. > > > > > For now it was made for numa topology. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If allocation is immediate then -mem-prealloc should be added to > > > > > the qemu > > > commanline. > > > > > If source is file then > > > > > -object memory-backend-file,id=mem,size=1024M,mem-path=*lib dir > > > > > path* -numa node,memdev=mem Will be added to the qemu > > > > > commandline > > > > > > > > > > If access is shared then the "share=on" parameter will be added > > > > > to the > > > memory-backend-file e.g. > > > > > -object > > > > > memory-backend-file,id=mem,size=1024M,mem- > > > path=/var/lib/libvirt/qemu > > > > > ,share=on > > > > > > > > > > The access mode can be overriden by specifying token memAccess > > > > > in numa > > > cell. > > > > > > > > > > The test cpu-numa-memshared was removed, because behaviour was > > > > > changed and is not needed anymore > > > > > > > > I beg to disagree. What if you don't have any ? > > > > > > > > I like these patches, but I'm not certainly sure about: > > > > a) domain XML (in the past we used to require an ACK on schema > > > > change from one of the Dans) > > > > > > What are you unsure about ? This XML is what I suggested in > > > previous rounds of discussion. > > > > > > > b) the location for qemu to create its mmaped files (patch 3/3). > > > > cfg->libDir looks very suspicious. > > > > > > Well we've got two possibilities - source=anonymous, should be using > > > /dev/shm, similar to how we do huge pages. For source=file, we need > > > a real filesystem. Something under /var/lib/libvirt is reasonable. > > > Perhaps a dedicated dir is needed ? eg /var/lib/libvirt/ram in order > > > to provide a point where the admin can mount a sufficiently large > > > filesystem ? Or make it configurable in /etc/libvirt/qemu.conf > > > > > > > [Jarek] It will be ok when I do something like libDir + "/ram". Or It > > should be > configurable on compilation time? > > Oh, I see that Dan already suggested to make it configurable. I would say > both. > Make it configurable in qemu.conf and use /var/lib/libvirt/ram as a default > path. > [Jarek] will be ok to make it configurable in another patch set? Or it should be all in one patch set? Because it will take me some time, when I find out how to add this parameter as configurable. > Pavel -- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv4 0/3] Add support for file memorybacking
On Mon, Jan 30, 2017 at 12:06:19PM +, Safka, JaroslavX wrote: > > > > -Original Message- > > From: Daniel P. Berrange [mailto:berra...@redhat.com] > > Sent: Monday, January 30, 2017 12:35 PM > > To: Michal Privoznik <mpriv...@redhat.com> > > Cc: Safka, JaroslavX <jaroslavx.sa...@intel.com>; libvir-list@redhat.com; > > Mooney, Sean K <sean.k.moo...@intel.com>; Ptacek, MichalX > > <michalx.pta...@intel.com> > > Subject: Re: [libvirt] [PATCHv4 0/3] Add support for file memorybacking > > > > On Sat, Jan 28, 2017 at 03:03:02PM +0100, Michal Privoznik wrote: > > > On 13.12.2016 13:12, Jaroslav Safka wrote: > > > > Hi, > > > > we would like to introduce 3 new elements source,access and allocation > > > > in > > memoryBacking element. > > > > For now it was made for numa topology. > > > > > > > > > > > > > > > > > > > > > > > > > > > > If allocation is immediate then -mem-prealloc should be added to the > > > > qemu > > commanline. > > > > If source is file then > > > > -object memory-backend-file,id=mem,size=1024M,mem-path=*lib dir > > > > path* -numa node,memdev=mem Will be added to the qemu commandline > > > > > > > > If access is shared then the "share=on" parameter will be added to the > > memory-backend-file e.g. > > > > -object > > > > memory-backend-file,id=mem,size=1024M,mem- > > path=/var/lib/libvirt/qemu > > > > ,share=on > > > > > > > > The access mode can be overriden by specifying token memAccess in numa > > cell. > > > > > > > > The test cpu-numa-memshared was removed, because behaviour was > > > > changed and is not needed anymore > > > > > > I beg to disagree. What if you don't have any ? > > > > > > I like these patches, but I'm not certainly sure about: > > > a) domain XML (in the past we used to require an ACK on schema change > > > from one of the Dans) > > > > What are you unsure about ? This XML is what I suggested in previous rounds > > of discussion. > > > > > b) the location for qemu to create its mmaped files (patch 3/3). > > > cfg->libDir looks very suspicious. > > > > Well we've got two possibilities - source=anonymous, should be using > > /dev/shm, similar to how we do huge pages. For source=file, we need a real > > filesystem. Something under /var/lib/libvirt is reasonable. > > Perhaps a dedicated dir is needed ? eg /var/lib/libvirt/ram in order to > > provide a > > point where the admin can mount a sufficiently large filesystem ? Or make > > it > > configurable in /etc/libvirt/qemu.conf > > > > [Jarek] It will be ok when I do something like libDir + "/ram". Or It should > be configurable on compilation time? Oh, I see that Dan already suggested to make it configurable. I would say both. Make it configurable in qemu.conf and use /var/lib/libvirt/ram as a default path. Pavel signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv4 0/3] Add support for file memorybacking
> -Original Message- > From: Daniel P. Berrange [mailto:berra...@redhat.com] > Sent: Monday, January 30, 2017 12:35 PM > To: Michal Privoznik <mpriv...@redhat.com> > Cc: Safka, JaroslavX <jaroslavx.sa...@intel.com>; libvir-list@redhat.com; > Mooney, Sean K <sean.k.moo...@intel.com>; Ptacek, MichalX > <michalx.pta...@intel.com> > Subject: Re: [libvirt] [PATCHv4 0/3] Add support for file memorybacking > > On Sat, Jan 28, 2017 at 03:03:02PM +0100, Michal Privoznik wrote: > > On 13.12.2016 13:12, Jaroslav Safka wrote: > > > Hi, > > > we would like to introduce 3 new elements source,access and allocation in > memoryBacking element. > > > For now it was made for numa topology. > > > > > > > > > > > > > > > > > > > > > If allocation is immediate then -mem-prealloc should be added to the qemu > commanline. > > > If source is file then > > > -object memory-backend-file,id=mem,size=1024M,mem-path=*lib dir > > > path* -numa node,memdev=mem Will be added to the qemu commandline > > > > > > If access is shared then the "share=on" parameter will be added to the > memory-backend-file e.g. > > > -object > > > memory-backend-file,id=mem,size=1024M,mem- > path=/var/lib/libvirt/qemu > > > ,share=on > > > > > > The access mode can be overriden by specifying token memAccess in numa > cell. > > > > > > The test cpu-numa-memshared was removed, because behaviour was > > > changed and is not needed anymore > > > > I beg to disagree. What if you don't have any ? > > > > I like these patches, but I'm not certainly sure about: > > a) domain XML (in the past we used to require an ACK on schema change > > from one of the Dans) > > What are you unsure about ? This XML is what I suggested in previous rounds > of discussion. > > > b) the location for qemu to create its mmaped files (patch 3/3). > > cfg->libDir looks very suspicious. > > Well we've got two possibilities - source=anonymous, should be using > /dev/shm, similar to how we do huge pages. For source=file, we need a real > filesystem. Something under /var/lib/libvirt is reasonable. > Perhaps a dedicated dir is needed ? eg /var/lib/libvirt/ram in order to > provide a > point where the admin can mount a sufficiently large filesystem ? Or make it > configurable in /etc/libvirt/qemu.conf > [Jarek] It will be ok when I do something like libDir + "/ram". Or It should be configurable on compilation time? > > Regards, > Daniel > -- > |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- http://virt-manager.org :| > |: http://entangle-photo.org -o-http://search.cpan.org/~danberr/ :| -- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv4 0/3] Add support for file memorybacking
On Sat, Jan 28, 2017 at 03:03:02PM +0100, Michal Privoznik wrote: > On 13.12.2016 13:12, Jaroslav Safka wrote: > > Hi, > > we would like to introduce 3 new elements source,access and allocation in > > memoryBacking element. > > For now it was made for numa topology. > > > > > > > > > > > > > > > > If allocation is immediate then -mem-prealloc should be added to the qemu > > commanline. > > If source is file then > > -object memory-backend-file,id=mem,size=1024M,mem-path=*lib dir path* -numa > > node,memdev=mem Will be added to the qemu commandline > > > > If access is shared then the "share=on" parameter will be added to the > > memory-backend-file e.g. > > -object > > memory-backend-file,id=mem,size=1024M,mem-path=/var/lib/libvirt/qemu,share=on > > > > The access mode can be overriden by specifying token memAccess in numa cell. > > > > The test cpu-numa-memshared was removed, because behaviour was changed and > > is not needed anymore > > I beg to disagree. What if you don't have any ? > > I like these patches, but I'm not certainly sure about: > a) domain XML (in the past we used to require an ACK on schema change > from one of the Dans) What are you unsure about ? This XML is what I suggested in previous rounds of discussion. > b) the location for qemu to create its mmaped files (patch 3/3). > cfg->libDir looks very suspicious. Well we've got two possibilities - source=anonymous, should be using /dev/shm, similar to how we do huge pages. For source=file, we need a real filesystem. Something under /var/lib/libvirt is reasonable. Perhaps a dedicated dir is needed ? eg /var/lib/libvirt/ram in order to provide a point where the admin can mount a sufficiently large filesystem ? Or make it configurable in /etc/libvirt/qemu.conf Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o-http://search.cpan.org/~danberr/ :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv4 0/3] Add support for file memorybacking
On 01/30/2017 09:07 AM, Safka, JaroslavX wrote:
> Hi,
> first , thanks much for review.
> Comments inside
>
>> -Original Message-
>> From: Michal Privoznik [mailto:mpriv...@redhat.com]
>> Sent: Saturday, January 28, 2017 3:03 PM
>> To: Safka, JaroslavX <jaroslavx.sa...@intel.com>; libvir-list@redhat.com
>> Cc: Mooney, Sean K <sean.k.moo...@intel.com>; Ptacek, MichalX
>> <michalx.pta...@intel.com>; Daniel P. Berrange <berra...@redhat.com>
>> Subject: Re: [libvirt] [PATCHv4 0/3] Add support for file memorybacking
>>
>> On 13.12.2016 13:12, Jaroslav Safka wrote:
>>> Hi,
>>> we would like to introduce 3 new elements source,access and allocation in
>> memoryBacking element.
>>> For now it was made for numa topology.
>>>
>>>
>>>
>>>
>>>
>>>
>>> If allocation is immediate then -mem-prealloc should be added to the qemu
>> commanline.
>>> If source is file then
>>> -object memory-backend-file,id=mem,size=1024M,mem-path=*lib dir path*
>>> -numa node,memdev=mem Will be added to the qemu commandline
>>>
>>> If access is shared then the "share=on" parameter will be added to the
>> memory-backend-file e.g.
>>> -object
>>> memory-backend-file,id=mem,size=1024M,mem-path=/var/lib/libvirt/qemu,s
>>> hare=on
>>>
>>> The access mode can be overriden by specifying token memAccess in numa
>> cell.
>>>
>>> The test cpu-numa-memshared was removed, because behaviour was
>> changed
>>> and is not needed anymore
>>
>> I beg to disagree. What if you don't have any ?
> [Jarek] disagree with removing the test or with xml change?
XML change is okay. But I don't think that behaviour is changed (rather
than extended). I mean, prior to these patches the following
configuration errors out:
With your patches, the error is no longer observed. Wait, is this
expected? If so, than you need to remove that check in
qemuBuildMemoryBackendStr in 3/3 which I told you not to do and also:
diff --git i/tests/qemuxml2argvtest.c w/tests/qemuxml2argvtest.c
index f09c5460f..feb50f7a2 100644
--- i/tests/qemuxml2argvtest.c
+++ w/tests/qemuxml2argvtest.c
@@ -1516,7 +1516,7 @@ mymain(void)
DO_TEST_PARSE_ERROR("cpu-numa3", NONE);
DO_TEST_FAILURE("cpu-numa-disjoint", NONE);
DO_TEST("cpu-numa-disjoint", QEMU_CAPS_NUMA);
-DO_TEST_FAILURE("cpu-numa-memshared", QEMU_CAPS_OBJECT_MEMORY_RAM);
+DO_TEST("cpu-numa-memshared", QEMU_CAPS_OBJECT_MEMORY_RAM);
DO_TEST_FAILURE("cpu-numa-memshared", NONE);
DO_TEST("cpu-host-model", NONE);
DO_TEST("cpu-host-model-vendor", NONE);
>
>
>>
>> I like these patches, but I'm not certainly sure about:
>> a) domain XML (in the past we used to require an ACK on schema change from
>> one of the Dans)
>> b) the location for qemu to create its mmaped files (patch 3/3).
>> cfg->libDir looks very suspicious.
>>
> [Jarek] is there any link or keywords for find to these previous discussions?
> I'm not able to find it :(
What discussion do you have in mind? The a) rule was not a written kind
of rule.
>
>
>> I have the patches applied locally with all the changes I've pointed out
>> applied.
>> If we have answers to both of the questions, I can push these.
This is still true. So no need to rework the patches on your side (you
can view this as my attempt to say sorry for such late review).
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv4 0/3] Add support for file memorybacking
Hi, first , thanks much for review. Comments inside > -Original Message- > From: Michal Privoznik [mailto:mpriv...@redhat.com] > Sent: Saturday, January 28, 2017 3:03 PM > To: Safka, JaroslavX <jaroslavx.sa...@intel.com>; libvir-list@redhat.com > Cc: Mooney, Sean K <sean.k.moo...@intel.com>; Ptacek, MichalX > <michalx.pta...@intel.com>; Daniel P. Berrange <berra...@redhat.com> > Subject: Re: [libvirt] [PATCHv4 0/3] Add support for file memorybacking > > On 13.12.2016 13:12, Jaroslav Safka wrote: > > Hi, > > we would like to introduce 3 new elements source,access and allocation in > memoryBacking element. > > For now it was made for numa topology. > > > > > > > > > > > > > > If allocation is immediate then -mem-prealloc should be added to the qemu > commanline. > > If source is file then > > -object memory-backend-file,id=mem,size=1024M,mem-path=*lib dir path* > > -numa node,memdev=mem Will be added to the qemu commandline > > > > If access is shared then the "share=on" parameter will be added to the > memory-backend-file e.g. > > -object > > memory-backend-file,id=mem,size=1024M,mem-path=/var/lib/libvirt/qemu,s > > hare=on > > > > The access mode can be overriden by specifying token memAccess in numa > cell. > > > > The test cpu-numa-memshared was removed, because behaviour was > changed > > and is not needed anymore > > I beg to disagree. What if you don't have any ? [Jarek] disagree with removing the test or with xml change? > > I like these patches, but I'm not certainly sure about: > a) domain XML (in the past we used to require an ACK on schema change from > one of the Dans) > b) the location for qemu to create its mmaped files (patch 3/3). > cfg->libDir looks very suspicious. > [Jarek] is there any link or keywords for find to these previous discussions? I'm not able to find it :( > I have the patches applied locally with all the changes I've pointed out > applied. > If we have answers to both of the questions, I can push these. > > Michal -- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv4 0/3] Add support for file memorybacking
On 13.12.2016 13:12, Jaroslav Safka wrote: > Hi, > we would like to introduce 3 new elements source,access and allocation in > memoryBacking element. > For now it was made for numa topology. > > > > > > > > If allocation is immediate then -mem-prealloc should be added to the qemu > commanline. > If source is file then > -object memory-backend-file,id=mem,size=1024M,mem-path=*lib dir path* -numa > node,memdev=mem Will be added to the qemu commandline > > If access is shared then the "share=on" parameter will be added to the > memory-backend-file e.g. > -object > memory-backend-file,id=mem,size=1024M,mem-path=/var/lib/libvirt/qemu,share=on > > The access mode can be overriden by specifying token memAccess in numa cell. > > The test cpu-numa-memshared was removed, because behaviour was changed and is > not needed anymore I beg to disagree. What if you don't have any ? I like these patches, but I'm not certainly sure about: a) domain XML (in the past we used to require an ACK on schema change from one of the Dans) b) the location for qemu to create its mmaped files (patch 3/3). cfg->libDir looks very suspicious. I have the patches applied locally with all the changes I've pointed out applied. If we have answers to both of the questions, I can push these. Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
