On Mon, Feb 18, 2019 at 15:50:52 -0600, Eric Blake wrote:
> On 2/18/19 10:34 AM, Peter Krempa wrote:
[...]
> > In the ideal world of snapshots when deletion/revertion was implemented
> > we'd never expose the virDomainBlockCommit and virDomainBlockPull APIs
> > including the multi-use backdoor
On 2/18/19 12:27 PM, Vladimir Sementsov-Ogievskiy wrote:
> 14.02.2019 2:23, John Snow wrote:
>> These mean the same thing now. Unify them and rename the merged call
>> bdrv_dirty_bitmap_busy to indicate semantically what we are describing,
>> as well as help disambiguate from the various
dnsmasq documentation says that the *IPv4* prefix/network
address/broadcast address sent to dhcp clients will be automatically
determined by dnsmasq by looking at the interface it's listening on,
so the original libvirt code did not add a netmask to the dnsmasq
commandline (or later, the dnsmasq
I sent V1 of this patch way back in October:
https://www.redhat.com/archives/libvir-list/2018-October/msg00889.html
but then self-NACKed it because I had written the patch to add the
network prefix to dhcp-range, but IPv4 requires the netmask rather
than range. Unfortunately, when I modified
This fixes a bug that has been present since the original version of
the function was pushed in commit 1ab80f3 on Nov. 26 2010 (by me). The
virSocketAddr::len was not being set.
Apparently until now we were always calling
virSocketAddrPrefixToNetmask() with a virSocketAddr object that was
already
On 2/18/19 11:39 AM, Vladimir Sementsov-Ogievskiy wrote:
> 14.02.2019 2:23, John Snow wrote:
>> Currently, enabled means something like "the status of the bitmap
>> is ACTIVE." After this patch, it should mean exclusively: "This
>> bitmap is recording guest writes, and is allowed to do so."
>>
On 2/8/19 11:51 AM, Andrea Bolognani wrote:
> Andrea Bolognani (5):
> jenkins: Move all Jenkins-related files
> README: Add short overview of the repository
> guests: Fix a small issue in README
> jenkins: Fix a couple small issues in README
> jenkins: Add YAML start of document
On 2/18/19 8:57 AM, Vladimir Sementsov-Ogievskiy wrote:
> 14.02.2019 2:23, John Snow wrote:
>> "Frozen" was a good description a long time ago, but it isn't adequate now.
>> Rename the frozen predicate to has_successor to make the semantics of the
>> predicate more clear to outside callers.
>>
On 2/18/19 12:39 PM, Vladimir Sementsov-Ogievskiy wrote:
> 14.02.2019 2:23, John Snow wrote:
>> Simply move the big status enum comment block to above the status
>> function, and document it as being deprecated. The whole confusing
>> block can get deleted in three releases time.
>>
>>
This method has the same idea of the method to parse IPv{4,6} data.
The method lxcNetworkParseDataInit() is responsible to initialize
network settings outside handler.
Signed-off-by: Julio Faracco
---
src/lxc/lxc_native.c | 56 +---
1 file changed, 32
The new method called lxcNetworkParseDataIPs() is responsible to handle
IPv{4,6} settings now. The idea is let lxcNetworkWalkCallback() method
handle all entries related to network definition only.
Signed-off-by: Julio Faracco
---
src/lxc/lxc_native.c | 65
This series has a lots of cleanups to prepare lxc to handle network
settings for verion 3.0 or higher. The new version is considering
network indexes to define network interfaces. i.e.: "lxc.net.X.".
As we need modular structures to support both versions, this method
needs a cleanup before
This commit removes the full network entry setting: "lxc.network.X" to
type only. Like "type", "name", "flags", etc. So, here no matter if the
settings is "lxc.network.X" or "lxc.net.X.Y".
Signed-off-by: Julio Faracco
---
src/lxc/lxc_native.c | 30 +++---
1 file changed,
This new method is responsible to verify is the settings correspond to
network entry. Right now, it is only verifying "lxc.network.", but in
the future, it can be used to verify "lxc.net.X." too. Any other case
would be rejected.
On the other hand, the idea here is working only with types. If we
14.02.2019 2:23, John Snow wrote:
> Simply move the big status enum comment block to above the status
> function, and document it as being deprecated. The whole confusing
> block can get deleted in three releases time.
>
> Signed-off-by: John Snow
Reviewed-by: Vladimir Sementsov-Ogievskiy
14.02.2019 2:23, John Snow wrote:
> These mean the same thing now. Unify them and rename the merged call
> bdrv_dirty_bitmap_busy to indicate semantically what we are describing,
> as well as help disambiguate from the various _locked and _unlocked
> versions of bitmap helpers that refer to mutex
So far we were detecting at guest start if any devices needed vhost net
and only if that was true added a rule for /dev/vhost-net.
It turns out that it is an absolutely valid case to start a guest
without any vhost-net networking but later on wanting to hotplug such a
device which then would be
Change fb01e1a44 "virt-aa-helper: generate rules for gl enabled
graphics devices" implemented the detection for gl enabled
devices in virt-aa-helper. But further testing showed
that it will need much more access for the full gl stack
to work.
Upstream apparmor just recently split those things out
Change fb01e1a44 "virt-aa-helper: generate rules for gl enabled
graphics devices" implemented the detection for gl enabled
devices in virt-aa-helper. But it will in certain cases e.g. if
no rendernode was explicitly specified need to read /dev/dri
which it currently isn't allowed.
Add a rule to
Further testing with opengl enabled graphics showed that we need
much more rules than we initially added.
Upstream apparmor has abstractions [1][2] for the majority of
what we'd need, but those are in no Distribution yet so we can't
rely on them. But we can add rules "like those known ones"
14.02.2019 2:23, John Snow wrote:
> Instead of implying a locked status, make it explicit.
locked interferes with bitmap mutex, so may be better "qmp_locked state", but
not sure.
> Now, bitmaps in use by migration, NBD or backup operations
> are all treated the same way with the same code
14.02.2019 2:23, John Snow wrote:
> Currently, enabled means something like "the status of the bitmap
> is ACTIVE." After this patch, it should mean exclusively: "This
> bitmap is recording guest writes, and is allowed to do so."
>
> In many places, this is how this predicate was already used.
>
On Wed, Feb 06, 2019 at 01:17:58PM -0600, Eric Blake wrote:
> The following is the latest version of my API proposal for
> incremental backups, and follows along from the demo I presented
> as part of my KVM Forum 2018 talk:
>
On Mon, Feb 18, 2019 at 04:15:21PM +0100, Ján Tomko wrote:
> We dropped support in commit 8e91a40 (November 2015), but some
> occurrences still remained, even in live code.
>
> Signed-off-by: Ján Tomko
> Reported-by: Thomas Huth
> ---
Can we at least get rid of X_QEMU_CAPS_KQEMU and
On 2/13/19 7:04 AM, Andrea Bolognani wrote:
> The newline was pretty arbitrary, and we're better off
> without it.
>
> Signed-off-by: Andrea Bolognani
> ---
> src/util/iohelper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
I'm mostly ambivalent about this one; however, since
On 2/13/19 7:04 AM, Andrea Bolognani wrote:
> Logging the error is fine and all, but getting the information
> to the user directly is even better.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1578741
> Signed-off-by: Andrea Bolognani
> ---
> src/util/virfile.c | 6 +-
> 1 file
Let's make use of the auto __cleanup capabilities cleaning up any
now unnecessary goto paths.
Signed-off-by: John Ferlan
---
BTW: I did try this with a linked travis-ci and github branch, and it
worked for me. I'm avoiding altering virStorageFileMetadataNew...
src/util/virstoragefile.c
We dropped support in commit 8e91a40 (November 2015), but some
occurrences still remained, even in live code.
Signed-off-by: Ján Tomko
Reported-by: Thomas Huth
---
docs/drvqemu.html.in | 2 +-
docs/formatdomain.html.in | 2 +-
src/qemu/qemu.conf | 2 +-
14.02.2019 2:23, John Snow wrote:
> "Frozen" was a good description a long time ago, but it isn't adequate now.
> Rename the frozen predicate to has_successor to make the semantics of the
> predicate more clear to outside callers.
>
> In the process, remove some calls to frozen() that no longer
On Mon, Feb 18, 2019 at 08:28:54AM -0500, John Ferlan wrote:
>
>
> On 2/18/19 7:51 AM, Peter Krempa wrote:
> > On Mon, Feb 18, 2019 at 07:38:34 -0500, John Ferlan wrote:
> >>
> >>
> >> On 2/18/19 7:27 AM, Peter Krempa wrote:
> >>> Commit dcda2bf4c110 forgot to fix this one instance.
> >>>
> >>>
On Mon, Feb 18, 2019 at 08:28:54 -0500, John Ferlan wrote:
>
>
> On 2/18/19 7:51 AM, Peter Krempa wrote:
> > On Mon, Feb 18, 2019 at 07:38:34 -0500, John Ferlan wrote:
> >>
> >>
> >> On 2/18/19 7:27 AM, Peter Krempa wrote:
> >>> Commit dcda2bf4c110 forgot to fix this one instance.
> >>>
> >>>
On 2/18/19 7:51 AM, Peter Krempa wrote:
> On Mon, Feb 18, 2019 at 07:38:34 -0500, John Ferlan wrote:
>>
>>
>> On 2/18/19 7:27 AM, Peter Krempa wrote:
>>> Commit dcda2bf4c110 forgot to fix this one instance.
>>>
>>> Signed-off-by: Peter Krempa
>>> ---
>>> src/util/virstoragefile.c | 14
14.02.2019 2:23, John Snow wrote:
> The current API allows us to report a single status, which we've defined as:
>
> Frozen: has a successor, treated as qmp_locked, may or may not be enabled.
> Locked: no successor, qmp_locked. may or may not be enabled.
> Disabled: Not frozen or locked,
On Mon, Feb 18, 2019 at 07:38:34 -0500, John Ferlan wrote:
>
>
> On 2/18/19 7:27 AM, Peter Krempa wrote:
> > Commit dcda2bf4c110 forgot to fix this one instance.
> >
> > Signed-off-by: Peter Krempa
> > ---
> > src/util/virstoragefile.c | 14 ++
> > 1 file changed, 6 insertions(+),
On 2/18/19 7:27 AM, Peter Krempa wrote:
> Commit dcda2bf4c110 forgot to fix this one instance.
>
> Signed-off-by: Peter Krempa
> ---
> src/util/virstoragefile.c | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
Right fix as far as I'm concerned; however, I am curious
Commit dcda2bf4c110 forgot to fix this one instance.
Signed-off-by: Peter Krempa
---
src/util/virstoragefile.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c
index 5927140a66..b2e308d81d 100644
---
On Mon, Feb 18, 2019 at 07:15:38 -0500, John Ferlan wrote:
>
>
> On 2/15/19 7:42 AM, Peter Krempa wrote:
> > Now that virStorageSource is a subclass of virObject we can use
> > virObjectUnref and remove virStorageSourceFree which was a thin wrapper.
> >
> > Signed-off-by: Peter Krempa
> > ---
On 2/15/19 7:42 AM, Peter Krempa wrote:
> Now that virStorageSource is a subclass of virObject we can use
> virObjectUnref and remove virStorageSourceFree which was a thin wrapper.
>
> Signed-off-by: Peter Krempa
> ---
> src/conf/domain_conf.c | 8
> src/conf/snapshot_conf.c
On Fri, Feb 15, 2019 at 11:29 PM Jamie Strandboge wrote:
>
> On Tue, 12 Feb 2019, Christian Ehrhardt wrote:
>
> > Change fb01e1a44 "virt-aa-helper: generate rules for gl enabled
> > graphics devices" implemented the detection for gl enabled
> > devices in virt-aa-helper. But further testing
On Mon, Feb 18, 2019 at 10:16:25AM +0100, Peter Krempa wrote:
> On Mon, Feb 18, 2019 at 08:29:14 +0100, Erik Skultety wrote:
> > On Fri, Feb 15, 2019 at 01:42:09PM +0100, Peter Krempa wrote:
> > > Add virStorageSourceNew and refactor places allocating that structure to
> > > use the helper.
> > >
On Mon, Feb 18, 2019 at 10:15:35AM +0100, Peter Krempa wrote:
> Use the proper function to allocate a disk definition.
>
> Signed-off-by: Peter Krempa
> ---
Reviewed-by: Erik Skultety
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Mon, Feb 18, 2019 at 08:29:14 +0100, Erik Skultety wrote:
> On Fri, Feb 15, 2019 at 01:42:09PM +0100, Peter Krempa wrote:
> > Add virStorageSourceNew and refactor places allocating that structure to
> > use the helper.
> >
> > Signed-off-by: Peter Krempa
> > ---
> Looks like you caught all the
Use the proper function to allocate a disk definition.
Signed-off-by: Peter Krempa
---
src/bhyve/bhyve_parse_command.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/bhyve/bhyve_parse_command.c b/src/bhyve/bhyve_parse_command.c
index 1c9191fb96..bd93070dfb 100644
---
On Mon, 2019-02-18 at 09:46 +0100, Bjoern Walk wrote:
> Andrea Bolognani [2019-02-15, 12:55PM +0100]:
> > +case VIR_DOMAIN_DEVICE_NONE:
> > +virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> > + _("unexpected VIR_DOMAIN_DEVICE_NONE"));
>
> Can we find a better
Andrea Bolognani [2019-02-15, 12:55PM +0100]:
> +case VIR_DOMAIN_DEVICE_NONE:
> +virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> + _("unexpected VIR_DOMAIN_DEVICE_NONE"));
Can we find a better error message here?
> +break;
> +
> +case
On Fri, Feb 15, 2019 at 01:42:13PM +0100, Peter Krempa wrote:
> Now that virStorageSource is a subclass of virObject we can use
> virObjectUnref and remove virStorageSourceFree which was a thin wrapper.
>
> Signed-off-by: Peter Krempa
> ---
Reviewed-by: Erik Skultety
--
libvir-list mailing list
On Fri, Feb 15, 2019 at 01:42:12PM +0100, Peter Krempa wrote:
> Since virStorageSource is now a subclass of virObject, we can use
> VIR_AUTOUNREF instead.
>
> Signed-off-by: Peter Krempa
> ---
Reviewed-by: Erik Skultety
--
libvir-list mailing list
libvir-list@redhat.com
On Fri, Feb 15, 2019 at 01:42:12PM +0100, Peter Krempa wrote:
> Since virStorageSource is now a subclass of virObject, we can use
> VIR_AUTOUNREF instead.
>
> Signed-off-by: Peter Krempa
> ---
Reviewed-by: Erik Skultety
--
libvir-list mailing list
libvir-list@redhat.com
On Fri, Feb 15, 2019 at 01:42:11PM +0100, Peter Krempa wrote:
> Add helper for utilizing __attribute__(cleanup())) for unref-ing
> instances of sublasses of virObject.
>
> Signed-off-by: Peter Krempa
> ---
Reviewed-by: Erik Skultety
--
libvir-list mailing list
libvir-list@redhat.com
49 matches
Mail list logo
