[libvirt] 答复: Re: 答复: Re: [PATCH] qemu: change the name of tap device for a tapand bridge network

i explain the case again. the net config xml of two vms is : ＜interface type='bridge'＞ ＜mac address='fa:16:3e:e1:b2:01'/＞ ＜source bridge='br100'/＞ ＜model type='virtio'/＞ ＜driver name='vhost'/＞ ＜virtualport type='openvswitch'/＞ ＜/interface＞ of cause the

Re: [libvirt] 答复: Re: [PATCH] qemu: change the name of tap device for a tapand bridge network

I'll try and explain the steps/situation where this is an issue. Say for example you have your router/dhcpd done inside a VM guest - you use macvtap devices and vlans off the hypervisor to get the traffic in and out (WAN and LAN). And you want the LAN side to provide connectivity to the host as

Re: [libvirt] 答复: Re: [PATCH] qemu: change the name of tap device for a tapand bridge network

On 04/28/2017 07:23 PM, Joel Wirāmu Pauling wrote: > Possibly related I notice race conditions caused by vnic never getting > loaded if an existing bridge is already up (by OS init scripts etc) and > stopping VM's from getting started. Can you explain this more exactly? In particular, by "vnic"

Re: [libvirt] 答复: Re: [PATCH] qemu: change the name of tap device for a tapand bridge network

Possibly related I notice race conditions caused by vnic never getting loaded if an existing bridge is already up (by OS init scripts etc) and stopping VM's from getting started. Often this is behavior you want ; i.e having Host Hypervisor NIC's added and up before libvirtd sets up it's

[libvirt] 答复: Re: [PATCH] qemu: change the name of tap device for a tapand bridge network

＞On Fri, Apr 28, 2017 at 05:23:19PM +0800, ZhiPeng Lu wrote:＞＞ Creating tap device and adding the device to bridge are not atomic operation.＞＞ Similarly deleting tap device and removing it from bridge are not atomic operation.＞＞The Problem occurs when two vms start and shutdown. When one vm

[libvirt] Entering freeze for libvirt-3.3.0

As planned, I tagged RC1 in git and pushed signed tarball and rpms to the usual place: ftp://libvirt.org/libvirt/ Seems to work in my limited testing, https://ci.centos.org/view/libvirt/ seems mostly clean and happy, but please give it some testing ! Assuming things go well, I think I

Re: [libvirt] Making panic great again

On Fri, Apr 28, 2017 at 1:46 AM, Daniel P. Berrange wrote: > With the watchdog we have a much wider set of actions that we can > instruct QEMU to do: > > 'reset' — default, forcefully reset the guest > 'shutdown' — gracefully shutdown the guest (not recommended) >

Re: [libvirt] Making panic great again

On Thu, Apr 27, 2017 at 11:43 PM, Martin Kletzander wrote: > I'm trying to understand the situation. So you have a guest that > handles crashes itself (like kdump, let's say), but on_crash options are > not enough for you: > > - preserve is bad because the guest is not

Re: [libvirt] [PATCHv3 5/6] conf: add caching attribute to iommu device

On 04/26/2017 04:29 AM, Ján Tomko wrote: > Add a new attribute to control the caching mode. > > https://bugzilla.redhat.com/show_bug.cgi?id=1427005 > --- > docs/formatdomain.html.in | 9 > docs/schemas/domaincommon.rng | 5 +++ >

[libvirt] [PATCH] docs: Add details about panic device behavior

When a guest triggers the panic device, QEMU pauses the guest, and libvirt takes the action specified by on_crash. This can interfere with the guest's own crash handling actions (like writing a dump file and rebooting itself) if the guest triggers the panic device first (as Windows does via the

Re: [libvirt] [PATCHv3 3/6] conf: add to

On 04/26/2017 04:29 AM, Ján Tomko wrote: > Add a new attribute to control interrupt remapping. > > https://bugzilla.redhat.com/show_bug.cgi?id=1427005 > --- > docs/formatdomain.html.in | 22 - > docs/schemas/domaincommon.rng | 9 +

Re: [libvirt] [PATCHv3 1/6] conf: add to

On 04/26/2017 04:29 AM, Ján Tomko wrote: > Add a new element with a mode attribute. > > Possible values are off, split or on. > > https://bugzilla.redhat.com/show_bug.cgi?id=1427005 > --- > docs/formatdomain.html.in | 10 +++ > docs/schemas/domaincommon.rng

Re: [libvirt] [PATCH] qemu: change the name of tap device for a tap and bridge network

On 04/28/2017 05:33 AM, Daniel P. Berrange wrote: > On Fri, Apr 28, 2017 at 05:23:19PM +0800, ZhiPeng Lu wrote: >> Creating tap device and adding the device to bridge are not atomic operation. >> Similarly deleting tap device and removing it from bridge are not atomic >> operation. >> The Problem

Re: [libvirt] [PATCH 0/2] Add support for some useful vim plugins

On Fri, 2017-04-28 at 15:52 +0100, Daniel P. Berrange wrote: > Ok, well perhaps just put a quick note in HACKING that we ship these > config files, and provide a link to the upstream plugin which describes > it further. I couldn't find an existing section where this would fit, so I created a new

[libvirt] [PATCH 3/2] HACKING: Document developer tooling

Advertise some of the useful developer tooling libvirt integrates with out of the box. --- HACKING | 13 + docs/hacking.html.in | 20 2 files changed, 33 insertions(+) diff --git a/HACKING b/HACKING index 74d1068..b78a9ae 100644 --- a/HACKING +++

Re: [libvirt] [PATCH 0/2] Add support for some useful vim plugins

On Fri, Apr 28, 2017 at 04:38:18PM +0200, Andrea Bolognani wrote: > On Fri, 2017-04-28 at 15:24 +0100, Daniel P. Berrange wrote: > > So presumably this requires users to have libclang installed > > on their system. Perhaps worth a note in the HACKING file > > about prerequisites and any VIM setup

Re: [libvirt] [PATCH 0/2] Add support for some useful vim plugins

On Fri, 2017-04-28 at 16:38 +0200, Andrea Bolognani wrote: > The upside is that users who have already set up the > plugins won't need to do anything specific for them to > work with libvirt, they will just pick up the respective > configuration files automatically. And, it goes without saying,

Re: [libvirt] [PATCH 0/2] Add support for some useful vim plugins

On Fri, 2017-04-28 at 15:24 +0100, Daniel P. Berrange wrote: > So presumably this requires users to have libclang installed > on their system. Perhaps worth a note in the HACKING file > about prerequisites and any VIM setup (if not 100% automatic) Setting up the plugins themselves is non-trivial,

[libvirt] [PATCH] qemu: Don't reset "events" migration capability

When creating v3.2.0-77-g8be3ccd04 commit, I completely forgot that one migration capability is very special. It's the "events" capability which tells QEMU to report "MIGRATION" events. Since libvirt always wants the events, it is enabled in qemuConnectMonitor and the rest of the code should not

Re: [libvirt] [PATCH 0/2] Add support for some useful vim plugins

On Fri, Apr 28, 2017 at 04:20:48PM +0200, Andrea Bolognani wrote: > libclang can be integrated into vim in pretty useful > ways, notably to provide semantic syntax highlighting > and code completion. So presumably this requires users to have libclang installed on their system. Perhaps worth a

[libvirt] [PATCH 2/2] Add YouCompleteMe support

YouCompleteMe[1] is a vim plugin that implements semantic code completion using libclang. For non-trivial projects such as libvirt, the plugin needs some help figuring out where to find the various header files: generate its configuration file at configure time so that the plugin works out of the

[libvirt] [PATCH 0/2] Add support for some useful vim plugins

libclang can be integrated into vim in pretty useful ways, notably to provide semantic syntax highlighting and code completion. This series enables basic support for both (through the color_coded and YouCompleteMe plugin respectively) by creating the required per-project configuration files

[libvirt] [PATCH 1/2] Add color_coded support

color_coded[1] is a vim plugin that implements semantic syntax highlighting using libclang. For non-trivial projects such as libvirt, the plugin needs some help figuring out where to find the various header files: generate its configuration file at configure time so that the plugin works out of

Re: [libvirt] [PATCH] news: Document libxl nested HVM support

On 04/28/2017 07:42 AM, Pavel Hrdina wrote: On Thu, Apr 27, 2017 at 03:24:24PM -0600, Jim Fehlig wrote: Nested HVM support in the libxl driver is a news-worthy improvement for libvirt 3.3.0. Signed-off-by: Jim Fehlig --- docs/news.xml | 11 +++ 1 file changed, 11

Re: [libvirt] [PATCH] news: Document libxl nested HVM support

On Thu, 2017-04-27 at 15:24 -0600, Jim Fehlig wrote: > Nested HVM support in the libxl driver is a news-worthy > improvement for libvirt 3.3.0. > > Signed-off-by: Jim Fehlig > --- > docs/news.xml | 11 +++ > 1 file changed, 11 insertions(+) ACK -- Andrea Bolognani /

Re: [libvirt] [PATCH] news: Document libxl nested HVM support

On Thu, Apr 27, 2017 at 03:24:24PM -0600, Jim Fehlig wrote: > Nested HVM support in the libxl driver is a news-worthy > improvement for libvirt 3.3.0. > > Signed-off-by: Jim Fehlig > --- > docs/news.xml | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git

Re: [libvirt] [PATCH] news: Document libxl nested HVM support

Anyone have time to take a quick look at this news entry? AFAICT, additions to news are reviewed and not considered trivial to push. Regards, Jim On 04/27/2017 03:24 PM, Jim Fehlig wrote: Nested HVM support in the libxl driver is a news-worthy improvement for libvirt 3.3.0. Signed-off-by:

Re: [libvirt] [PATCH v3 4/8] tests: Add missing cache data for vircaps2xmltest

On Tue, Apr 25, 2017 at 01:10:28PM +0200, Martin Kletzander wrote: > Commit a0fdd2f6f9a0cc77ae285c289e2c16d314b6a907 added some data from > the system but forgot 3 files for each cache. Again, to me, the content of this patch is white noise. But I guess we want to test stuff, don't we... ACK

Re: [libvirt] [PATCH v3 3/8] tests: Test vircaps2xmldata XMLs in virschematest

On Tue, Apr 25, 2017 at 01:10:27PM +0200, Martin Kletzander wrote: > Signed-off-by: Martin Kletzander > --- > tests/virschematest.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/tests/virschematest.c b/tests/virschematest.c > index

Re: [libvirt] [PATCH v3 2/8] util: Remove virsysfs and instead enhance virFileReadValue* functions

On Tue, Apr 25, 2017 at 01:10:26PM +0200, Martin Kletzander wrote: > It is no longer needed thanks to the great virfilemock.c. And this s/mock/wrapper > > -return 0; > + > +/* Arbitrarily sized number, feel free to change, but the function should be > + * used for small, interface-like

Re: [libvirt] [PATCH v3 1/8] tests: Add virfilewrapper -- the new super "mock"

On Tue, Apr 25, 2017 at 01:10:25PM +0200, Martin Kletzander wrote: > This mock (which is actually not mock at all, see later) can redirect > all accesses to a path into another path. There is no need to > create mocks for particular directories, you just create a directory > with all the data a

Re: [libvirt] [PATCH RFC V2] RFC: Reimplement cache allocation for a VM

On Fri, Apr 14, 2017 at 06:01:46PM +0800, Eli Qiao wrote: This is a RFC patch for the reimplement of `support cache tune(CAT) in libvirt`[1]. I searched for 'lock' in this mail and found nothing... This patch defines some structs to represent data struct in linux resctrl fs which will be

Re: [libvirt] [PATCH v2 07/38] iohelper: Remove unused mode

On 04/28/2017 07:42 AM, Michal Privoznik wrote: > On 04/27/2017 09:47 PM, John Ferlan wrote: >> >> >> On 04/20/2017 06:01 AM, Michal Privoznik wrote: >>> After 1eb6647979f8c nobody calls the iohelper with 6 arguments. >>> Everybody uses the other mode. Well, the only user of iohelper >>> after

Re: [libvirt] [PATCH v2 07/38] iohelper: Remove unused mode

On 04/27/2017 09:47 PM, John Ferlan wrote: > > > On 04/20/2017 06:01 AM, Michal Privoznik wrote: >> After 1eb6647979f8c nobody calls the iohelper with 6 arguments. >> Everybody uses the other mode. Well, the only user of iohelper >> after the previous commit is virFileWrapperFd really. > > Are

Re: [libvirt] [PATCH v2 06/38] virfdstream: Use messages instead of pipe

On 04/27/2017 07:48 PM, Daniel P. Berrange wrote: > On Thu, Apr 20, 2017 at 12:01:35PM +0200, Michal Privoznik wrote: >> One big downside of using the pipe to transfer the data is that >> we can really transfer just bare data. No metadata can be carried >> through unless some formatted messages

Re: [libvirt] [PATCH] conf: format only relevant attributes for graphics based on listen type

On 04/26/2017 06:50 AM, Pavel Hrdina wrote: > This patch changes following output: > > ... > > > > ... > > into this output: > > ... > > > > ... > > Signed-off-by: Pavel Hrdina > --- > src/conf/domain_conf.c | 12

[libvirt] [PATCH 3/5] qemuDomainCreateDeviceRecursive: Don't try to create devices under preserved mount points

While the code allows devices to already be there (by some miracle), we shouldn't try to create devices that don't belong to us. For instance, we shouldn't try to create /dev/shm/file because /dev/shm is a mount point that is preserved. Therefore if a file is created there from an outside (e.g. by

[libvirt] [PATCH 2/5] qemuDomainCreateDeviceRecursive: pass a structure instead of bare path

Currently, all we need to do in qemuDomainCreateDeviceRecursive() is to take given @device, get all kinds of info on it (major & minor numbers, owner, seclabels) and create its copy at a temporary location @path (usually /var/run/libvirt/qemu/$domName.dev), if @device live under /dev. This is,

[libvirt] [PATCH 5/5] qemuDomainDetachDeviceUnlink: Don't unlink files we haven't created

Even though there are several checks before calling this function and for some scenarios we don't call it at all (e.g. on disk hot unplug), it may be possible to sneak in some weird files (e.g. if domain would have RNG with /dev/shm/some_file as its backend). No matter how improbable, we shouldn't

[libvirt] [PATCH 0/5] qemu: Couple of namespace fixes

It was brought to my attention on IRC by Cedric that there's a bug in our namespace code. Namely, if a disk has say /dev/shm/blah source. For more detailed description see the first patch. The rest is just subsequent fixes. Michal Privoznik (5): qemuDomainBuildNamespace: Move /dev/* mountpoints

[libvirt] [PATCH 1/5] qemuDomainBuildNamespace: Move /dev/* mountpoints later

When setting up mount namespace for a qemu domain the following steps are executed: 1) get list of mountpoints under /dev/ 2) move them to /var/run/libvirt/qemu/$domName.ext 3) start constructing new device tree under /var/run/libvirt/qemu/$domName.dev 4) move the mountpoint of the new device

[libvirt] [PATCH 4/5] qemuDomainAttachDeviceMknodRecursive: Don't try to create devices under preserved mount points

Just like in previous commit, this fixes the same issue for hotplug. Signed-off-by: Michal Privoznik --- src/qemu/qemu_domain.c | 112 ++--- 1 file changed, 97 insertions(+), 15 deletions(-) diff --git a/src/qemu/qemu_domain.c

[libvirt] [PATCH v2 3/4] conf: Add support for modifying ssl validation for https/ftps disks

To allow turning of verification of SSL cerificates add a new element to the disk source XML which will allow configuring the validation process using the 'verify' attribute. --- docs/formatdomain.html.in | 9 + docs/schemas/domaincommon.rng |

[libvirt] [PATCH v2 1/4] qemu: capabilities: Add capability for the sslverify curl driver option

The option allows setting verifiaction of the SSL certificate for HTTPS and FTPS based disks. --- src/qemu/qemu_capabilities.c | 2 ++ src/qemu/qemu_capabilities.h | 1 + tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml | 1 + 3 files changed, 4

[libvirt] [PATCH v2 2/4] conf: Use only one temporary string in virDomainDiskSourceParse

--- src/conf/domain_conf.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 5a736c853..c40a5a7a6 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -7526,7 +7526,7 @@

[libvirt] [PATCH v2 4/4] qemu: command: Implement ssl verification configuration

Allow disabling of SSL certificate validation for HTTPS and FTPS drives in qemu. --- src/qemu/qemu_command.c| 22 +++-- .../qemuxml2argv-disk-drive-network-http.args | 37 +++ .../qemuxml2argv-disk-drive-network-http.xml | 52

[libvirt] [PATCH v2 0/4] qemu: Allow setting sslverify option

This is a rebased version now that the support was postponed. Peter Krempa (4): qemu: capabilities: Add capability for the sslverify curl driver option conf: Use only one temporary string in virDomainDiskSourceParse conf: Add support for modifying ssl validation for https/ftps disks

Re: [libvirt] [PATCH] qemu: change the name of tap device for a tap and bridge network

On Fri, Apr 28, 2017 at 05:23:19PM +0800, ZhiPeng Lu wrote: > Creating tap device and adding the device to bridge are not atomic operation. > Similarly deleting tap device and removing it from bridge are not atomic > operation. > The Problem occurs when two vms start and shutdown. When one vm

[libvirt] [PATCH] qemu: change the name of tap device for a tap and bridge network

Creating tap device and adding the device to bridge are not atomic operation. Similarly deleting tap device and removing it from bridge are not atomic operation. The Problem occurs when two vms start and shutdown. When one vm with the nic named "vnet0" stopping, it deleted tap device but not

Re: [libvirt] [PATCH v2 0/3] conf: don't ignore for macvtap interfaces

On Tue, Apr 25, 2017 at 02:50:34PM -0400, Laine Stump wrote: The parser had been clearing out *all* suggested device names for type='direct' (aka macvtap) interfaces. All of the code implementing macvtap allows for a user-specified device name, so we should allow it. In the case that an

Re: [libvirt] [PATCH v2 1/3] util: make macvtap/macvlan generated name #defines available to other files

On Tue, Apr 25, 2017 at 02:50:35PM -0400, Laine Stump wrote: MACVTAP_NAME_PREFIX and MACVLAN_NAME_PREFIX could be useful to other files if they were defined in virnetdevmacvlan.h instead of virnetdevmacvlan.c, so do that (while slightly renaming them and also adding yet another #define that

Re: [libvirt] Making panic great again

On Fri, Apr 28, 2017 at 08:43:30AM +0200, Martin Kletzander wrote: > On Thu, Apr 27, 2017 at 05:34:21PM -0700, Ed Swierk wrote: > > The panic device is currently documented as a way for "libvirt to receive > > panic notification from a QEMU guest". > > > > This is true, but not the whole story.

Re: [libvirt] [PATCH v2 0/5] add support for qemu-xhci USB controller

On Fri, Apr 28, 2017 at 10:36:06AM +0200, Andrea Bolognani wrote: > On Thu, 2017-04-27 at 20:47 +0200, Andrea Bolognani wrote: > > > Pavel Hrdina (5): > > >qemu: change the logic of setting default USB controller > > >qemu: use nec-usb-xhci as a default controller for aarch64 if > > >  

Re: [libvirt] [PATCH v2 0/5] add support for qemu-xhci USB controller

On Thu, 2017-04-27 at 20:47 +0200, Andrea Bolognani wrote: > > Pavel Hrdina (5): > >qemu: change the logic of setting default USB controller > >qemu: use nec-usb-xhci as a default controller for aarch64 if > >  available > >qemu: introduce QEMU_CAPS_DEVICE_QEMU_XHCI > >qemu:

Re: [libvirt] [PATCH v2 1/5] qemu: change the logic of setting default USB controller

On Thu, 2017-04-27 at 20:58 +0200, Pavel Hrdina wrote: > The issue with original code is that the if else-if else condition > is not consistent. >  > The first if checks S390 and address type together, however the second > else-if checks only for PPC64, the capability checks are inside that block.

Re: [libvirt] [PATCH v2 4/5] qemu: add support for qemu-xhci USB controller

On Fri, Apr 28, 2017 at 10:07:43AM +0200, Andrea Bolognani wrote: > On Thu, 2017-04-27 at 20:45 +0200, Pavel Hrdina wrote: > > > > @@ -1416,6 +1416,10 @@ mymain(void) > > > >   DO_TEST_PARSE_ERROR("usb-controller-xhci-limit", > > > >   QEMU_CAPS_CHARDEV, QEMU_CAPS_NODEFCONFIG, > >

Re: [libvirt] [PATCH v2 4/5] qemu: add support for qemu-xhci USB controller

On Thu, 2017-04-27 at 20:45 +0200, Pavel Hrdina wrote: > > > @@ -1416,6 +1416,10 @@ mymain(void) > > >   DO_TEST_PARSE_ERROR("usb-controller-xhci-limit", > > >   QEMU_CAPS_CHARDEV, QEMU_CAPS_NODEFCONFIG, > > >QEMU_CAPS_PIIX3_USB_UHCI, > > >   QEMU_CAPS_NEC_USB_XHCI,

Re: [libvirt] Making panic great again

On 04/28/2017 02:34 AM, Ed Swierk wrote: > The panic device is currently documented as a way for "libvirt to receive > panic notification from a QEMU guest". > > This is true, but not the whole story. When a guest triggers the panic > device, QEMU pauses the guest, and libvirt takes the action

[libvirt] [PATCH 0/2] Fix daemon crash caused by virHostdevUpdateActiveMediatedDevices

Erik Skultety (2): util: mdev: Use a local variable instead of an invalid pointer reference mdev: Fix daemon crash on domain shutdown after reconnect src/util/virhostdev.c | 4 ++-- src/util/virmdev.c| 18 +++--- src/util/virmdev.h| 2 +- 3 files changed, 14

[libvirt] [PATCH 2/2] mdev: Fix daemon crash on domain shutdown after reconnect

The problem resides in virHostdevUpdateActiveMediatedDevices which gets called during qemuProcessReconnect. The issue here is that virMediatedDeviceListAdd takes a pointer to the item to be added to the list to which VIR_APPEND_ELEMENT is used, which also clears the pointer. However, in this case

[libvirt] [PATCH 1/2] util: mdev: Use a local variable instead of an invalid pointer reference

virMediatedDeviceListAdd calls VIR_APPEND_ELEMENT which normally clears the element to be added, thus the pointer must not be used afterwards, but because the pointer here is passed by value, what gets cleared is a copy of the original pointer that got created on the stack automatically when

Re: [libvirt] Making panic great again

On Thu, Apr 27, 2017 at 05:34:21PM -0700, Ed Swierk wrote: The panic device is currently documented as a way for "libvirt to receive panic notification from a QEMU guest". This is true, but not the whole story. When a guest triggers the panic device, QEMU pauses the guest, and libvirt takes the