Re: [libvirt] [Qemu-devel] [PATCH v4 7/8] qmp: Support abstract classes on device-list-properties

Eduardo Habkost writes: > On Mon, Nov 07, 2016 at 03:40:57PM +0100, Markus Armbruster wrote: >> Eduardo Habkost writes: >> >> > On Mon, Nov 07, 2016 at 09:09:58AM +0100, Markus Armbruster wrote: >> >> Eduardo Habkost writes: >> >>

[libvirt] [PATCH] qemu: Only allow 'raw' format for scsi-block using virtio-scsi

https://bugzilla.redhat.com/show_bug.cgi?id=1379196 Add check in qemuCheckDiskConfig for an invalid combination of using the 'scsi' bus for a block 'lun' device and any disk source format other than 'raw'. Signed-off-by: John Ferlan --- src/qemu/qemu_command.c | 8

[libvirt] [PATCH v2 00/11] clean up after "slot sharing" patches

(this is just a rebase of the v1 patches to make review easier) Some of the patches that enabled sharing PCI slots by multiple pcie-root-ports made the idea of reserving an entire slot obsolete. To reduce confusion and misunderstandings, this patch series gets rid of the name "Slot" in all of the

[libvirt] [PATCH v2 07/11] conf: rename virDomainPCIAddressReserveAddr() to ...Internal()

This is in preparation for renaming virDomainPCIAddressReserveSlot() to virDomainPCIAddressReserveAddr(), which is a better description of what it does. --- src/conf/domain_addr.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/src/conf/domain_addr.c

[libvirt] [PATCH v2 09/11] qemu: remove qemuDomainPCIAddressReserveNextAddr()

This function is only called in two places, and the function itself is just adding a single argument and calling virDomainPCIAddressReserveNextAddr(), so we can remove it and instead call virDomainPCIAddressReserveNextAddr() directly. (The main motivation for doing this is to free up the name so

[libvirt] [PATCH v2 10/11] qemu: rename qemuDomainPCIAddressReserveNextSlot() to ...Addr()

This function doesn't actually reserve an entire slot any more, it reserves a single PCI address, so this name is more appropriate. --- src/qemu/qemu_domain_address.c | 45 +- 1 file changed, 23 insertions(+), 22 deletions(-) diff --git

[libvirt] [PATCH v2 06/11] conf: make virDomainPCIAddressReserveAddr() a static function

It is now only used in domain_addr.c. --- src/conf/domain_addr.c | 2 +- src/conf/domain_addr.h | 6 -- src/libvirt_private.syms | 1 - 3 files changed, 1 insertion(+), 8 deletions(-) diff --git a/src/conf/domain_addr.c b/src/conf/domain_addr.c index dde4237..b1779c4 100644 ---

[libvirt] [PATCH v2 11/11] conf: eliminate virDomainPCIAddressReleaseSlot() in favor of ...Addr()

Surprisingly there was a virDomainPCIAddressReleaseAddr() function already, but it was completely unused. Since we don't reserve entire slots at once any more, there is no need to release entire slots either, so we just replace the single call to virDomainPCIAddressReleaseSlot() with a call to

[libvirt] [PATCH v2 08/11] conf: rename virDomainPCIAddressReserveSlot() to ...Addr()

This function doesn't actually reserve an entire slot any more, it reserves a single PCI address, so this name is more appropriate. --- src/bhyve/bhyve_device.c | 8 ++-- src/conf/domain_addr.c | 2 +- src/conf/domain_addr.h | 2 +- src/libvirt_private.syms | 2

[libvirt] [PATCH v2 05/11] qemu: replace virDomainPCIAddressReserveAddr with virDomainPCIAddressReserveSlot

All occurences of the former use fromConfig=true, and that's exactly how virDomainPCIAddressReserveSlot() calls virDomainPCIaddressReserveAddr(), so just use *Slot() so that *Addr() can be made static to conf/domain_addr.c (both functions will be renamed in upcoming patches). ---

[libvirt] [PATCH v2 02/11] conf: fix fromConfig argument to virDomainPCIAddressValidate()

fromConfig should be true if the caller want virDomainPCIAddressValidate() to loosen restrictions on its interpretation of the pciConnectFlags. In particular, either PCI_DEVICE or PCIE_DEVICE will be counted as equivalent to both, and HOTPLUG will be ignored. In a few cases where libvirt was

[libvirt] [PATCH v2 03/11] conf: rename virDomainPCIAddressGetNextSlot() to ...GetNextAddr()

With the advent of VIR_PCI_CONNECT_AGGREGATE_SLOT, the new name is more appropriate, since the address contained may be another address on the same slot as last time, not necessarily a new slot. --- src/conf/domain_addr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[libvirt] [PATCH v2 01/11] conf: fix fromConfig argument to virDomainPCIAddressReserveAddr()

Although setting virDomainPCIAddressReserveAddr()'s fromConfig=true is correct when a PCI addres is coming from a domain's config, the *true* purpose of the fromConfig argument is to lower restrictions on what kind of device can plug into what kind of controller - if fromConfig is true, then a

[libvirt] [PATCH v2 04/11] conf: eliminate virDomainPCIAddressReserveNextSlot()

Since we don't actually reserve an entire slot at a time anymore, the name of this function is just confusing, and it's almost identical in operation to virDomainPCIAddressReserveNextAddr() anyway, so remove the *Slot() function and replace calls to it with calls to *Addr(..., -1). ---

[libvirt] [PATCH v2 2/2] vbox: get rid of g_pVBoxGlobalData

now that we have a new global vboxDriver object, remove the old vboxGlobalData struct and all references to it. --- src/vbox/vbox_common.c| 168 +-- src/vbox/vbox_common.h| 2 +- src/vbox/vbox_network.c | 24 +-- src/vbox/vbox_storage.c | 20 +--

[libvirt] [PATCH v2 1/2] vbox: change how vbox API is initialized.

* add vboxDriver object to serve as a singleton global object that holds references to IVirtualBox and ISession to be shared among multiple connections. The vbox_driver is instantiated only once in the first call vboxGetDriverConnection function that is guarded by a mutex. * call vbox API

[libvirt] [PATCH v2 0/2] vbox: address thread-safety issues

This patch series solves vbox driver thread-safety issues where libvird process would segfault when there was more than one concurrent vbox connection. The reason for the segfault was because the original implementation called pfnComInitialize/Unintialize on each virConnectOpen/Close calls which

[libvirt] [PATCH v2 7/9] conf: Add support for blkiotune group_name option

Modify _virDomainBlockIoTuneInfo and rng schema to support the group_name option for iotune throttling. Document the new value. Signed-off-by: John Ferlan --- docs/formatdomain.html.in | 11 docs/schemas/domaincommon.rng |

[libvirt] [PATCH v2 6/9] qemu: Add support for parsing iotune group setting

Add support to read/parse the iotune group setting for qemu. Signed-off-by: John Ferlan --- include/libvirt/libvirt-domain.h | 8 src/conf/domain_conf.c | 1 + src/conf/domain_conf.h | 1 + src/qemu/qemu_driver.c | 45

[libvirt] [PATCH v2 0/9] Add group_name support for

v1: http://www.redhat.com/archives/libvir-list/2016-October/msg01336.html Changes from v1: Patches 3-5 are new to address review comments Other adjustments as listed in responses to v1: - Addressed leak in qemuDomainSetBlockIoTune from setting "group_name" defaults - Test adjustment for

[libvirt] [PATCH v2 8/9] qemu: Add the group name option to the iotune command line

Add in the block I/O throttling group parameter to the command line if supported. If not supported, fail command creation. Add the xml2argvtest for testing. Signed-off-by: John Ferlan --- src/qemu/qemu_command.c| 13 +

[libvirt] [PATCH v2 9/9] virsh: Add group name to blkdeviotune output

https://bugzilla.redhat.com/show_bug.cgi?id=1336564 Add the ability to set/display the group_name for block device iotune Signed-off-by: John Ferlan --- tools/virsh-domain.c | 17 + tools/virsh.pod | 5 - 2 files changed, 21 insertions(+), 1

[libvirt] [PATCH v2 5/9] qemu: Adjust various bool BlockIoTune set_ values into mask

Rather than have multiple bool values, create a single enum with bits representing what can be set. Signed-off-by: John Ferlan --- src/qemu/qemu_driver.c | 113 +++-- 1 file changed, 54 insertions(+), 59 deletions(-) diff --git

[libvirt] [PATCH v2 1/9] include: Add new "group_name" definition for iotune throttling

Add the new field to support sharing I/O throttling quota between multiple drives. Signed-off-by: John Ferlan --- include/libvirt/libvirt-domain.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-domain.h

[libvirt] [PATCH v2 3/9] qemu: Adjust maxparams logic for qemuDomainGetBlockIoTune

Rather than using negative logic and setting the maxparams to a lesser value based on which capabilities exist, alter the logic to modify the maxparams based on a base value plus the found capabilities. Reduces the chance that some backported feature produces an incorrect value. Signed-off-by:

[libvirt] [PATCH v2 4/9] qemu: Alter qemuMonitorJSONSetBlockIoThrottle command logic

Currently we build the JSON object for the "block_set_io_throttle" command using the knowledge that a NULL for a support*Options boolean would essentially ignore the rest of the arguments. This may not work properly if some capability was backported, plus it just looks rather ugly. So instead,

[libvirt] [PATCH v2 2/9] caps: Add new capability for the iotune group name

Add the capability to detect if the qemu binary can support the feature to use throttling.group. Signed-off-by: John Ferlan --- src/qemu/qemu_capabilities.c| 2 ++ src/qemu/qemu_capabilities.h| 1 +

Re: [libvirt] [PATCH 4/6] conf: Add support for blkiotune group_name option

On 11/02/2016 10:38 AM, Martin Kletzander wrote: > On Mon, Oct 31, 2016 at 05:23:00PM -0400, John Ferlan wrote: >> Modify _virDomainBlockIoTuneInfo and rng schema to support the group_name >> option for iotune throttling. Document the new value. >> >> Signed-off-by: John Ferlan

Re: [libvirt] [PATCH 3/6] qemu: Add support for parsing iotune group setting

On 11/02/2016 12:37 PM, Erik Skultety wrote: > On Mon, Oct 31, 2016 at 05:22:59PM -0400, John Ferlan wrote: >> Add support to read/parse the iotune group setting for qemu. >> >> Signed-off-by: John Ferlan >> --- >> include/libvirt/libvirt-domain.h | 8 + >>

Re: [libvirt] [PATCH 3/6] qemu: Add support for parsing iotune group setting

On 11/02/2016 10:24 AM, Martin Kletzander wrote: > On Mon, Oct 31, 2016 at 05:22:59PM -0400, John Ferlan wrote: >> Add support to read/parse the iotune group setting for qemu. >> >> Signed-off-by: John Ferlan >> --- >> include/libvirt/libvirt-domain.h | 8 + >>

Re: [libvirt] [PATCH 1/2] vbox: add vbox 5.1 C API header file.

On Mon, 2016-11-07 at 15:16 -0600, Eric Blake wrote: > On 11/07/2016 03:03 PM, Dawid Zamirski wrote: > > > > extracted from VirutalBox SDK and reindented with cppi. > > --- > >  src/vbox/vbox_CAPI_v5_1.h | 26117 > > > >  1 file changed, 26117

Re: [libvirt] [PATCH 1/2] vbox: add vbox 5.1 C API header file.

On 11/07/2016 03:03 PM, Dawid Zamirski wrote: > > extracted from VirutalBox SDK and reindented with cppi. > --- > src/vbox/vbox_CAPI_v5_1.h | 26117 > > 1 file changed, 26117 insertions(+) > create mode 100644 src/vbox/vbox_CAPI_v5_1.h 1.1 Meg of

[libvirt] [PATCH 2/2] vbox: hookup the 5.1 C API to the unified driver.

simply follow the same pattern as other versions did. --- src/Makefile.am | 1 + src/vbox/vbox_V5_1.c | 13 + src/vbox/vbox_common.h| 2 ++ src/vbox/vbox_storage.c | 2 ++ src/vbox/vbox_tmpl.c | 2 ++ src/vbox/vbox_uniformed_api.h |

[libvirt] [PATCH 0/2] vbox: add support for 5.1.x

With VBox 5.1.x release new SDK header needs to be added to libvirt sources. Sending as attachments due to the size of the first patch being a large header file taken from VBOX SDK. Dawid Zamirski (2): vbox: add vbox 5.1 C API header file. vbox: hookup the 5.1 C API to the unified driver.

[libvirt] [PATCH] qemu: Emit domain events for all virtio-serial channels

Presently domain events are emitted for the "agent lifecycle" which is a specialization on virtio-serial events specific to the channel named "org.qemu.guest_agent.0". This patch adds a generic event for "channel lifecycles", which emit state change events for all attached channels. ---

Re: [libvirt] [PATCH v6 17/17] qemu: assign vfio devices to PCIe addresses when appropriate

On Mon, 7 Nov 2016 14:50:25 -0500 Laine Stump wrote: > Although nearly all host devices that are assigned to guests using > vfio ("" devices in libvirt) are physically PCI Express > devices, until now libvirt's PCI address assignment has always > assigned them addresses on

[libvirt] [PATCH] Test driver should error when domain destroy twice

Fixes the behavior when destroying a domain more than once. VIR_ERR_OPERATION_INVALID should be raised when destroying an already destroyed domain. --- src/test/test_driver.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/src/test/test_driver.c b/src/test/test_driver.c index

[libvirt] [PATCH v2 0/8] aggregate multiple pcie-root-ports onto a single slot

This is just a rebase of v1 of the same series, reposted to make it easier for Andrea to review. Laine Stump (8): conf: use struct instead of int for each slot in virDomainPCIAddressBus conf: eliminate concept of "reserveEntireSlot" conf: eliminate repetitive code in

[libvirt] [PATCH v2 1/8] conf: use struct instead of int for each slot in virDomainPCIAddressBus

When keeping track of which functions of which slots are allocated, we will need to have more information than just the current bitmap with a bit for each function that is currently stored for each slot in a virDomainPCIAddressBus. To prepare for adding more per-slot info, this patch changes "int

[libvirt] [PATCH v2 4/8] conf: start search for next unused PCI address at same slot as previous find

There is a very slight time advantage to beginning the search for the next unused PCI address at the slot *after* the previous find (which is now used), but if we do that, we will miss allocating the other functions of the same slot (when we implement a VIR_PCI_CONNECT_AGGREGATE_SLOT flag to

[libvirt] [PATCH v2 8/8] conf: aggregate multiple pcie-root-ports onto a single slot

Set the VIR_PCI_CONNECT_AGGREGATE_SLOT flag for pcie-root-ports so that they will be assigned to all the functions on a slot. Some qemu test case outputs had to be adjusted due to the pcie-root-ports now being put on multiple functions. --- src/conf/domain_addr.c | 2

[libvirt] [PATCH v2 6/8] qemu: use virDomainPCIAddressIsMulti() to determine multifunction setting

If the multifunction attribute isn't set in the config for the device at function 0 of a slot used for multifunction, it would previously have been an error. This patch will instead automatically correct the omission (but only if it hasn't been set at all - if someone explicitly has

[libvirt] [PATCH v2 3/8] conf: eliminate repetitive code in virDomainPCIAddressGetNextSlot()

virDomainPCIAddressGetNextSlot() starts searching from the last allocated address and goes to the end of all the buses, then goes back to the first bus and searchs from there up to the starting point (in case any address has been freed since the last time an address was allocated. The loops for

[libvirt] [PATCH v2 7/8] conf: aggregate multiple devices on a slot when assigning PCI addresses

If a PCI device has VIR_PCI_CONNECT_AGGREGATE_SLOT set in its pciConnectFlags, then during address assignment we allow multiple instances of this type of device to be auto-assigned to multiple functions on the same device. A slot is used for aggregating multiple devices only if the first device

[libvirt] [PATCH v2 2/8] conf: eliminate concept of "reserveEntireSlot"

setting reserveEntireSlot really accomplishes nothing - instead of going to the trouble of computing the value for reserveEntireSlot and then possibly setting *all* functions of the slot as in-use, we can just set the in-use bit only for the specific function being used by a device. Later we will

[libvirt] [PATCH v2 5/8] conf: new function virDomainPCIAddressIsMulti()

This function iterates through all the devices in a domain to determine if the address it has been given is part of a "multifunction device" (i.e. multiple devices connected to different functions of the same slot). This implementation may seem a bit inefficient because it has to iterate through

[libvirt] [PATCH v6 08/17] qemu: assign nec-xhci (USB3) controller to a PCIe address when appropriate

The nec-usb-xhci device (which is a USB3 controller) has always presented itself as a PCI device when plugged into a legacy PCI slot, and a PCIe device when plugged into a PCIe slot, but libvirt has always auto-assigned it to a legacy PCI slot. This patch changes that behavior to auto-assign to a

[libvirt] [PATCH v6 12/17] [ACKED] qemu: don't force-add a dmi-to-pci-bridge just on principle

Now the a dmi-to-pci-bridge is automatically added just as it's needed (when a pci-bridge is being added), we no longer have any need to force-add one to every single Q35 domain. --- src/qemu/qemu_domain.c | 12 tests/qemuxml2argvdata/qemuxml2argv-pcie-root.args |

[libvirt] [PATCH v6 10/17] qemu: auto-add pcie-root-port/dmi-to-pci-bridge controllers as needed

Previously libvirt would only add pci-bridge devices automatically when an address was requested for a device that required a legacy PCI slot and none was available. This patch expands that support to dmi-to-pci-bridge (which is needed in order to add a pci-bridge on a machine with a pcie-root),

[libvirt] [PATCH v6 07/17] qemu: assign e1000e network devices to PCIe slots when appropriate

The e1000e is an emulated network device based on the Intel 82574, present in qemu 2.7.0 and later. Among other differences from the e1000, it presents itself as a PCIe device rather than legacy PCI. In order to get it assigned to a PCIe controller, this patch updates the flags setting for network

[libvirt] [PATCH v6 03/17] qemu: set/use info->pciConnectFlags when validating/assigning PCI addresses

Set pciConnectFlags in each device's DeviceInfo and then use those flags later when validating existing addresses in qemuDomainCollectPCIAddress() and when assigning new addresses with qemuDomainPCIAddressReserveNextAddr() (rather than scattering the logic about which devices need which type of

[libvirt] [PATCH v6 15/17] qemu: initially reserve one open pcie-root-port for hotplug

For machinetypes with a pci-root bus (all legacy PCI), libvirt will make a "fake" reservation for one extra slot prior to assigning addresses to unaddressed PCI endpoint devices in the domain. This will trigger auto-adding of a pci-bridge for the final device to be assigned an address *if that

[libvirt] [PATCH v6 02/17] qemu: new functions to calculate/set device pciConnectFlags

The lowest level function of this trio (qemuDomainDeviceCalculatePCIConnectFlags()) aims to be the single authority for the virDomainPCIConnectFlags to use for any given device using a particular arch/machinetype/qemu-binary. qemuDomainFillDevicePCIConnectFlags() sets info->pciConnectFlags in a

[libvirt] [PATCH v6 05/17] qemu: set pciConnectFlags to 0 instead of PCI|HOTPLUGGABLE if device isn't PCI

This patch cleans up the connect flags for certain types/models of devices that aren't PCI to return 0. In the future that may be used as an indicator to the caller about whether or not a device needs a PCI address. For now it's just ignored, except for in virDomainPCIAddressEnsureAddr() - called

[libvirt] [PATCH v6 16/17] qemu: propagate virQEMUDriver object to qemuDomainDeviceCalculatePCIConnectFlags

If libvirtd is running unprivileged, it is not able to read devices' PCI config data from sysfs, and qemuDomainDeviceCalculatePCIConnectFlags() will need to read the PCI config data in to positively determine whether or not a device is an Express device or a legacy PCI device. In order to avoid

[libvirt] [PATCH v6 17/17] qemu: assign vfio devices to PCIe addresses when appropriate

Although nearly all host devices that are assigned to guests using vfio ("" devices in libvirt) are physically PCI Express devices, until now libvirt's PCI address assignment has always assigned them addresses on legacy PCI controllers. This patch tries to assign them to an address on a PCIe

[libvirt] [PATCH v6 14/17] [ACKED] qemu: try to put ich9 sound device at 00:1B.0

Real Q35 hardware has an ICH9 chip that includes several integrated devices at particular addresses (see the file docs/q35-chipset.cfg in the qemu source). libvirt already attempts to put the first two sets of ich9 USB2 controllers it finds at 00:1D.* and 00:1A.* to match the real hardware. This

[libvirt] [PATCH v6 13/17] [ACKED] qemu: add a USB3 controller to Q35 domains by default

Previously we added a set of EHCI+UHCI controllers to Q35 machines to mimic real hardware as closely as possible, but recent discussions have pointed out that the nec-usb-xhci (USB3) controller is much more virtualization-friendly (uses less CPU), so this patch switches the default for Q35

[libvirt] [PATCH v6 04/17] qemu: set/use proper pciConnectFlags during hotplug

Before now, all the qemu hotplug functions assumed that all devices to be hotplugged were legacy PCI endpoint devices (VIR_PCI_CONNECT_TYPE_PCI_DEVICE). This worked out "okay", because all devices *are* legacy PCI endpoint devices on x86/440fx machinetypes, and hotplug didn't work properly on

[libvirt] [PATCH v6 01/17] qemu: new functions qemuDomainMachineHasPCI[e]Root()

These functions provide a simple one line method of learning if the current domain has a pci-root or pcie-root bus. --- src/qemu/qemu_domain.c | 30 ++ src/qemu/qemu_domain.h | 2 ++ 2 files changed, 32 insertions(+) diff --git a/src/qemu/qemu_domain.c

[libvirt] [PATCH v6 09/17] [ACKED] qemu: only force an available legacy-PCI slot on domains with pci-root

Andrea had the right idea when he disabled the "reserve an extra unused slot" bit for aarch64/virt. For *any* PCI Express-based machine, it is pointless since 1) an extra legacy-PCI slot can't be used for hotplug, since hotplug into legacy PCI slots doesn't work on PCI Express machinetypes, and 2)

[libvirt] [PATCH v6 00/17] Use more PCIe less legacy PCI

This is a rebase of v5 (, with the addition of patches 16 & 17, which detect the type of VFIO assigned devices and assign them to either an Express or a legacy PCI slot as appropriate, Laine Stump (17): qemu: new functions qemuDomainMachineHasPCI[e]Root() qemu: new functions to calculate/set

[libvirt] [PATCH v6 06/17] qemu: assign virtio devices to PCIe slot when appropriate

libvirt previously assigned nearly all devices to a "hotpluggable" legacy PCI slot even on machines with a PCIe root bus (and even though most such machines don't even support hotplug on legacy PCI slots!) Forcing all devices onto legacy PCI slots means that the domain will need a

[libvirt] [PATCH v6 11/17] [RFC] qemu: if pci-bridge is in PCIe config w/o dmi-to-pci-bridge, add it

I'm undecided if it is worthwhile to add this... Up until now it has been legal to have something like this in the xml: (for example, see the existing test case "usb-controller-default-q35"). This is handled in qemuDomainPCIAddressSetCreate() when it's adding in controllers to fill holes

Re: [libvirt] [PATCH] Unbreak rebuilding docs with release tarballs

On Mon, Nov 07, 2016 at 03:38:17PM +0100, Michal Privoznik wrote: > On 04.11.2016 19:08, Guido Günther wrote: > > Release tarballs ship the include/libvirt/libvirt-common.h. > > > > when srcdir != builddir we end up including libvirt-common.h twice: from > > $top_srcdir/include/libvirt-common.h

Re: [libvirt] [PATCH] loopback is not always just lo

On 11/07/2016 04:15 AM, Daniel P. Berrange wrote: On Mon, Nov 07, 2016 at 01:52:05AM -0500, Laine Stump wrote: On 11/06/2016 01:54 AM, Roman Bogorodskiy wrote: Daniel P. Berrange wrote: On Tue, Nov 01, 2016 at 06:15:59PM +0300, Pavel Timofeev wrote: On BSD family OSes

[libvirt] [PATCH 2/2] conf: List only online cpus for virsh emulatorpin

From: nitesh konkar Signed-off-by: Nitesh Konkar --- src/qemu/qemu_driver.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 38c8414..256d034 100644 ---

[libvirt] [PATCH 0/2] List only online cpus for vcpupin/emulatorpin when vcpu placement static

From: nitesh konkar Currently when the vcpu placement is static and cpuset is not specified, CPU Affinity shows 0.. CPUMAX. This patchset will result in display of only online CPU's under CPU Affinity. nitesh konkar (2): conf: List only online cpus under CPU

[libvirt] [PATCH 1/2] conf: List only online cpus for virsh vcpupin

From: nitesh konkar Signed-off-by: Nitesh Konkar --- src/conf/domain_conf.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index a233c0c..227b695 100644 ---

Re: [libvirt] [PATCH] qemu: fix one reboot scenario

On 07.11.2016 17:19, Michal Privoznik wrote: > On 03.11.2016 19:11, Maxim Nestratov wrote: >> Both qemuDomainReboot and qemuDomainShutdownFlags do the following if >> they were called to reboot: >> 1. use agent and call qemuAgentShutdown >> 2. then if the above function doesn't succeed, try

Re: [libvirt] [Qemu-devel] [PATCH v4 7/8] qmp: Support abstract classes on device-list-properties

On Mon, Nov 07, 2016 at 03:40:57PM +0100, Markus Armbruster wrote: > Eduardo Habkost writes: > > > On Mon, Nov 07, 2016 at 09:09:58AM +0100, Markus Armbruster wrote: > >> Eduardo Habkost writes: > >> > >> > On Fri, Nov 04, 2016 at 04:45:17PM +0100,

Re: [libvirt] [PATCH] spec: Run all make jobs in parallel

On Mon, 2016-11-07 at 16:32 +, Daniel P. Berrange wrote: > On Mon, Nov 07, 2016 at 05:30:53PM +0100, Andrea Bolognani wrote: > > Commit e8861f69714f changed our spec file to compile and run > > tests in parallel. That's a very good step forward, but why > > stop there? Let's run *all* make

Re: [libvirt] [PATCH] spec: Run all make jobs in parallel

On Mon, Nov 07, 2016 at 05:30:53PM +0100, Andrea Bolognani wrote: > Commit e8861f69714f changed our spec file to compile and run > tests in parallel. That's a very good step forward, but why > stop there? Let's run *all* make jobs in parallel and really > put those expensive cores to use! > > On

[libvirt] [PATCH] spec: Run all make jobs in parallel

Commit e8861f69714f changed our spec file to compile and run tests in parallel. That's a very good step forward, but why stop there? Let's run *all* make jobs in parallel and really put those expensive cores to use! On my laptop, this shaves ~10s off 'make rpm'. --- libvirt.spec.in | 4 ++-- 1

Re: [libvirt] [PATCH] qemu: fix one reboot scenario

On 03.11.2016 19:11, Maxim Nestratov wrote: > Both qemuDomainReboot and qemuDomainShutdownFlags do the following if > they were called to reboot: > 1. use agent and call qemuAgentShutdown > 2. then if the above function doesn't succeed, try qemuMonitorSystemPowerdown > > When the first step is

Re: [libvirt] [PATCH] Allow saving QEMU libvirt state to a pipe

On Mon, Nov 07, 2016 at 09:19:23AM -0600, Roy Keene wrote: > > > On 11/07/2016 03:27 AM, Peter Krempa wrote: > > On Fri, Nov 04, 2016 at 15:20:44 -0500, Roy Keene wrote: > >> All, > >> > >> Currently the "virsh save" command opens a file to save a domain's > >> XML and memory state, does

Re: [libvirt] [PATCH] Allow saving QEMU libvirt state to a pipe

On 11/07/2016 03:27 AM, Peter Krempa wrote: On Fri, Nov 04, 2016 at 15:20:44 -0500, Roy Keene wrote: All, Currently the "virsh save" command opens a file to save a domain's XML and memory state, does the save, and then re-opens the file to simulate seeking to the beginning to update

Re: [libvirt] [Qemu-devel] [PATCH v4 7/8] qmp: Support abstract classes on device-list-properties

Eduardo Habkost writes: > On Mon, Nov 07, 2016 at 09:09:58AM +0100, Markus Armbruster wrote: >> Eduardo Habkost writes: >> >> > On Fri, Nov 04, 2016 at 04:45:17PM +0100, Markus Armbruster wrote: >> >> Eduardo Habkost writes: >> >>

Re: [libvirt] [PATCH] Unbreak rebuilding docs with release tarballs

On 04.11.2016 19:08, Guido Günther wrote: > Release tarballs ship the include/libvirt/libvirt-common.h. > > when srcdir != builddir we end up including libvirt-common.h twice: from > $top_srcdir/include/libvirt-common.h and from > $builddir/include/libvirt-common.h leading to > > function

Re: [libvirt] qemu: domain notification for serial channel changes

On Mon, Nov 07, 2016 at 03:05:24PM +0100, Peter Krempa wrote: > On Mon, Nov 07, 2016 at 08:56:58 -0500, Matt Broadstone wrote: > > On Mon, Nov 7, 2016 at 8:52 AM, Matt Broadstone wrote: > > > On Mon, Nov 7, 2016 at 8:35 AM, Peter Krempa wrote: > > >> On

Re: [libvirt] [PATCH v2] bhyve: add e1000 nic support

Laine Stump wrote: > On 11/06/2016 01:09 AM, Roman Bogorodskiy wrote: > > Recently e1000 NIC support was added to bhyve; implement that in > > the bhyve driver: > > > > - Add capability check by analyzing output of the 'bhyve -s 0,e1000' > > command > > - Modify bhyveBuildNetArgStr() to

[libvirt] [PATCH v3 1/2] bhyve: Separate out checks from virBhyveProbeCaps

From: Fabian Freyer At the moment this is just one check, but separating this out into a separate function makes checks more modular, allowing for more readable code once more checks are added. This also makes checks more easily testable. Signed-off-by: Roman

[libvirt] [PATCH v3 0/2] bhyve: add e1000 nic support

Changes since v2: - Include missing Fabian's probes patch Changes since v1: - Fix indentation - Don't leak nic_model in bhyveBuildNetArgStr, and actually convert it to use 'goto out' to the clean up routine instead of explicit calls to VIR_FREE for every case - Add support for e1000

[libvirt] [PATCH v3 2/2] bhyve: add e1000 nic support

Recently e1000 NIC support was added to bhyve; implement that in the bhyve driver: - Add capability check by analyzing output of the 'bhyve -s 0,e1000' command - Modify bhyveBuildNetArgStr() to support e1000 and also pass virConnectPtr so it could call bhyveDriverGetCaps() to check if

Re: [libvirt] qemu: domain notification for serial channel changes

On Mon, Nov 07, 2016 at 08:56:58 -0500, Matt Broadstone wrote: > On Mon, Nov 7, 2016 at 8:52 AM, Matt Broadstone wrote: > > On Mon, Nov 7, 2016 at 8:35 AM, Peter Krempa wrote: > >> On Mon, Nov 07, 2016 at 13:31:30 +, Daniel Berrange wrote: > >>> On

Re: [libvirt] qemu: domain notification for serial channel changes

On Mon, Nov 7, 2016 at 8:52 AM, Matt Broadstone wrote: > On Mon, Nov 7, 2016 at 8:35 AM, Peter Krempa wrote: >> On Mon, Nov 07, 2016 at 13:31:30 +, Daniel Berrange wrote: >>> On Mon, Nov 07, 2016 at 08:22:59AM -0500, Matt Broadstone wrote: >>> > Hi,

Re: [libvirt] qemu: domain notification for serial channel changes

On Mon, Nov 7, 2016 at 8:35 AM, Peter Krempa wrote: > On Mon, Nov 07, 2016 at 13:31:30 +, Daniel Berrange wrote: >> On Mon, Nov 07, 2016 at 08:22:59AM -0500, Matt Broadstone wrote: >> > Hi, >> > >> > I was in the process of implementing a custom qemu agent which >> >

Re: [libvirt] qemu: domain notification for serial channel changes

On Mon, Nov 07, 2016 at 13:31:30 +, Daniel Berrange wrote: > On Mon, Nov 07, 2016 at 08:22:59AM -0500, Matt Broadstone wrote: > > Hi, > > > > I was in the process of implementing a custom qemu agent which > > communicates over virtio-serial channels, when I noticed that the only > > way to

Re: [libvirt] qemu: domain notification for serial channel changes

On Mon, Nov 07, 2016 at 08:22:59AM -0500, Matt Broadstone wrote: > Hi, > > I was in the process of implementing a custom qemu agent which > communicates over virtio-serial channels, when I noticed that the only > way to receive channel state change notifications was to poll the > domstatus XML

[libvirt] qemu: domain notification for serial channel changes

Hi, I was in the process of implementing a custom qemu agent which communicates over virtio-serial channels, when I noticed that the only way to receive channel state change notifications was to poll the domstatus XML file. There does seem to be code in libvirt to monitor for serial change events

Re: [libvirt] [Qemu-devel] [PATCH v4 7/8] qmp: Support abstract classes on device-list-properties

On Mon, Nov 07, 2016 at 09:09:58AM +0100, Markus Armbruster wrote: > Eduardo Habkost writes: > > > On Fri, Nov 04, 2016 at 04:45:17PM +0100, Markus Armbruster wrote: > >> Eduardo Habkost writes: > >> > >> > (CCing libvirt people, as I forgot to CC

Re: [libvirt] [PATCH 00/17] Redo website layout and branding

On Mon, Nov 07, 2016 at 01:21:45PM +0100, Kashyap Chamarthy wrote: > On Fri, Nov 04, 2016 at 10:07:50AM +0100, Michal Privoznik wrote: > > On 03.11.2016 17:13, Daniel P. Berrange wrote: > > > On Thu, Nov 03, 2016 at 03:25:55PM +, Daniel P. Berrange wrote: > > >> > > >> The bluriness is caused

Re: [libvirt] [PATCH 00/17] Redo website layout and branding

On Fri, Nov 04, 2016 at 10:07:50AM +0100, Michal Privoznik wrote: > On 03.11.2016 17:13, Daniel P. Berrange wrote: > > On Thu, Nov 03, 2016 at 03:25:55PM +, Daniel P. Berrange wrote: > >> > >> The bluriness is caused by inkscape anti-aliasing the font when > >> exporting the SVG to PNG. I'll

Re: [libvirt] How to make udev not touch my device?

On Mon, Nov 07, 2016 at 01:11:14PM +0100, Michal Privoznik wrote: > On 07.11.2016 10:17, Daniel P. Berrange wrote: > > On Fri, Nov 04, 2016 at 08:47:34AM +0100, Michal Privoznik wrote: > >> Hey udev developers, > >> > >> I'm a libvirt developer and I've been facing an interesting issue > >>

Re: [libvirt] How to make udev not touch my device?

On 07.11.2016 10:17, Daniel P. Berrange wrote: > On Fri, Nov 04, 2016 at 08:47:34AM +0100, Michal Privoznik wrote: >> Hey udev developers, >> >> I'm a libvirt developer and I've been facing an interesting issue >> recently. Libvirt is a library for managing virtual machines and as such >> allows

Re: [libvirt] [PATCH 00/17] Redo website layout and branding

On Fri, Nov 04, 2016 at 02:18:21PM +, Daniel P. Berrange wrote: > On Fri, Nov 04, 2016 at 09:05:49AM -0500, Eric Blake wrote: > > On 10/31/2016 07:41 AM, Daniel P. Berrange wrote: > > > The libvirt logo used a specific font with angled tops > > > to letters like "l", "b" and "t" - this is the

Re: [libvirt] [PATCH 04/17] docs: add footer to all pages

On Mon, Nov 07, 2016 at 12:09:56PM +0100, Peter Krempa wrote: > On Fri, Nov 04, 2016 at 13:55:31 +, Daniel Berrange wrote: > > On Fri, Nov 04, 2016 at 02:19:22PM +0100, Ján Tomko wrote: > > > On Mon, Oct 31, 2016 at 12:41:45PM +, Daniel P. Berrange wrote: > > > > Add a footer to all pages

Re: [libvirt] [PATCH 12/17] docs: expand downloads page to cover all modules

On Fri, Nov 04, 2016 at 02:05:42PM +0100, Ján Tomko wrote: > On Mon, Oct 31, 2016 at 12:41:53PM +, Daniel P. Berrange wrote: > > Previously the download page only covered the main libvirt > > module and the app dev guide. Expand it to provide direct > > links to all artifacts published by the

Re: [libvirt] [PATCH 04/17] docs: add footer to all pages

On Fri, Nov 04, 2016 at 13:55:31 +, Daniel Berrange wrote: > On Fri, Nov 04, 2016 at 02:19:22PM +0100, Ján Tomko wrote: > > On Mon, Oct 31, 2016 at 12:41:45PM +, Daniel P. Berrange wrote: > > > Add a footer to all pages containing a blurb about the > > > code of conduct, and links to

Re: [libvirt] [PATCH 06/17] docs: add page describing contribution to libvirt

On Fri, Nov 04, 2016 at 01:31:11PM +0100, Ján Tomko wrote: > On Mon, Oct 31, 2016 at 12:41:47PM +, Daniel P. Berrange wrote: > > Add a page that describes what contributions libvirt is > > looking for and how to get involved. > > > > Neat. > > > Signed-off-by: Daniel P. Berrange

  1   2   >