[libvirt] [PATCH 4/5] macvtap support for libvirt -- helper code
by Stefan Berger
This part adds the helper code to setup and tear down macvtap devices
using direct communication with the device driver via netlink sockets.
The rather short messages received from the netlink layer are now written
into a dynamically allocated buffer.
Signed-off-by: Stefan Berger <stefanb(a)us.ibm.com>
14 years, 10 months
[libvirt] [PATCH 3/5] macvtap support for libvirt -- qemu support
by Stefan Berger
This part adds support for qemu making a macvtap tap device available
via file descriptor passed to qemu command line. This also attempts to
tear down the macvtap device when a VM terminates. This includes support
for attachment and detachment to/from running VM.
Signed-off-by: Stefan Berger <stefanb(a)us.ibm.com>
14 years, 10 months
[libvirt] [PATCH 1/5] macvtap support for libvirt -- build support
by Stefan Berger
This patch adds build support for libvirt checking for certain contents
of /usr/include/linux/if_link.h to see whether macvtap support is
compilable on that system. One can disable macvtap support in libvirt
via --without-macvtap passed to configure.
Signed-off-by: Stefan Berger <stefanb(a)us.ibm.com>
14 years, 10 months
[libvirt] [PATCH] virStorageBackendIsMultipath: avoid dead store
by Jim Meyering
This suppresses a warning reported by clang.
Since "target_type" is initialized, there's no point
in storing dm_get_next_target's return value.
>From d0cd9b4233194b27fb168e835223dd51e77fa6f2 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering(a)redhat.com>
Date: Thu, 11 Feb 2010 15:26:37 +0100
Subject: [PATCH] virStorageBackendIsMultipath: avoid dead store
* src/storage/storage_backend_mpath.c (virStorageBackendIsMultipath):
The result of dm_get_next_target was never used (and isn't needed),
so don't store it.
---
src/storage/storage_backend_mpath.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/storage/storage_backend_mpath.c b/src/storage/storage_backend_mpath.c
index dbcd6d8..1e7504b 100644
--- a/src/storage/storage_backend_mpath.c
+++ b/src/storage/storage_backend_mpath.c
@@ -1,7 +1,7 @@
/*
* storage_backend_mpath.c: storage backend for multipath handling
*
- * Copyright (C) 2009-2009 Red Hat, Inc.
+ * Copyright (C) 2009-2010 Red Hat, Inc.
* Copyright (C) 2009-2008 Dave Allan
*
* This library is free software; you can redistribute it and/or
@@ -150,7 +150,6 @@ virStorageBackendIsMultipath(const char *devname)
{
int ret = 0;
struct dm_task *dmt = NULL;
- void *next = NULL;
uint64_t start, length;
char *target_type = NULL;
char *params = NULL;
@@ -173,8 +172,7 @@ virStorageBackendIsMultipath(const char *devname)
goto out;
}
- next = dm_get_next_target(dmt, next, &start, &length,
- &target_type, ¶ms);
+ dm_get_next_target(dmt, next, &start, &length, &target_type, ¶ms);
if (target_type == NULL) {
ret = -1;
--
1.7.0.rc2.170.gbc565
14 years, 10 months
[libvirt] [PATCH 3/5] macvtap support for libvirt -- qemu support
by Stefan Berger
This part adds support for qemu making a macvtap tap device available
via file descriptor passed to qemu command line. This also attempts to
tear down the macvtap device when a VM terminates. This includes support
for attachment and detachment to/from running VM.
Signed-off-by: Stefan Berger <stefanb(a)us.ibm.com>
14 years, 10 months
[libvirt] [PATCH 0/5] macvtap support for Qemu/KVM VMs via libvirt
by Stefan Berger
Hello!
This is a re-post of previously posted patches following Daniel
Berrange's request for changes along with other fixes.
The following patches provide support for making the macvtap
networking device type available to Qemu/KVM VMs. The patches rely on
the macvtap driver that just became available through the Linux net-next
tree (fixes still may be necessary) and make the device available to
Qemu/KVM via a tap file descriptor similar to a 'regular' tap device.
Following up on previous discussions, the libvirt patches allow using
the following XML in the domain description to enable qemu network
connectivity via this type of device:
<interface type='direct'>
<source dev='eth1' mode='vepa'/>
<model type='virtio'/>
</interface>
The above XML indicates that eth1 is the Ethernet interface to link
the macvtap device to and communicate to the network. As a consequence,
libvirt will create an instance of a macvtap device, assign it the same
MAC address as the VM's interface has and open a file descriptor of the
associated character device /dev/tap%d and pass it via command line to
Qemu/kvm. In the above XML the mode can be chosen as 'vepa', 'private'
or 'bridge' and is by default set to 'vepa'(by the driver) if omitted.
Attachment and detachment of macvtap to/from a running VM also works.
Regards,
Stefan
14 years, 10 months