Re: [libvirt] [sandbox] Weird apparmor problems

On Fri, 2015-10-30 at 09:15 +0900, Daniel P. Berrange wrote: > NB in containers we have two PTYs involved. The libvirt_lxc process > opens one pty in the host context and that is used to communicate > between virsh console & libvirt_lxc. The libvirt_lxc process opens > one pty in the guest

Re: [libvirt] qemu-agent-command via isa-serial for freebsd

2015-10-29 18:40 GMT+03:00 Michal Privoznik : > You need to have a virtio channel whose target name is > "org.qemu.guest_agent.0". The source does not matter to libvirt - we can > connect both to an unix socket or pty. Can you helps me via providing xml for this? Freebsd

Re: [libvirt] [PATCH] vz: support cpu time in driver's domainGetInfo

28.10.2015 17:29, Nikolay Shirokovskiy пишет: Just straight-forward patch. Use reference counting for privdom as stats internally could drop domain lock. Signed-off-by: Nikolay Shirokovskiy --- src/vz/vz_driver.c | 19 --- 1 files changed, 16

Re: [libvirt] [PATCH 2/3] Qemu: add CMT support

> -Original Message- > From: Daniel P. Berrange [mailto:berra...@redhat.com] > Sent: Thursday, October 29, 2015 10:56 PM > To: Ren, Qiaowei > Cc: libvir-list@redhat.com; Feng, Shaohe > Subject: Re: [PATCH 2/3] Qemu: add CMT support > > On Thu, Oct 29, 2015 at 02:02:29PM +0800, Qiaowei

Re: [libvirt] Entering freeze for libvirt-1.2.21

On Thu, Oct 29, 2015 at 03:28:51PM +0800, Daniel Veillard wrote: > As pointed our on Tuesday it's time for a new release. I have tagged > the release candidate 1 in git and pushed signed tarball and rpms to > the usual place at: > >ftp://libvirt.org/libvirt/ > > Based on my limited

Re: [libvirt] qemu-agent-command via isa-serial for freebsd

On Fri, Oct 30, 2015 at 01:32:34PM +0300, Vasiliy Tolstov wrote: 2015-10-30 13:08 GMT+03:00 Michal Privoznik : Yeah, something like that could work. Mind proposing patch? Maybe... Does it possible to get something like this: i'm not understand does target for

Re: [libvirt] qemu-agent-command via isa-serial for freebsd

2015-10-30 13:00 GMT+03:00 Michal Privoznik : > Oh right, libvirt only know how to deal with channels. ISA serials are > ignored when it comes to qemu-ga. The problem is that from looking at > we don't know which one is suppose to be for the agent. For > instance: > > >

Re: [libvirt] qemu-agent-command via isa-serial for freebsd

2015-10-30 13:57 GMT+03:00 Michal Privoznik : > Right now, qemu-ga has -p switch, that allows you to pass the path it > should listen to. In this case: > > qemu-ga -m isa-serial -p /dev/ttyS0 > > should do. I'm no *BSD-ian, but I bet it can be configured in their > startup

Re: [libvirt] qemu-agent-command via isa-serial for freebsd

On 30.10.2015 08:32, Vasiliy Tolstov wrote: > 2015-10-29 18:40 GMT+03:00 Michal Privoznik : >> You need to have a virtio channel whose target name is >> "org.qemu.guest_agent.0". The source does not matter to libvirt - we can >> connect both to an unix socket or pty. > > >

Re: [libvirt] qemu-agent-command via isa-serial for freebsd

On 30.10.2015 11:04, Vasiliy Tolstov wrote: > 2015-10-30 13:00 GMT+03:00 Michal Privoznik : >> Oh right, libvirt only know how to deal with channels. ISA serials are >> ignored when it comes to qemu-ga. The problem is that from looking at >> we don't know which one is suppose

Re: [libvirt] RFC: Improve performance of macvtap device creation

On 29.10.2015 18:48, Laine Stump wrote: > On 10/29/2015 12:49 PM, Tony Krowiak wrote: >> For a guest domain defined with a large number of macvtap devices, it >> takes an exceedingly long time to boot the guest. In a test of a guest >> domain configured with 82 macvtap devices, it took over two

Re: [libvirt] [PATCH v2 2/3] virsh-domain: update attach-interface to support type=hostdev

On Thu, Oct 29, 2015 at 10:33:51AM -0400, John Ferlan wrote: > > > On 10/29/2015 03:08 AM, Pavel Hrdina wrote: > > On Tue, Oct 27, 2015 at 06:16:33PM -0400, John Ferlan wrote: > >> > > [...] > > >> > >> What happens if someone provides --managed with some other 'typ'? > >> > >> IOW: If it's

Re: [libvirt] qemu-agent-command via isa-serial for freebsd

2015-10-30 13:08 GMT+03:00 Michal Privoznik : > Yeah, something like that could work. Mind proposing patch? Maybe... Does it possible to get something like this: i'm not understand does target for serial can have name. qemuFindAgentConfig uses if

Re: [libvirt] qemu-agent-command via isa-serial for freebsd

2015-10-30 13:46 GMT+03:00 Martin Kletzander : > That doesn't make sense to me. virtio channel can have a name, but > isa serial cannot, that name wouldn't make sense. Also, how would you > identify to which serial port to attach in the guest-agent? Hm.. interesting

Re: [libvirt] [PATCH v2 3/3] virsh.pod: update and improve a attach-interface section

On Thu, Oct 29, 2015 at 10:52:00AM -0400, John Ferlan wrote: > > > On 10/29/2015 04:42 AM, Pavel Hrdina wrote: > > On Tue, Oct 27, 2015 at 06:53:55PM -0400, John Ferlan wrote: > >> > >> > >> On 10/27/2015 11:01 AM, Pavel Hrdina wrote: > >>> Rewrite the attach-interface section in man page to be

Re: [libvirt] RAM backend and guest ABI (was Re: [Qemu-devel] [PATCH v2] pc: memhp: enforce minimal 128Mb) alignment for pc-dimm

On Thu, 29 Oct 2015 16:16:57 -0200 Eduardo Habkost wrote: > (CCing Michal and libvir-list, so libvirt team is aware of this > restriction) > > On Thu, Oct 29, 2015 at 02:36:37PM +0100, Igor Mammedov wrote: > > On Tue, 27 Oct 2015 14:36:35 -0200 > > Eduardo Habkost

Re: [libvirt] RFC: Improve performance of macvtap device creation

On Fri, Oct 30, 2015 at 11:49:12AM +0100, Michal Privoznik wrote: > On 29.10.2015 18:48, Laine Stump wrote: > > On 10/29/2015 12:49 PM, Tony Krowiak wrote: > >> For a guest domain defined with a large number of macvtap devices, it > >> takes an exceedingly long time to boot the guest. In a test of

Re: [libvirt] [sandbox] Weird apparmor problems

On Fri, 2015-10-30 at 09:15 +0900, Daniel P. Berrange wrote: > So, yes, it is normal for libvirt_lxc to access /dev/ptmx to create > a new master PTY and to read/write to /dev/pts/NN associated with > the file descriptor retrieved from /dev/ptmx. After some more debugging and help from jjohansen,

Re: [libvirt] [PATCH 4/8] Wait for vfio-pci device cleanups before reassinging the device to host driver

On Fri, 2015-10-30 at 04:58 +0530, Shivaprasad G Bhat wrote: > Before unbind from stub driver libvirt should be sure the guest is not using > the device anymore. The libvirt today waits for pci-stub driver alone in > /proc/iommu. > The same wait is needed for vfio devices too. > > Signed-off-by:

Re: [libvirt] [PATCH 3/8] Refuse to reattach from vfio if the iommu group is in use by any domain

On Fri, 2015-10-30 at 04:57 +0530, Shivaprasad G Bhat wrote: > It is incorrect to attempt the device reattach of a function, > when some other domain is using some functions belonging to the same iommu > group. > > Signed-off-by: Shivaprasad G Bhat > --- >

Re: [libvirt] [PATCH 1/8] Initialize the stubDriver of pci devices if bound to a valid one

Thanks for the comments Andrea. On Fri, Oct 30, 2015 at 8:27 PM, Andrea Bolognani wrote: > On Fri, 2015-10-30 at 04:56 +0530, Shivaprasad G Bhat wrote: >> The stubDriver name can be used to make useful decisions if readily >> available. >> Set it if bound to a valid one

Re: [libvirt] [PATCH 5/8] Split reprobe action from the virPCIUnbindFromStub into a new function

On Fri, 2015-10-30 at 04:59 +0530, Shivaprasad G Bhat wrote: > The reprobe needs to be called multiple times for vfio devices for each > device in the iommu group in future patch. So split the reprobe into a > new function. No functional change. > > Signed-off-by: Shivaprasad G Bhat

Re: [libvirt] [PATCH 6/8] Pass activeDevs and inactiveDevs to virPCIDeviceUnbindFromStub and virPCIDeviceBindToStub

On Fri, 2015-10-30 at 05:00 +0530, Shivaprasad G Bhat wrote: > The inactiveDevs need to be selectively altered for more than one > device in case of vfio devices. So, pass the whole list. > > Signed-off-by: Shivaprasad G Bhat > --- > src/util/virpci.c | 38

Re: [libvirt] RFC: Improve performance of macvtap device creation

On 10/30/2015 06:49 AM, Michal Privoznik wrote: On 29.10.2015 18:48, Laine Stump wrote: On 10/29/2015 12:49 PM, Tony Krowiak wrote: For a guest domain defined with a large number of macvtap devices, it takes an exceedingly long time to boot the guest. In a test of a guest domain configured

Re: [libvirt] [PATCH 8/8] Wait for iommmu device to go away before reprobing the host driver

On Fri, 2015-10-30 at 05:04 +0530, Shivaprasad G Bhat wrote: > Author: Shivaprasad G Bhat This line is redundant since the information is already stored in git, plus you have the Signed-off-by below. This applies to Patch 7 as well. > > There could be a delay of 1 or

[libvirt] [PATCH] storage: Ignore block devices that fail format detection

https://bugzilla.redhat.com/show_bug.cgi?id=1276198 Prior to commit id '98322052' failure to saferead the block device would cause an error to be logged and the device to be skipped while attempting to discover/create a stable target path for a new LUN (NPIV). This was because

Re: [libvirt] [PATCH 7/8] Postpone reprobing till all the devices in iommu group are unbound from vfio

I know you're already working on a v2 of this, just a couple of quick remarks below. On Fri, 2015-10-30 at 05:01 +0530, Shivaprasad G Bhat wrote: > Author: Shivaprasad G Bhat > > The host will crash if a device is bound to host driver when the device > belonging to

Re: [libvirt] [PATCH 1/8] Initialize the stubDriver of pci devices if bound to a valid one

On Fri, 2015-10-30 at 04:56 +0530, Shivaprasad G Bhat wrote: > The stubDriver name can be used to make useful decisions if readily available. > Set it if bound to a valid one during initialisation. > > Signed-off-by: Shivaprasad G Bhat > --- > src/util/virpci.c | 36

Re: [libvirt] [PATCH 2/8] Add iommu group number info to virPCIDevice

n Fri, 2015-10-30 at 04:56 +0530, Shivaprasad G Bhat wrote: > The iommu group number need not be fetched from the sysfs > everytime as it remains constant. Fetch it once during > allocation > > Signed-off-by: Shivaprasad G Bhat > --- > src/util/virpci.c |5 + >

[libvirt] [PATCH 0/8] Few vfio related fixes

The series fixes 3 issues which lead to host crash. The actual fixes are in p3, p4, p7 and p8. I'll fill in more details / descriptions in v2. The make check fails on virpcitest now, which I am still debugging. I anticipate some rework from review on p7 which I continue to refine. Sending now, to

Re: [libvirt] [PATCH 1/8] Initialize the stubDriver of pci devices if bound to a valid one

On Fri, 2015-10-30 at 20:34 +0530, Shivaprasad bhat wrote: > > > @@ -1556,6 +1563,8 @@ virPCIDeviceNew(unsigned int domain, > > > virPCIDevicePtr dev; > > > char *vendor = NULL; > > > char *product = NULL; > > > +char *drvpath = NULL; > > > +char *driver = NULL; > > > > > >

Re: [libvirt] RFC: Improve performance of macvtap device creation

On 10/30/2015 11:56 AM, Tony Krowiak wrote: On 10/30/2015 06:49 AM, Michal Privoznik wrote: On 29.10.2015 18:48, Laine Stump wrote: On 10/29/2015 12:49 PM, Tony Krowiak wrote: For a guest domain defined with a large number of macvtap devices, it takes an exceedingly long time to boot the

Re: [libvirt] RFC: Improve performance of macvtap device creation

On 10/30/2015 01:44 PM, Tony Krowiak wrote: On 10/29/2015 01:48 PM, Laine Stump wrote: On 10/29/2015 12:49 PM, Tony Krowiak wrote: For a guest domain defined with a large number of macvtap devices, it takes an exceedingly long time to boot the guest. In a test of a guest domain configured

Re: [libvirt] qemu-agent-command via isa-serial for freebsd

On 30.10.2015 11:46, Martin Kletzander wrote: > On Fri, Oct 30, 2015 at 01:32:34PM +0300, Vasiliy Tolstov wrote: >> 2015-10-30 13:08 GMT+03:00 Michal Privoznik : >>> Yeah, something like that could work. Mind proposing patch? >> >> >> Maybe... >> Does it possible to get

Re: [libvirt] RFC: Improve performance of macvtap device creation

On 10/29/2015 01:48 PM, Laine Stump wrote: On 10/29/2015 12:49 PM, Tony Krowiak wrote: For a guest domain defined with a large number of macvtap devices, it takes an exceedingly long time to boot the guest. In a test of a guest domain configured with 82 macvtap devices, it took over two