From: D. Herrendoerfer d.herrendoer...@herrendoerfer.name
currently upon a migration a callback is created when a 802.1qbg link
is set to PREASSOCIATE, this should not happen because this is
a no-op on most switches, and does not lead to an ASSOCIATE state.
This patch only creates callbacks when
From: D. Herrendoerfer d.herrendoer...@herrendoerfer.name
This patch adds a netlink callback when migrating a VEPA enabled
virtual machine.
It fixes a Bug where a VM would not request a port association when
it was cleared by lldpad.
This patch requires the latest git version of lldpad to work
On Mar 23, 2012, at 7:21 PM, Laine Stump wrote:
Related to this patch - while looking at the uses of
virNetDevVPortProfileAssociate(), I found the function
qemuMigrationVPAssociatePortProfiles() in src/qemu/qemu_migration.c.
It
calls virNetDevVPortProfileAssociate() without ever calling
From: D. Herrendoerfer d.herrendoer...@herrendoerfer.name
When libvirtd is restarted, also restart the netlink event
message callbacks for existing VEPA connections and send
a message to lldpad for these existing links, so it learns
the new libvirtd pid.
This patch includes the nits sent by Laine
From: D. Herrendoerfer d.herrendoer...@herrendoerfer.name
When libvirtd is restarted, also restart the netlink event
message callbacks for existing VEPA connections and send
a message to lldpad for these existing links, so it learns
the new libvirtd pid.
This only includes qemu support as a base
From: D. Herrendoerfer d.herrendoer...@herrendoerfer.name
When libvirtd is restarted, also restart the netlink event
message callbacks for existing VEPA connections and send
a message to lldpad for these existing links, so it learns
the new libvirtd pid.
Note: This Patch provides fixes
On Feb 29, 2012, at 5:36 PM, Laine Stump wrote:
On 02/24/2012 09:29 AM, D. Herrendoerfer wrote:
The callback mechanism is not re-armed when libvirt is restarted now.
The reason is: lldpad remembers who sent the associate by pid - since
in theory there could be multiple agents performing
On Feb 29, 2012, at 9:51 AM, Laine Stump wrote:
Since I found a couple other problems, but have made you suffer
through
enough back and forth already, I've made some final suggested changes
myself, and am sending a diff patch as a response to this message
(differences from your latest
From: D. Herrendoerfer d.herrendoer...@herrendoerfer.name
this patch adds the changes proposed by Laine Stump to
netlink event code.
Signed-off-by: D. Herrendoerfer d.herrendoer...@herrendoerfer.name
---
src/util/virnetdevmacvlan.c | 47 +-
src/util
On Feb 23, 2012, at 11:16 PM, Laine Stump wrote:
On 02/22/2012 08:17 AM, D. Herrendoerfer wrote:
From: D. Herrendoerfer d.herrendoer...@herrendoerfer.name
Add de-association handling for 802.1qbg (vepa) via lldpad
netlink messages. Also adds the possibility to perform an
association request
On Feb 24, 2012, at 3:29 PM, D. Herrendoerfer wrote:
On Feb 23, 2012, at 11:16 PM, Laine Stump wrote:
On 02/22/2012 08:17 AM, D. Herrendoerfer wrote:
From: D. Herrendoerfer d.herrendoer...@herrendoerfer.name
Add de-association handling for 802.1qbg (vepa) via lldpad
netlink messages. Also
From: D. Herrendoerfer d.herrendoer...@herrendoerfer.name
Add de-association handling for 802.1qbg (vepa) via lldpad
netlink messages. Also adds the possibility to perform an
association request without waiting for a confirmation.
Signed-off-by: D. Herrendoerfer d.herrendoer
From: D. Herrendoerfer d.herrendoer...@herrendoerfer.name
This code adds a netlink event interface to libvirt.
It is based upon the event_poll code and makes use of
it. An event is generated for each netlink message sent
to the libvirt pid.
Signed-off-by: D. Herrendoerfer d.herrendoer
From: D. Herrendoerfer d.herrendoer...@herrendoerfer.name
This is the updated netlink event code based upon the updated
virnetlink.[ch] files.
Also the related code to virnetdevmacvlan is included as well
as the related changes to the setup code.
D. Herrendoerfer (2):
util: Add netlink event
From: D. Herrendoerfer d.herrendoer...@herrendoerfer.name
This code adds a netlink event interface to libvirt.
It is based upon the event_poll code and makes use of
it. An event is generated for each netlink message sent
to the libvirt pid.
Signed-off-by: D. Herrendoerfer d.herrendoer
From: D. Herrendoerfer d.herrendoer...@herrendoerfer.name
This is the updated netlink event code based upon the updated
virnetlink.[ch] files. Most of the previous remarks have been
addressed. This has also seen some preliminary testing.
D. Herrendoerfer (1):
util: Add netlink event handling
From: D. Herrendoerfer d.herrendoer...@herrendoerfer.name
To Laines (!) reply, this is the renamed code, I will base my
further work on this. I hope I didn't oversee anything.
DirkH
D. Herrendoerfer (1):
Rename netlink.[ch] to virnetlink.[ch]
po/POTFILES.in |2 +-
po
From: D. Herrendoerfer d.herrendoer...@herrendoerfer.name
This is the second version of the netlink event code. it has most of
the proposed changes by Eric and Daniel included.
DirkH
D. Herrendoerfer (1):
Add netlink message event service
daemon/libvirtd.c|9 +
src/Makefile.am
On Jan 26, 2012, at 5:57 PM, Daniel P. Berrange wrote:
On Fri, Jan 20, 2012 at 03:56:26PM +0100, D. Herrendoerfer wrote:
From: D. Herrendoerfer d.herrendoer...@herrendoerfer.name
This code adds an event service for netlink messages addressed
to libvirt and passes the message to registered
From: D. Herrendoerfer d.herrendoer...@herrendoerfer.name
Make macvtap setup code register a callback to handle link status
changes sent by lldpad.
This is prototype code for reference only.
Signed-off-by: D. Herrendoerfer d.herrendoer...@herrendoerfer.name
---
src/util/virnetdevmacvlan.c
From: D. Herrendoerfer d.herrendoer...@herrendoerfer.name
I'd like to put this up for discussion.
This is the prototype for netlink events as discussed before,
it follows the design of the event_poll functions.
Included is the unfinished prototype netlink event callback for
virnetdevmacvtap.c
From: D. Herrendoerfer d.herrendoer...@herrendoerfer.name
This code adds an event service for netlink messages addressed
to libvirt and passes the message to registered callback handlers.
Itself, it makes use of the polling file event service and follows
a similar design.
Signed-off-by: D
Daniel, Eric
On Jan 5, 2012, at 6:35 PM, Daniel P. Berrange wrote:
Thank you very much for the introduction, I've spent the
week digging through the code and have a way better
understanding of the difference in the handling of events
now.
Any event loop callback must be sure to complete in
Sorry to come back on this.
How are the different threads of the libvirt daemon separated ?
I understand that there are 2 separate threads running that are
forked. There are also 4 more that appear to be threads.
Is that correct ?
Now, the virEvents main polling loop is running in a forked
,
this is a very linux specific thing, and the asynchronous nature of the
request handling makes starting the monitor thread later on difficult.
Thoughts, ideas ?
D. Herrendoerfer
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Aug 23, 2011, at 12:50 PM, Daniel P. Berrange wrote:
[...snip...]
This makes using SRIOV VFs via PCI passthrough very unpalatable. The
problem can be solved by setting the MAC address of the ethernet
device prior to assigning it to the guest, but of course the
hostdev element used to
On Jun 24, 2011, at 9:34 AM, Michal Privoznik wrote:
3) Similarly for macvtap networks, will the network-wide bandwidth
limiting be applied to the physical ethernet device? This would
have the
side effect of including host traffic on that interface in the
bandwidth
totals, but I don't
Hi to all,
there is a problem present in libvirt that when a PASSTHROUGH mode
DIRECT
NIC connection is made the MAC address of the NIC is not automatically
set
and reset to the configured VM MAC and back again.
The attached patch fixes this problem by setting and resetting the MAC
while
,
Dirk
On May 18, 2011, at 4:22 PM, Eric Blake wrote:
On 05/18/2011 05:32 AM, D. Herrendoerfer wrote:
destination
device is in codeprivate/code mode./dd
+ dtcodepassthru/code/dt
+ ddThis feature allows to attach a virtual function of a
SRIOV
capable
That patch looks fine
On May 18, 2011, at 10:53 AM, Daniel Veillard wrote:
On Tue, May 17, 2011 at 08:19:17PM -0600, Eric Blake wrote:
On 05/17/2011 05:26 AM, D. Herrendoerfer wrote:
This patch includes the documentation part.
The error returned by libvirt when a using an older kernel
is imho sufficient to point
On May 11, 2011, at 12:21 AM, Eric Blake wrote:
Missing corresponding documentation in docs/formatdomain.html.in to
describe the new mode.
What happens if you try to use this mode but you have an older kernel?
Do we need to add any sanity checking to give a saner error message
than
just
Hi all,
starting with kernel 2.6.38 macvtap supports a 'passthru' mode for
attaching virtual functions
of a SRIOV capable network card directly to a VM.
This patch adds the capability to configure such a device.
Signed-off-by: Dirk Herrendoerfer d.herrendoerfer at
herrendoerfer.name
diff
:
On Thu, Dec 02, 2010 at 02:47:15PM +0100, D. Herrendoerfer wrote:
This a basic implemantation to support the net_cls feature of
cgroups. It adds the setting of a net_cls.classid value to the
existing cgroups setup in the qemu driver.
The classid is specified in the qemu.conf file.
This enables
This a basic implemantation to support the net_cls feature of
cgroups. It adds the setting of a net_cls.classid value to the
existing cgroups setup in the qemu driver.
The classid is specified in the qemu.conf file.
This enables the use of the tc utility to manage traffic from/to
vitual
soon.
Regards,
Dirk
On Nov 22, 2010, at 8:23 PM, D. Herrendoerfer wrote:
On Nov 22, 2010, at 2:21 PM, Daniel P. Berrange wrote:
On Thu, Nov 18, 2010 at 04:22:49PM +0100, D. Herrendoerfer wrote:
Hello,
I'm looking into the possibility of putting a network(tc) classID
into
to the domain
On Nov 22, 2010, at 2:21 PM, Daniel P. Berrange wrote:
On Thu, Nov 18, 2010 at 04:22:49PM +0100, D. Herrendoerfer wrote:
Hello,
I'm looking into the possibility of putting a network(tc) classID
into
to the domain description and adding it into a (possibly) mounted
cgroup directory upon
entry to look somewhat like:
domain type='qemu'
name foo/name
uuid3e3fce45-4f53-4fa7-bb32-11f34168b82b /uuid
...
classid0x1234/classid
...
Thoughts ?
Best regards,
D. Herrendoerfer
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
37 matches
Mail list logo
