Re: [libvirt] [RFC] Accepting PRs/MRs for libvirt on GitHub/GitLab

[Roman Mohr]

On Wed, Oct 16, 2019 at 6:42 PM Daniel Henrique Barboza <
danielhb...@gmail.com> wrote:

>
>
> On 10/16/19 9:22 AM, Andrea Bolognani wrote:
> > As we look to make the libvirt project easier to contribute to, one
> > fact that certainly comes to mind is that we only accept patches via
> > the mailing list. While the core developers are comfortable with the
> > email-based workflow and swear by it, many perspective contributors
> > are used to the PR/MR workflow common to many Open Source projects
> > these days, and similarly swear by it.
> >
> > If we look at the PRs submitted on GitHub against the libvirt mirror
> > repository[1], there's just three of them per year on average, which
> > is arguably not a lot; however, it should be noted that each
> > repository also carries a fairly loud "PULL REQUESTS ARE IGNORED"
> > message right at the top, and it's not unlikely that a number of
> > perspective contributors simply lost interest after seeing it.
> >
> > As a way to make contributions easier without forcing core developers
> > to give up their current workflow or making the project dependent on
> > a third-party provider, I suggest we adopt a hybrid approach.
> >
> > First of all, we'd remove the ominous message from GitHub mirror
> > repositories (interestingly, the same is not present on GitLab).
> >
> > Then, we'd starting accepting PRs/MRs. The way we'd handle them is
> > that, when one comes in, one among the handful of core developers who
> > volunteered to do so would review the patches on the respective
> > platform, working with the submitter to get it into shape just like
> > they would do on the mailing list; once the series is finally ready
> > to be merged, the core developer would update the PR/MR as necessary,
> > for example picking up R-bs or fixing the kind of trivial issues that
> > usually don't warrant a repost, and then push to master as usual.
>
> This would mean that there will be patches that will get accepted
> without the ML being aware of. The core developer (or the author
> itself) would need to send the revised patches to the ML before
> pushing to make people aware of it before pushing to master, IMO.
>

The activemq mailing list as a bot or something installed which posts
events like a new PR or a merged PR to their mailing list.

Best Regards,
Roman


>
> I have a 2 year experience maintaining a now defunct project in
> Github (a KVM web management tool called Kimchi) in which we used a
> hybrid approach like I think you're suggesting, with mailing list, people
> opening bugs in Github + Github PRs. It was annoying - people will
> inevitably
> discuss issues using the Github tracking system, which means that you'll
> have to subscribe via email to Github notifications if you didn't want
> to miss
> out. It was common for people that used the ML to start discussions that
> were already happening in the Web, and vice-versa.
>
> All that to make a case against Libvirt having additional ways of
> communication. I don't mind pull requests from Github/Gitlab as long as the
> ML is made aware of, before the patches are accepted. But people bringing
> up discussions in the ML and Github/Gitlab scales poorly, in my experience.
>
>
> DHB
>
>
> >
> > More in detail: GitHub and GitLab have a feature that allows project
> > members to update PRs/MRs: basically the way it works is that, if the
> > PR/MR was created by the user 'foo' from their branch 'bar', the
> > libvirt developer is allowed to (force-)push to the foo/libvirt/bar
> > branch, and doing so updates the corresponding PR/MR; after that, if
> > the updated branch is locally merged into master and master is pushed
> > to the libvirt.org repo, once it gets mirrored GitHub/GitLab will
> > recognize that the commit IDs match and automatically mark the PR/MR
> > as merged. I have tested this behavior on both platforms (minus the
> > mirroring part) with Martin's help.
> >
> > One last important bit. In the spirit of not requiring core
> > developers to alter their workflow, the developer who reviewed the
> > patches on GitHub/GitLab will also be responsible to format them to
> > the mailing list after merging them: this way, even those who don't
> > have a GitHub/GitLab account will get a chance to take notice of the
> > code changes and weigh in. Unlike what we're used to, this feedback
> > will come after the fact, but assuming that issues are spotted only
> > at that point we can either push the relevant fixes as follow-up
> > commits or even revert the series outright, so I don't feel like it
> > would be a massive problem overall.
> >
> > Thoughts?
> >
> >
> > [1] https://github.com/libvirt/libvirt/pulls?q=is:pr+is:closed
>
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
>
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Missing repo file for virt-preview repo on fedorapeople

[Roman Mohr]

On Fri, Aug 10, 2018 at 10:02 AM Andrea Bolognani 
wrote:

> On Fri, 2018-08-10 at 08:54 +0200, Roman Mohr wrote:
> > Hi everyone,
> >
> > Is there a change on how to get the fedora-virt-preview.repo?
> >
> > So far we were referencing
> >
> >
> https://fedorapeople.org/groups/virt/virt-preview/fedora-virt-preview.repo
> >
> > but that file does not seem to exist anymore.
>
> Please post this kind of question to libvirt-users next time, and
> refrain from CC'ing libvirt developers - we are all subscribed to
> and read the lists.
>
> As for your question,
>
>   https://fedoraproject.org/wiki/Virtualization_Preview_Repository


Thank you.

Roman

>
>
> (which was the first result when searching "fedora virt-preview"
> with Google) should contain the information you're looking for.
>
> --
> Andrea Bolognani / Red Hat / Virtualization
>
>
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] Missing repo file for virt-preview repo on fedorapeople

[Roman Mohr]

Hi everyone,

Is there a change on how to get the fedora-virt-preview.repo?

So far we were referencing

https://fedorapeople.org/groups/virt/virt-preview/fedora-virt-preview.repo

but that file does not seem to exist anymore.

Best Regards,
Roman
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] opening tap devices that are created in a container

[Roman Mohr]

On Wed, Jul 11, 2018 at 12:10 PM  wrote:

> On Mon, Jul 09, 2018 at 05:00:49PM -0400, Jason Baron wrote:
> >
> >
> >On 07/08/2018 02:01 AM, Martin Kletzander wrote:
> >> On Thu, Jul 05, 2018 at 06:24:20PM +0200, Roman Mohr wrote:
> >>> On Thu, Jul 5, 2018 at 4:20 PM Jason Baron  wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> Opening tap devices, such as macvtap, that are created in containers
> is
> >>>> problematic because the interface for opening tap devices is via
> >>>> /dev/tapNN and devtmpfs is not typically mounted inside a container as
> >>>> its not namespace aware. It is possible to do a mknod() in the
> >>>> container, once the tap devices are created, however, since the tap
> >>>> devices are created dynamically its not possible to apriori allow
> access
> >>>> to certain major/minor numbers, since we don't know what these are
> going
> >>>> to be. In addition, its desirable to not allow the mknod capability in
> >>>> containers. This behavior, I think is somewhat inconsistent with the
> >>>> tuntap driver where one can create tuntap devices inside a container
> by
> >>>> first opening /dev/net/tun and then using them by supplying the tuntap
> >>>> device name via the ioctl(TUNSETIFF). And since TUNSETIFF validates
> the
> >>>> network namespace, one is limited to opening network devices that
> belong
> >>>> to your current network namespace.
> >>>>
> >>>> Here are some options to this issue, that I wanted to get feedback
> >>>> about, and just wondering if anybody else has run into this.
> >>>>
> >>>> 1)
> >>>>
> >>>> Don't create the tap device, such as macvtap in the container.
> Instead,
> >>>> create the tap device outside of the container and then move it into
> the
> >>>> desired container network namespace. In addition, do a mknod() for the
> >>>> corresponding /dev/tapNN device from outside the container before
> doing
> >>>> chroot().
> >>>>
> >>>> This solution still doesn't allow tap devices to be created inside the
> >>>> container. Thus, in the case of kubevirt, which runs libvirtd inside
> of
> >>>> a container, it would mean changing libvirtd to open existing tap
> >>>> devices (as opposed to the current behavior of creating new ones).
> This
> >>>> would not require any kernel changes, but as mentioned seems
> >>>> inconsistent with the tuntap interface.
> >>>>
> >>>
> >>> For KubeVirt, apart from how exactly the device ends up in the
> >>> container, I
> >>> would want to pursue a way where all network preparations which require
> >>> privileges happens from a privileged process *outside* of the
> container.
> >>> Like CNI solutions do it. They run outside, have privileges and then
> >>> create
> >>> devices in the right network/mount namespace or move them there. The
> >>> final
> >>> goal for KubeVirt is that our pod with the qemu process is completely
> >>> unprivileged and privileged setup happens from outside.
> >>>
> >>> As a consequence, and depending on which route Dan pursues with the
> >>> restructured libvirt, I would assume that either a privileged
> >>> libvirtd-part
> >>> outside of containers creates the devices by entering the right
> >>> namespaces,
> >>> or that libvirt in the container can consume pre-created tun/tap
> devices,
> >>> like qemu.
> >>>
> >>
> >> That would be nice, but as far as I understand there will always be a
> >> need for
> >> some privileges if you want to use a tap device.  It's nice that CNI
> >> does that
> >> and all the containers can run unprivileged, but that's because they do
> >> not open
> >> the tap device and they do not do any privileged operations on it.  But
> >> QEMU
> >> needs to.  So the only way would be passing an opened fd to the
> >> container or
> >> opening the tap device there and making the fd usable for one process in
> >> the
> >> container.  Is this already supported for some type of containers in
> >> some way?
> >>
> >> Martin
> >
> >Hi,
> >
> >So another option here call it #3 is to pass open fds

Re: [libvirt] opening tap devices that are created in a container

[Roman Mohr]

On Thu, Jul 5, 2018 at 4:20 PM Jason Baron  wrote:

> Hi,
>
> Opening tap devices, such as macvtap, that are created in containers is
> problematic because the interface for opening tap devices is via
> /dev/tapNN and devtmpfs is not typically mounted inside a container as
> its not namespace aware. It is possible to do a mknod() in the
> container, once the tap devices are created, however, since the tap
> devices are created dynamically its not possible to apriori allow access
> to certain major/minor numbers, since we don't know what these are going
> to be. In addition, its desirable to not allow the mknod capability in
> containers. This behavior, I think is somewhat inconsistent with the
> tuntap driver where one can create tuntap devices inside a container by
> first opening /dev/net/tun and then using them by supplying the tuntap
> device name via the ioctl(TUNSETIFF). And since TUNSETIFF validates the
> network namespace, one is limited to opening network devices that belong
> to your current network namespace.
>
> Here are some options to this issue, that I wanted to get feedback
> about, and just wondering if anybody else has run into this.
>
> 1)
>
> Don't create the tap device, such as macvtap in the container. Instead,
> create the tap device outside of the container and then move it into the
> desired container network namespace. In addition, do a mknod() for the
> corresponding /dev/tapNN device from outside the container before doing
> chroot().
>
> This solution still doesn't allow tap devices to be created inside the
> container. Thus, in the case of kubevirt, which runs libvirtd inside of
> a container, it would mean changing libvirtd to open existing tap
> devices (as opposed to the current behavior of creating new ones). This
> would not require any kernel changes, but as mentioned seems
> inconsistent with the tuntap interface.
>

For KubeVirt, apart from how exactly the device ends up in the container, I
would want to pursue a way where all network preparations which require
privileges happens from a privileged process *outside* of the container.
Like CNI solutions do it. They run outside, have privileges and then create
devices in the right network/mount namespace or move them there. The final
goal for KubeVirt is that our pod with the qemu process is completely
unprivileged and privileged setup happens from outside.

As a consequence, and depending on which route Dan pursues with the
restructured libvirt, I would assume that either a privileged libvirtd-part
outside of containers creates the devices by entering the right namespaces,
or that libvirt in the container can consume pre-created tun/tap devices,
like qemu.

Best Regards,
Roman


>
> 2)
>
> Add a new kernel interface for tap devices similar to how /dev/net/tun
> currently works. It might be nice to use TUNSETIFF for tap devices, but
> because tap devices have different fops they can't be easily switched
> after open(). So the suggestion is a new ioctl (TUNGETFDBYNAME?), where
> the tap device name is supplied and a new fd (distinct from the fd
> returned by the open of /dev/net/tun) is returned as an output field as
> part of the new ioctl parameter.
>
> It may not make sense to have this new ioctl call for /dev/net/tun since
> its really about opening a tap device, so it may make sense to introduce
> it as part of a new device, such as /dev/net/tap. This new ioctl could
> be used for macvtap and ipvtap (or any tap device). I think it might
> also improve performance for tuntap devices themselves, if they are
> opened this way since currently all tun operations such as read() and
> write() take a reference count on the underlying tuntap device, since it
> can be changed via TUNSETIFF. I tested this interface out, so I can
> provide the kernel changes if that's helpful for clarification.
>
> Thanks,
>
> -Jason
>
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH alt] conf: Allow user define their own alias

[Roman Mohr]

On Fri, Sep 29, 2017 at 3:49 PM, Michal Privoznik 
wrote:

> On 09/29/2017 01:16 PM, Peter Krempa wrote:
> > On Fri, Sep 29, 2017 at 12:57:29 +0200, Michal Privoznik wrote:
> >> On 09/29/2017 09:52 AM, Peter Krempa wrote:
> >>> On Fri, Sep 29, 2017 at 09:06:01 +0200, Michal Privoznik wrote:
>  https://bugzilla.redhat.com/show_bug.cgi?id=1434451
> 
>  It comes handy for management application to be able to have a
>  per-device label so that it can uniquely identify devices it
>  cares about. The advantage of this approach is that we don't have
>  to generate aliases at define time (non trivial amount of work
>  and problems). The only thing we do is parse the user supplied
>  tag and format it back. For instance:
> 
>  
>    
>    
>    
>    
> unit='0'/>
>  
> 
>  Signed-off-by: Michal Privoznik 
>  ---
> 
>  An alternative approach to:
> 
>  https://www.redhat.com/archives/libvir-list/2017-
> September/msg00765.html
> 
>  Honestly, I prefer this one as it's simpler and we don't have to care
> about
>  devices changing their aliases on cold plug. I mean, on cold
> (un-)plug we'd
>  have to regenerate the aliases so it might be hard to track certain
> device.
>  But with this approach, it's no problem.
> 
>  Also, I'm not completely convinced about the name of @user attribute.
> So I'm
>  open for suggestions.
> >>>
> >>> With this proposed design you need to make sure to document that the
> >>> user alias is _not_ guaranteed to be unique and also that it can't be
> >>> used to match the device in any way.
> >>>
> >>
> >> Sure. I'll just add it at the end of the paragraph that describes
> >> . Err, hold on. There's none! But okay, I think I can find a
> >> place to add it there.
> >>
> >> Even though my patch doesn't implement it (simply because I wanted to
> >> have ACK on the design so I've saved it for follow up patches), I don't
> >> quite see why we can't match user supplied aliases?
> >
> > I think it will introduce more problems than solve. You will need to
> > make sure that it's unique even across hotplug and add lookup code for
> > everything. Additionally you can't add that as a mandatory field when
> > looking up, since some device classes allow lookup only with partial XML
> > descriptions (for unplug/update).
>
> It can't be mandatory, that's the whole point. Sure. Well, in
> DomainPostParse I can check for uniqueness pretty easily: just create an
> empty list and start adding all strings provided by user. If the string
> we're trying to add is already in the list we just error out. Sure, I'll
> have to iterate over all devices, but that should be pretty easy since
> we have virDomainDeviceInfoIterate(). All that's needed is to write the
> callback function (= a few lines of code). Then, on hotplug goto 10.
> IOW, if user alias is provided just check for its uniqueness.
>
> >
> >> virsh domif-setlink fedora myNet down
> >>
> >> This has the great advantage of being ordering agnostic. You don't have
> >> to check for the alias of the device you want to modify (as aliases can
> >> change across different startups, right?). True, for that we would have
> >
> > Well, you've used a bad example for this. 'domif-setlink' uses target and
> > mac address, both of which are stable and don't rely on ordering on
> > startup. Same thing applies to disks.
>
> Oh right. domiftune is more like it.
>
> >
> > The matching in virsh in this particular command is done by looking for
> > the full element and then using that with the UpdateDevice() API, so the
> > lookup is basically syntax sugar.
> >
> >> to make sure that the supplied aliases are unique per domain (which is
> >> trivial to achieve). But apart from that I don't quite see why we
> >> shouldn't/can't do it.
> >
> > Well, I don't think it's trivial. It's simpler than providing the alias
> > which would be used with qemu, but you still have a zillion hotplug code
> > paths which would need to check this.
>
> Well, it might be slightly tricky yes. But in general, the
> virDomain*Find() would try to match the user alias first (if provided)
> else continue with current behaviour. I'm not quite sure what you mean
> by zillion code paths.
>
> >
> >>> I think that users which know semantics of the current alias may be
> very
> >>> confused by putting user data with different semantics into the same
> >>> field.
> >>>
> >>
> >> Yep. As I say, I'm not happy with the name either. Any suggestion is
> >> welcome. So a separate element then? Naming is hard.
> >
> > I'm voting for separate element in case there's consensus that this
> > route is a good idea.
> >
>
> Yeah, it may look a bit better. Any idea on the element name?
>


How about "label" or "userlabel"?

Best Regards,

Roman


>
> Michal
>
> --
> libvir-list mailing list
> libvir-list@redhat.com
> 

Re: [libvirt] Libvirt domain event usage and consistency

[Roman Mohr]

On Wed, Dec 7, 2016 at 8:38 AM, Fabian Deutsch <fdeut...@redhat.com> wrote:

> On Wed, Dec 7, 2016 at 8:26 AM, Michal Privoznik <mpriv...@redhat.com>
> wrote:
> > On 06.12.2016 14:12, Roman Mohr wrote:
> >> On Fri, Nov 25, 2016 at 4:34 PM, Michal Privoznik <mpriv...@redhat.com>
> >> wrote:
> >>
> >>> On 25.11.2016 14:38, Roman Mohr wrote:
> >>>
> >>>
> >> [...]
> >>
> >>
> >>>>
> >>>> 4) There libvirt domain description is not versioned
> >>>>
> >>>> I would expect that every time I update a domainxml (update from third
> >>>> party entity), or an event is generated (update from libvirt), that
> the
> >>>> resource version of a Domain is increased and that I get this resource
> >>>> version when I do a xmldump or when I get an event. Without this
> there is
> >>>> afaik no way to stay in sync with libvirt, even if you do regular
> polling
> >>>> of all domains. The main issue here is that I can never know if
> events in
> >>>> the queue arrived before my latest domain resync or after it.
> >>>>
> >>>> Also not that this is not about delivery guarantees of events. It is
> just
> >>>> about having a consistent view of a VM and the individual event. If I
> >>> have
> >>>> resource versions, I can decide if an event is still interesting for
> me
> >>> or
> >>>> not, which is exactly what I need to solve the syncing problem above.
> >>>> When I do a complete relisting of all domains to syn, I know which
> >>> version
> >>>> I got and I can then see on every event if it is newer or older.
> >>>>
> >>>> If along side with the event, the domain xml, the VM state, and the
> >>>> resource version would be sent to a client, it would be even better.
> >>> Then,
> >>>> whenever there is a new event for a VM in the queue, I can be sure
> that
> >>>> this domainxml I see is the one which triggered the event. This xml is
> >>> then
> >>>> a complete representation for this revision number.
> >>>
> >>> I recall some people asking for this. Basically, they were worried
> about
> >>> somebody from outside could manipulate their XMLs without them knowing.
> >>> Frankly I don't recall what was our answer to that.
> >>
> >>
> >>
> >>
> >>
> >>>
> >>>
> >> Having a version number in live XML makes sense. However, it makes less
> >>> sense for config XML - there would be no way how to start with version
> >>> #0 once I've edited the file.
> >>>
> >>
> >> I think it would be very beneficial to have it on the config file too.
> >> Think about the resource version as opaque data which can be used by
> >> libvirt to see if the domain xml update contains the same resource
> number
> >> which libvirt sees.
> >
> > If we do this then it's just a matter of time that users start demanding
> > "How do I return to revision #1337?". And we don't want to go there.
>
> Well - We could argue that currently it is just not possible to
> connect libvirtd events and a specific dom revision. This implies that
> users also could not do it themselves.
> With the change however, libvirtd will not provide the full history,
> but if it's needed then now users are able to add such functionality
> alongside of libvirtd. It would ismpliy enable this usecase.
>

+1

If the dom and events are connected, creating your own history is just a
matter of storing the dom in a map or a key-value store with the revision
as a key. Really no need to have that in libvirt. In my eyes the benefit
here really is that you get  consistency which enables all the consistent
caching and update usecases.




>
> >> So if you want to be sure that you are updating the domain xml from the
> >> latest state, you pass in the resource version of your cached domain xml
> >> view. If the version is still the same inside of libvirt, libvirt
> updates
> >> the domain xml and increases the resource version. If it has changed in
> the
> >> meantime, it rejects the update and the client can re-fetch the latest
> >> state and try again.
> >
> > Makes sense.
> >
> >> For classic update mode, just don't pass in the
> >> resource version as a client and libvirt can then just update the domain
> >

Re: [libvirt] Libvirt domain event usage and consistency

[Roman Mohr]

On Fri, Nov 25, 2016 at 4:34 PM, Michal Privoznik <mpriv...@redhat.com>
wrote:

> On 25.11.2016 14:38, Roman Mohr wrote:
>
>
[...]


> >
> > 4) There libvirt domain description is not versioned
> >
> > I would expect that every time I update a domainxml (update from third
> > party entity), or an event is generated (update from libvirt), that the
> > resource version of a Domain is increased and that I get this resource
> > version when I do a xmldump or when I get an event. Without this there is
> > afaik no way to stay in sync with libvirt, even if you do regular polling
> > of all domains. The main issue here is that I can never know if events in
> > the queue arrived before my latest domain resync or after it.
> >
> > Also not that this is not about delivery guarantees of events. It is just
> > about having a consistent view of a VM and the individual event. If I
> have
> > resource versions, I can decide if an event is still interesting for me
> or
> > not, which is exactly what I need to solve the syncing problem above.
> > When I do a complete relisting of all domains to syn, I know which
> version
> > I got and I can then see on every event if it is newer or older.
> >
> > If along side with the event, the domain xml, the VM state, and the
> > resource version would be sent to a client, it would be even better.
> Then,
> > whenever there is a new event for a VM in the queue, I can be sure that
> > this domainxml I see is the one which triggered the event. This xml is
> then
> > a complete representation for this revision number.
>
> I recall some people asking for this. Basically, they were worried about
> somebody from outside could manipulate their XMLs without them knowing.
> Frankly I don't recall what was our answer to that.





>
>
Having a version number in live XML makes sense. However, it makes less
> sense for config XML - there would be no way how to start with version
> #0 once I've edited the file.
>

I think it would be very beneficial to have it on the config file too.
Think about the resource version as opaque data which can be used by
libvirt to see if the domain xml update contains the same resource number
which libvirt sees.
So if you want to be sure that you are updating the domain xml from the
latest state, you pass in the resource version of your cached domain xml
view. If the version is still the same inside of libvirt, libvirt updates
the domain xml and increases the resource version. If it has changed in the
meantime, it rejects the update and the client can re-fetch the latest
state and try again. For classic update mode, just don't pass in the
resource version as a client and libvirt can then just update the domain
xml like always. This is pretty much the same principle like described in
[1].

What is the rationale for this?

I am mostly operating on cached views on libvirts data in combination with
events. If, on listing resources and on events, I get a domain xml with a
resource version and the Domain state, I have a full snapshot of the
Domain, which I can put into a cache or queue. Then syncing with libvirt
based on events and initial listing is possible. Otherwise I can never be
sure if my view of libvirt is out of sync.

When I then process an event I can process it based on the consistent
snapshot view of the Domain and update the domain xml. If something has
changed in the meantime, the update of the domain xml will fail and I can
recheck and retry. Even better: In most cases the event does not need
retries, because a newer event is already in the queue with the new Domain
view which caused the update to fail.

Finally it allows consistent incremental Domain state and description
updates which can be sent to third parties without periodic refetching of
all resources.

Roman

[1]
https://github.com/kubernetes/kubernetes/blob/master/docs/devel/api-conventions.md


> Michal
>
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Libvirt domain event usage and consistency

[Roman Mohr]

On Fri, Nov 25, 2016 at 8:23 PM, Michal Privoznik <mpriv...@redhat.com>
wrote:

> On 25.11.2016 18:33, Roman Mohr wrote:
> > On Fri, Nov 25, 2016 at 6:04 PM, Michal Privoznik <mpriv...@redhat.com>
> > wrote:
> >
> >> On 25.11.2016 17:54, Roman Mohr wrote:
> >>> On Fri, Nov 25, 2016 at 4:34 PM, Michal Privoznik <mpriv...@redhat.com
> >
> >>> wrote:
> >>>
> >>>> On 25.11.2016 14:38, Roman Mohr wrote:
> >>>>> Hi,
> >>>>>
> >>>>> I recently started to use the libvirt domain events. With them I
> >> increase
> >>>>> the responsiveness of my VM state wachers.
> >>>>> In general it works pretty well. I just listen to the events and do a
> >>>>> periodic resync to cope with missed events.
> >>>>>
> >>>>> While watching the events I ran into a few interesting situations I
> >>>> wanted
> >>>>> to share. The points 1-3 describe some minor issues or
> irregularities.
> >>>>> Point 4 is about the fact that domain and state updates are not
> >> versioned
> >>>>> which makes it very hard to stay in sync with libvirt when using
> >> events.
> >>>>>
> >>>>> My libvirt version is 1.2.18.4.
> >>>>
> >>>> This might be the root cause. I'm unable to see some of the scenarios
> >>>> you're seeing. Have you tried the latest release (or even git HEAD) to
> >>>> check whether all the scenarios you are describing still stand?
> >>>>
> >>>
> >>> Definitely better with latest HEAD but still it does not look
> completely
> >>> right.
> >>>
> >>>>
> >>>>>
> >>>>> 1) Event order seems to be weird on startup:
> >>>>>
> >>>>> When listening for VM lifecycle events I get this order:
> >>>>>
> >>>>> {"event_type": "Started", "timestamp": "2016-11-25T11:59:53.209326Z",
> >>>>> "reason": "Booted", "domain_name": "generic", "domain_id":
> >>>>> "8ff7047b-fb46-44ff-a4c6-7c20c73ab86e"}
> >>>>> {"event_type": "Defined", "timestamp": "2016-11-25T11:59:53.435530Z",
> >>>>> "reason": "Added", "domain_name": "generic", "domain_id":
> >>>>> "8ff7047b-fb46-44ff-a4c6-7c20c73ab86e"}
> >>>>>
> >>>>> It is strange that a VM already boots before it is defined. Is this
> the
> >>>>> intended order?
> >>>>
> >>>> I don't see this order so probable this is fixed upstream.
> >>>>
> >>>
> >>> On latest master a normal creation emits these events:
> >>>
> >>> event 'lifecycle' for domain testvm: Resumed Unpaused
> >>> event 'lifecycle' for domain testvm: Started Booted
> >>>
> >>> The Resumed event looks wrong. Further I get no more Defined/Undefined
> >>> events. Maybe they were removed?
> >>
> >> Yes, they were removed.
> >
> >
> > Nice
> >
> >
> >> The Resumed event comes from qemu actually,
> >> because libvirt starts qemu in paused mode so that we can do some setup
> >> (e.g. place vcpu threads into cgroups) and only after that we can resume
> >> guest CPUs and in fact let guest start. Once this is done we
> >> deliberately emit Started event.
> >>
> >
> > I would expect an event like this:
> >
> > event 'lifecycle' for domain testvm: Suspended Bootstrapping
> >
> > before the other two events. That takes the ambiguity from the Resumed
> > event.
> >
> >
> >>>
> >>>
> >>>>
> >>>>>
> >>>>> 2) Defining a VM with VIR_DOMAIN_START_PAUSED gives me this event
> order
> >>>>
> >>>> I don't think you can define a domain with that flag. What's the
> actual
> >>>> action?
> >>>>
> >>>
> >>> That is the flag for the api, when using virsh using `--paused` does
> >> that.
> >>
> >> Ah, that's for virsh create/start not virsh define. Anyway, this is no
> >> longer the case with upstream, is it?
> >>
> >>
&

Re: [libvirt] Libvirt domain event usage and consistency

[Roman Mohr]

On Fri, Nov 25, 2016 at 6:04 PM, Michal Privoznik <mpriv...@redhat.com>
wrote:

> On 25.11.2016 17:54, Roman Mohr wrote:
> > On Fri, Nov 25, 2016 at 4:34 PM, Michal Privoznik <mpriv...@redhat.com>
> > wrote:
> >
> >> On 25.11.2016 14:38, Roman Mohr wrote:
> >>> Hi,
> >>>
> >>> I recently started to use the libvirt domain events. With them I
> increase
> >>> the responsiveness of my VM state wachers.
> >>> In general it works pretty well. I just listen to the events and do a
> >>> periodic resync to cope with missed events.
> >>>
> >>> While watching the events I ran into a few interesting situations I
> >> wanted
> >>> to share. The points 1-3 describe some minor issues or irregularities.
> >>> Point 4 is about the fact that domain and state updates are not
> versioned
> >>> which makes it very hard to stay in sync with libvirt when using
> events.
> >>>
> >>> My libvirt version is 1.2.18.4.
> >>
> >> This might be the root cause. I'm unable to see some of the scenarios
> >> you're seeing. Have you tried the latest release (or even git HEAD) to
> >> check whether all the scenarios you are describing still stand?
> >>
> >
> > Definitely better with latest HEAD but still it does not look completely
> > right.
> >
> >>
> >>>
> >>> 1) Event order seems to be weird on startup:
> >>>
> >>> When listening for VM lifecycle events I get this order:
> >>>
> >>> {"event_type": "Started", "timestamp": "2016-11-25T11:59:53.209326Z",
> >>> "reason": "Booted", "domain_name": "generic", "domain_id":
> >>> "8ff7047b-fb46-44ff-a4c6-7c20c73ab86e"}
> >>> {"event_type": "Defined", "timestamp": "2016-11-25T11:59:53.435530Z",
> >>> "reason": "Added", "domain_name": "generic", "domain_id":
> >>> "8ff7047b-fb46-44ff-a4c6-7c20c73ab86e"}
> >>>
> >>> It is strange that a VM already boots before it is defined. Is this the
> >>> intended order?
> >>
> >> I don't see this order so probable this is fixed upstream.
> >>
> >
> > On latest master a normal creation emits these events:
> >
> > event 'lifecycle' for domain testvm: Resumed Unpaused
> > event 'lifecycle' for domain testvm: Started Booted
> >
> > The Resumed event looks wrong. Further I get no more Defined/Undefined
> > events. Maybe they were removed?
>
> Yes, they were removed.


Nice


> The Resumed event comes from qemu actually,
> because libvirt starts qemu in paused mode so that we can do some setup
> (e.g. place vcpu threads into cgroups) and only after that we can resume
> guest CPUs and in fact let guest start. Once this is done we
> deliberately emit Started event.
>

I would expect an event like this:

event 'lifecycle' for domain testvm: Suspended Bootstrapping

before the other two events. That takes the ambiguity from the Resumed
event.


> >
> >
> >>
> >>>
> >>> 2) Defining a VM with VIR_DOMAIN_START_PAUSED gives me this event order
> >>
> >> I don't think you can define a domain with that flag. What's the actual
> >> action?
> >>
> >
> > That is the flag for the api, when using virsh using `--paused` does
> that.
>
> Ah, that's for virsh create/start not virsh define. Anyway, this is no
> longer the case with upstream, is it?
>
>
Right


> >
> >
> >>
> >>>
> >>> {"event_type": "Defined", "timestamp": "2016-11-25T12:02:44.037817Z",
> >>> "reason": "Added", "domain_name": "core_node", "domain_id":
> >>> "b9906489-6d5b-40f8-a742-ca71b2b84277"}
> >>> {"event_type": "Resumed", "timestamp": "2016-11-25T12:02:44.813104Z",
> >>> "reason": "Unpaused", "domain_name": "core_node", "domain_id":
> >>> "b9906489-6d5b-40f8-a742-ca71b2b84277"}
> >>> {"event_type": "Started", "timestamp": "2016-11-25T12:02:44.813733Z",
> >>> "reason": "Booted", "domain_name": "core_node", "domain_id":
> >>> "b9906489-6d5b-40f8-a742-ca71b2b84277"}
> >>
> >>
> >> Interesting, so here is "defined" event delivered before the "started"
> >> event. Also - where is "suspended" event?
> >>
> >
> >
> > With latest master the situation looks better. Now I see
> >
> > event 'lifecycle' for domain testvm: Started Booted
> > event 'lifecycle' for domain testvm: Suspended Paused
>
> Again, both of these are deliberately emitted by libvirt and in fact I
> think they reflect what is happening.
>
>
Why is in this case  not

 event 'lifecycle' for domain testvm: Resumed Unpaused

event emitted?

I would expect

event 'lifecycle' for domain testvm: Resumed Unpaused
event 'lifecycle' for domain testvm: Started Booted
event 'lifecycle' for domain testvm: Suspended Paused


So the situation on master is much better but because of the
Resumed/Unpaused event I still have the feeling that the most simple but
powerful usecase, watching for CREATE, UPDATE, DELETE is very hard because
you can't know if the Resumed/Unpaused is the indicator for CREATE or
UPDATE.

What do you think?


Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Libvirt domain event usage and consistency

[Roman Mohr]

On Fri, Nov 25, 2016 at 4:34 PM, Michal Privoznik <mpriv...@redhat.com>
wrote:

> On 25.11.2016 14:38, Roman Mohr wrote:
> > Hi,
> >
> > I recently started to use the libvirt domain events. With them I increase
> > the responsiveness of my VM state wachers.
> > In general it works pretty well. I just listen to the events and do a
> > periodic resync to cope with missed events.
> >
> > While watching the events I ran into a few interesting situations I
> wanted
> > to share. The points 1-3 describe some minor issues or irregularities.
> > Point 4 is about the fact that domain and state updates are not versioned
> > which makes it very hard to stay in sync with libvirt when using events.
> >
> > My libvirt version is 1.2.18.4.
>
> This might be the root cause. I'm unable to see some of the scenarios
> you're seeing. Have you tried the latest release (or even git HEAD) to
> check whether all the scenarios you are describing still stand?
>

Definitely better with latest HEAD but still it does not look completely
right.

>
> >
> > 1) Event order seems to be weird on startup:
> >
> > When listening for VM lifecycle events I get this order:
> >
> > {"event_type": "Started", "timestamp": "2016-11-25T11:59:53.209326Z",
> > "reason": "Booted", "domain_name": "generic", "domain_id":
> > "8ff7047b-fb46-44ff-a4c6-7c20c73ab86e"}
> > {"event_type": "Defined", "timestamp": "2016-11-25T11:59:53.435530Z",
> > "reason": "Added", "domain_name": "generic", "domain_id":
> > "8ff7047b-fb46-44ff-a4c6-7c20c73ab86e"}
> >
> > It is strange that a VM already boots before it is defined. Is this the
> > intended order?
>
> I don't see this order so probable this is fixed upstream.
>

On latest master a normal creation emits these events:

event 'lifecycle' for domain testvm: Resumed Unpaused
event 'lifecycle' for domain testvm: Started Booted

The Resumed event looks wrong. Further I get no more Defined/Undefined
events. Maybe they were removed?


>
> >
> > 2) Defining a VM with VIR_DOMAIN_START_PAUSED gives me this event order
>
> I don't think you can define a domain with that flag. What's the actual
> action?
>

That is the flag for the api, when using virsh using `--paused` does that.


>
> >
> > {"event_type": "Defined", "timestamp": "2016-11-25T12:02:44.037817Z",
> > "reason": "Added", "domain_name": "core_node", "domain_id":
> > "b9906489-6d5b-40f8-a742-ca71b2b84277"}
> > {"event_type": "Resumed", "timestamp": "2016-11-25T12:02:44.813104Z",
> > "reason": "Unpaused", "domain_name": "core_node", "domain_id":
> > "b9906489-6d5b-40f8-a742-ca71b2b84277"}
> > {"event_type": "Started", "timestamp": "2016-11-25T12:02:44.813733Z",
> > "reason": "Booted", "domain_name": "core_node", "domain_id":
> > "b9906489-6d5b-40f8-a742-ca71b2b84277"}
>
>
> Interesting, so here is "defined" event delivered before the "started"
> event. Also - where is "suspended" event?
>


With latest master the situation looks better. Now I see

event 'lifecycle' for domain testvm: Started Booted
event 'lifecycle' for domain testvm: Suspended Paused


>
> >
> > This boot-order makes it hard to track active domains by listening to
> > life-cycle events. One could theoretically still always fetch the VM
> state
> > in the event callback and check the state, but if the state is not
> > immediately transferred with the event itself, it can already be
> outdated,
> > so this might be racy (intransparent for the libvirt bindings user), and
> as
> > described in (3) currently not even possible. In general the real
> existing
> > events seem to differ quite significantly from the described life-cycle
> in
> > [1].
>
> Again, in the upstream I see something different:
> event 'lifecycle' for domain $domain: Started Booted
> event 'lifecycle' for domain $domain: Suspended Paused
>
>
On master I see that too when I start the VM with `virsh create --paused`.


>
> >
> > 3) "Defined" event is triggered before the domain is completely defined
> >
> > {"event_type": "Defined", "timestamp": "2

[libvirt] Libvirt domain event usage and consistency

[Roman Mohr]

Hi,

I recently started to use the libvirt domain events. With them I increase
the responsiveness of my VM state wachers.
In general it works pretty well. I just listen to the events and do a
periodic resync to cope with missed events.

While watching the events I ran into a few interesting situations I wanted
to share. The points 1-3 describe some minor issues or irregularities.
Point 4 is about the fact that domain and state updates are not versioned
which makes it very hard to stay in sync with libvirt when using events.

My libvirt version is 1.2.18.4.

1) Event order seems to be weird on startup:

When listening for VM lifecycle events I get this order:

{"event_type": "Started", "timestamp": "2016-11-25T11:59:53.209326Z",
"reason": "Booted", "domain_name": "generic", "domain_id":
"8ff7047b-fb46-44ff-a4c6-7c20c73ab86e"}
{"event_type": "Defined", "timestamp": "2016-11-25T11:59:53.435530Z",
"reason": "Added", "domain_name": "generic", "domain_id":
"8ff7047b-fb46-44ff-a4c6-7c20c73ab86e"}

It is strange that a VM already boots before it is defined. Is this the
intended order?

2) Defining a VM with VIR_DOMAIN_START_PAUSED gives me this event order

{"event_type": "Defined", "timestamp": "2016-11-25T12:02:44.037817Z",
"reason": "Added", "domain_name": "core_node", "domain_id":
"b9906489-6d5b-40f8-a742-ca71b2b84277"}
{"event_type": "Resumed", "timestamp": "2016-11-25T12:02:44.813104Z",
"reason": "Unpaused", "domain_name": "core_node", "domain_id":
"b9906489-6d5b-40f8-a742-ca71b2b84277"}
{"event_type": "Started", "timestamp": "2016-11-25T12:02:44.813733Z",
"reason": "Booted", "domain_name": "core_node", "domain_id":
"b9906489-6d5b-40f8-a742-ca71b2b84277"}

This boot-order makes it hard to track active domains by listening to
life-cycle events. One could theoretically still always fetch the VM state
in the event callback and check the state, but if the state is not
immediately transferred with the event itself, it can already be outdated,
so this might be racy (intransparent for the libvirt bindings user), and as
described in (3) currently not even possible. In general the real existing
events seem to differ quite significantly from the described life-cycle in
[1].

3) "Defined" event is triggered before the domain is completely defined

{"event_type": "Defined", "timestamp": "2016-11-25T12:02:44.037817Z",
"reason": "Added", "domain_name": "core_node", "domain_id":
"b9906489-6d5b-40f8-a742-ca71b2b84277"}
{"event_type": "Resumed", "timestamp": "2016-11-25T12:02:44.813104Z",
"reason": "Unpaused", "domain_name": "core_node", "domain_id":
"b9906489-6d5b-40f8-a742-ca71b2b84277"}
{"event_type": "Started", "timestamp": "2016-11-25T12:02:44.813733Z",
"reason": "Booted", "domain_name": "core_node", "domain_id":
"b9906489-6d5b-40f8-a742-ca71b2b84277"}

When I try to process the first event and do a xmldump I get:

   Event: [Code-42] [Domain-10] Domain not found: no domain with matching
uuid 'b9906489-6d5b-40f8-a742-ca71b2b84277' (core_node)

So it seems like I get the event before the domain is completely ready.

4) There libvirt domain description is not versioned

I would expect that every time I update a domainxml (update from third
party entity), or an event is generated (update from libvirt), that the
resource version of a Domain is increased and that I get this resource
version when I do a xmldump or when I get an event. Without this there is
afaik no way to stay in sync with libvirt, even if you do regular polling
of all domains. The main issue here is that I can never know if events in
the queue arrived before my latest domain resync or after it.

Also not that this is not about delivery guarantees of events. It is just
about having a consistent view of a VM and the individual event. If I have
resource versions, I can decide if an event is still interesting for me or
not, which is exactly what I need to solve the syncing problem above.
When I do a complete relisting of all domains to syn, I know which version
I got and I can then see on every event if it is newer or older.

If along side with the event, the domain xml, the VM state, and the
resource version would be sent to a client, it would be even better. Then,
whenever there is a new event for a VM in the queue, I can be sure that
this domainxml I see is the one which triggered the event. This xml is then
a complete representation for this revision number.


Would be nice to hear your thoughts to these points.

Best Regards,
Roman

[1]
https://wiki.libvirt.org/page/VM_lifecycle#States_that_a_guest_domain_can_be_in
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Nice golang bindings for libvirt

[Roman Mohr]

Hi Martin,

On Tue, Sep 6, 2016 at 11:30 AM, Martin Kletzander <mklet...@redhat.com>
wrote:

> On Mon, Sep 05, 2016 at 05:44:03PM +0200, Roman Mohr wrote:
>
>> Hi all,
>>
>> I have been using these pretty nice libvirt-binding library for golang
>> [1].
>> It is under active development, pretty well maintained and has a very nice
>> travis setup to run tests against libvirt [2].
>>
>> I was wondering if the bindings could be added to [3] on libvirt.org.
>>
>>
> Hi, it's great to hear that.  We'd love to add those to the list.  Would
> you mind sending a patch to libvirt against 'docs/bindings.html.in'
> file?


Done [4].


>   That page needs heavy updating, but I can take care of the rest.
> If you don't feel like updating it, just let me know and I'll add it in
> while updating the old info that's there.
>
>
Thanks,

Roman


> Have a nice day,
> Martin
>
>
> Best Regards,
>> Roman
>>
>>
>> [1] https://github.com/rgbkrk
>> [2] https://github.com/rgbkrk/libvirt-go/blob/master/.travis.yml
>> [3] https://libvirt.org/bindings.html
>>
>
> [4]
https://www.redhat.com/archives/libvir-list/2016-September/msg00130.html


> --
>> libvir-list mailing list
>> libvir-list@redhat.com
>> https://www.redhat.com/mailman/listinfo/libvir-list
>>
>
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] docs: Add libvirt-go Go bindings to binding page

[Roman Mohr]

Signed-off-by: Roman Mohr <rm...@redhat.com>
---
 docs/bindings.html.in | 4 
 1 file changed, 4 insertions(+)

diff --git a/docs/bindings.html.in b/docs/bindings.html.in
index 95cfe25..7fe26df 100644
--- a/docs/bindings.html.in
+++ b/docs/bindings.html.in
@@ -14,6 +14,10 @@
 C#: Arnaud Champion develops
 C# bindings.
   
+ 
+Go: Kyle Kelley et al. are developing
+https://github.com/rgbkrk/libvirt-go;>Go bindings.
+  
   
 Java: Daniel Veillard develops
 Java bindings.
-- 
2.5.5

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list