[libvirt] [PATCHv4 0/4] Add initial support for reverting snapshots
by Peter Krempa
I'm reposting another version of the series. This version fixes small mistakes
in patches 1-3 and reposts patch 4 as it got missing due to a sending error.
Peter Krempa (4):
qemu: Split out guts of qemuDomainSaveImageStartVM() to allow reuse
snapshot: Add flag VIR_DOMAIN_SNAPSHOT_REVERT_STOPPED
snapshot: Add flag to allow hypervisor restart when reverting
snapshots
snapshot: qemu: Implement reverting of external snapshots
include/libvirt/libvirt.h.in | 3 +
src/libvirt.c | 36 ++--
src/qemu/qemu_driver.c | 389 ++++++++++++++++++++++++++++++++++++++++---
tools/virsh-snapshot.c | 7 +
tools/virsh.pod | 19 ++-
5 files changed, 410 insertions(+), 44 deletions(-)
--
1.8.0
12 years
[libvirt] libvirt RBD attach regression?
by Scott Sullivan
Hello,
I have been testing libvirt v1.0.0 for deployment within my
organization, and in the process discovered what appears to be a bug
that breaks virsh attach-device, when attaching an RBD volume to an
instance. First, here is the error presented, with v1.0.0 (this worked
in v0.10.2):
[root@host ~]# virsh attach-device W5APQ8 G84VV1.xml
error: Failed to attach device from G84VV1.xml
error: cannot open file 'dc3-1-test/G84VV1': No such file or directory
[root@host ~]#
W5APQ8 is my running QEMU/KVM instance, and G84VV1.xml contains the
following:
<disk type='network' device='disk'>
<driver name='qemu' type='raw'/>
<auth username="removed">
<secret type="ceph" uuid="removed"/>
</auth>
<source protocol='rbd' name='dc3-1-test/G84VV1'>
<host name="X.X.X.X" port="6789"/>
<host name="X.X.X.X" port="6789"/>
<host name="X.X.X.X" port="6789"/>
</source>
<target dev='vdc' bus='virtio'/>
<serial>hpbs-G84VV1</serial>
</disk>
Using git bisect, I narrowed the problem down to this as the first
commit to break this setup:
4d34c92947e8cf9e9bedfa227ada1d2dba92d68a is the first bad commit
commit 4d34c92947e8cf9e9bedfa227ada1d2dba92d68a
Author: Eric Blake <eblake(a)redhat.com>
Date: Tue Oct 9 16:08:14 2012 -0600
These all look closely related as well to the problem commit:
http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=67aea3fb780346b4aa5a...
http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=38c4a9cc40476bd2e598...
http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=4d34c92947e8cf9e9bed...
If I build libvirt from sources before these commits and then run the
exact virsh-attach command shown above, the attachment works and I do
not get any errors.
I wanted to see if anyone had any insights on this, or perhaps a commit
to correct this issue. If I can be of any further assistance with this,
let me know.
Thanks,
Scott Sullivan
12 years
[libvirt] [libvirt-glib] gobject: Also delete storage volume from its pool's list
by Zeeshan Ali (Khattak)
From: "Zeeshan Ali (Khattak)" <zeeshanak(a)gnome.org>
Without this patch, storage pool still lists the volume even after it is
deleted.
Related Boxes bug: https://bugzilla.gnome.org/show_bug.cgi?id=688724
---
libvirt-gobject/libvirt-gobject-storage-pool.c | 23 +++++++++++++++++++++++
libvirt-gobject/libvirt-gobject-storage-vol.c | 4 ++++
2 files changed, 27 insertions(+)
diff --git a/libvirt-gobject/libvirt-gobject-storage-pool.c b/libvirt-gobject/libvirt-gobject-storage-pool.c
index 8f579a1..df7e77c 100644
--- a/libvirt-gobject/libvirt-gobject-storage-pool.c
+++ b/libvirt-gobject/libvirt-gobject-storage-pool.c
@@ -29,6 +29,7 @@
#include "libvirt-glib/libvirt-glib.h"
#include "libvirt-gobject/libvirt-gobject.h"
#include "libvirt-gobject-compat.h"
+#include "libvirt-gobject-storage-pool-private.h"
#define GVIR_STORAGE_POOL_GET_PRIVATE(obj) \
(G_TYPE_INSTANCE_GET_PRIVATE((obj), GVIR_TYPE_STORAGE_POOL, GVirStoragePoolPrivate))
@@ -1129,3 +1130,25 @@ gboolean gvir_storage_pool_delete_finish(GVirStoragePool *pool,
return TRUE;
}
+
+G_GNUC_INTERNAL gboolean gvir_storage_pool_delete_vol(GVirStoragePool *pool,
+ GVirStorageVol *volume)
+{
+ GVirStoragePoolPrivate *priv;
+ gboolean ret = FALSE;
+
+ g_return_val_if_fail(GVIR_IS_STORAGE_POOL(pool), FALSE);
+ g_return_val_if_fail(GVIR_IS_STORAGE_VOL(volume), FALSE);
+
+ priv = pool->priv;
+ g_mutex_lock(priv->lock);
+ if (priv->volumes != NULL) {
+ const gchar *name = gvir_storage_vol_get_name(volume);
+ ret = g_hash_table_remove(priv->volumes, name);
+ } else {
+ g_warn_if_reached();
+ }
+ g_mutex_unlock(priv->lock);
+
+ return ret;
+}
diff --git a/libvirt-gobject/libvirt-gobject-storage-vol.c b/libvirt-gobject/libvirt-gobject-storage-vol.c
index c7ebb45..4352d30 100644
--- a/libvirt-gobject/libvirt-gobject-storage-vol.c
+++ b/libvirt-gobject/libvirt-gobject-storage-vol.c
@@ -29,6 +29,7 @@
#include "libvirt-glib/libvirt-glib.h"
#include "libvirt-gobject/libvirt-gobject.h"
#include "libvirt-gobject-compat.h"
+#include "libvirt-gobject-storage-pool-private.h"
#define GVIR_STORAGE_VOL_GET_PRIVATE(obj) \
(G_TYPE_INSTANCE_GET_PRIVATE((obj), GVIR_TYPE_STORAGE_VOL, GVirStorageVolPrivate))
@@ -309,6 +310,9 @@ gboolean gvir_storage_vol_delete(GVirStorageVol *vol,
g_return_val_if_fail(GVIR_IS_STORAGE_VOL(vol), FALSE);
g_return_val_if_fail(err == NULL || *err == NULL, FALSE);
+ if (!gvir_storage_pool_delete_vol(vol->priv->pool, vol))
+ return FALSE;
+
if (virStorageVolDelete(vol->priv->handle, flags) < 0) {
gvir_set_error_literal(err,
GVIR_STORAGE_VOL_ERROR,
--
1.8.0
12 years
[libvirt] RFC: Migration with NPIV
by Osier Yang
Hi,
This proposal is trying to figure out a solution for migration
of domain which uses LUN behind vHBA as disk device (QEMU
emulated disk only at this stage). And other related NPIV
improvements which are not related with migration. I'm not
luck to get a environment to test if the thoughts are workable,
but I'd like see if guys have good idea/suggestions earlier.
1) Persistent vHBA support
This is the useful stuff missed for long time. Assuming
that one created a vHBA, did masking/zoning, everything works
as expected. However, after a system rebooting, everything is
just lost. If the user wants to get things back, he has to
find out the preivous WWNN & WWPN, and create the vHBA again.
On the other hand, Persistent vHBA support is actually required
for domain which uses LUN behind a vHBA. Othewise the domain
could fail to start after a system rebooting.
To support the persistent vHBA, new APIs like virNodeDeviceDefineXML,
virNodeDeviceUndefine is required. Also it's useful to introduce
"autostart" for vHBA, so that the vHBA could be started automatically
after system rebooting.
Proposed APIs:
virNodeDevicePtr
virNodeDeviceDefineXML(virConnectPtr conn,
const char *xml,
unsigned int flags);
int
virNodeDeviceUndefine(virConnectPtr conn,
virNodeDevicePtr dev,
unsigned int flags);
int
virNodeDeviceSetAutostart(virNodeDevicePtr dev,
int autostart,
unsigned int flags);
int
virNodeDeviceGetAutostart(virNodeDevicePtr dev,
int *autostart,
unsigned int flags);
2) Associate vHBA with domain XML
There are two ways to attach a LUN to a domain: as an QEMU emulated
device; or passthrough. Since passthrough a LUN is not supported in
libvirt yet, let's focus on the emulated LUN at this stage.
New attributes "wwnn" and "wwpn" are introduced to indicate the
LUN behind the vHBA. E.g.
<disk type='block' device='disk'>
<driver name='qemu' type='raw'/>
<source wwnn="2001001b32a9da4e" wwpn="2101001b32a90004"/>
<target dev='vda' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07'
function='0x0'/>
</disk>
Before the domain starting, we have to check if there is LUN
assigned to the vHBA, error out if not.
Using the stable path of LUN also works, e.g.
<source dev="/dev/disk/by-path/pci-0000\:00\:07.0-scsi-0\:0\:0\:0"/>
But the disadvantage is the user have to figure out the stable
path himself; And we have to do checking of every stable path to
see if it's behind a vHBA in migration "Begin" stage. Or an new
XML tag for element "source" to indicate that it's behind a vHBA?
such as:
<source dev="disk-by-path" model="vport"/>
3) Migration with vHBA
One possible solution for migration with vHBA is to use one pair
of WWNN & WWPN on source host, one is using for domain, one is
reserved for migration purpose. It requires the storage admin maps
the same LUN to the two vHBAs when doing the masking and zoning.
One of the two vHBA is called "Primary vHBA", another is called
"secondary vHBA". To maitain the relationship between these two
vHBAs, we have to introduce new XMLs to vHBA. E.g.
In XML of primary vHBA:
<secondary wwpn="2101001b32a90004"/>
In XML of secondary vHBA:
<primary wwpn="2101001b32a90002"/>
Primary vHBA is going to be guaranteed not used by any domain which
is driven by libvirt (we do some checking eariler before the domain
starting). And it's also guaranteed that the LUN can't be used by
other domain with sVirt or Sanlock. So it's safe to have two vHBAs
on source host too.
To prevent one using the LUN by creating vHBA using the same WWNN &
WWPN on another host, we must create the secondary vHBA on source
host, even it's not being used.
Both primary and secondary vHBA must be defined and marked as
"autostart" so that the domain could be started after system
rebooting.
When do migration, we have to bake a bigger cookie with secondary
vHBA's info (basically it's WWNN and WWPN) in migration "Begin"
stage, and eat that in migration "Prepare" stage on target host.
In "Begin" stage, the XMLs represents the secondary vHBA is
constructed. And the secondary vHBA is destoyed on source host,
not undefined though.
In "Prepare" stage, a new vHBA is created (define and start)
on target host with the same WWNN & WWPN as secondary vHBA on
source host. The LUN then should be visible to target host
automatically? and thus migration can be performed. After migration
is finished on target host, the primary vHBA on source host is
destroyed, not undefined.
If migration fails, the new vHBA created on target host will
be destroyed and undefined. And both primary and secondary
vHBA on source host will be started, so that the domain could
be resumed.
Finally if migration succeeds, primary vHBA on source host
will be transtered to target host as secondary vHBA (defined).
And both primary and secondary vHBA on source host will be
undefined.
4) Enrich HBA's XML
It's hard to known the vHBAs created from a HBA with current
implementation. One have to dump XML of each (v)HBAs and find
out the clue with element "parent" of vHBAs. It's good to introduce
new element for HBA like "vports", so that one can easily known
what (how many) vHBAs are created from the HBA?
And also it's good to have the maximum vports the HBA supports.
Except these, other useful information should be exposed too,
such as the vendor name, the HBA state, PCI address, etc.
The new XMLs should be like:
<vports num='2' max='64'>
<vport name="scsi_host40" wwpn="2101001b32a90004"/>
<vport name="scsi_host40" wwpn="2101001b32a90005"/>
</vports>
<online/>
<vendor>QLogic</vendor>
<address type="pci" domain="0" bus="0" slot="5" function="0"/>
"online", "vendor", "address" make sense to vHBA too.
5) Improve the way to lookup LUN's stable path
Currently, to lookup the LUN's stable path with WWNN & WWPN,
it needs to iterate over the sysfs each time, maintaining the
stable path in vHBA's XML doesn't make sense, as the LUN assigned
to the vHBA could be changed as the storage admin's mood. I'm
wondering if there is a way to notify the change asynchronously,
if there is, then maintaining the stable path internally make
sense.
6) Miscellaneous
This is only about QEMU emulated device, passthroughed scsi_host
with vHBA is still not covered, we have to support the vHBA passthough
first. The good thing is the solution should be similiar.
Regards,
Osier
12 years
[libvirt] [libvirt-glib] Return an error when virConnectGetVersion returns 0
by Christophe Fergeau
virConnectGetVersion can return 0 'if the version can't be extracted
by lack of capabilities'. I've also seen it return 0 when libvirtd
1.0 is running but virsh 0.10.2 is used to get the version.
gvir_connection_get_version is documented as returning 0 on error.
However, currently it only sets the corresponding GError when
virConnectGetVersion returns -1. Makes sure the GError is also
set when 0 is returned. The old behaviour was causing a crash
in conn-test as this assumes that the GError will be set when
gvir_connection_get_version returns 0.
---
libvirt-gobject/libvirt-gobject-connection.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/libvirt-gobject/libvirt-gobject-connection.c b/libvirt-gobject/libvirt-gobject-connection.c
index 3157a66..91cc535 100644
--- a/libvirt-gobject/libvirt-gobject-connection.c
+++ b/libvirt-gobject/libvirt-gobject-connection.c
@@ -1108,6 +1108,12 @@ gvir_connection_get_version(GVirConnection *conn,
if (virConnectGetVersion(priv->conn, &ret) < 0) {
gvir_set_error_literal(err, GVIR_CONNECTION_ERROR, 0,
"Unable to get hypervisor version");
+ ret = 0;
+ } else if (ret == 0) {
+ /* From virConnectGetVersion doc: "if the version can't be
+ * extracted by lack of capacities returns 0 and @hvVer is 0" */
+ g_set_error_literal(err, GVIR_CONNECTION_ERROR, 0,
+ "Unknown hypervisor version");
}
cleanup:
--
1.8.0
12 years
[libvirt] [PATCH] Use virNetServerRun instead of custom main loop
by Daniel P. Berrange
From: "Daniel P. Berrange" <berrange(a)redhat.com>
The LXC controller code currently directly invokes the
libvirt main loop code. The problem is that this misses
the cleanup of virNetServerClient connections that
virNetServerRun takes care of.
The result is that when libvirtd is stopped, the
libvirt_lxc controller process gets stuck in a I/O loop.
When libvirtd is then started again, it fails to connect
to the controller and thus kills of the entire domain.
Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com>
---
src/lxc/lxc_controller.c | 33 ++++++++++++++-------------------
1 file changed, 14 insertions(+), 19 deletions(-)
diff --git a/src/lxc/lxc_controller.c b/src/lxc/lxc_controller.c
index 4746897..aec2d4c 100644
--- a/src/lxc/lxc_controller.c
+++ b/src/lxc/lxc_controller.c
@@ -97,6 +97,8 @@ struct _virLXCControllerConsole {
char fromHostBuf[1024];
size_t fromContLen;
char fromContBuf[1024];
+
+ virNetServerPtr server;
};
typedef struct _virLXCController virLXCController;
@@ -278,6 +280,7 @@ static int virLXCControllerAddConsole(virLXCControllerPtr ctrl,
virReportOOMError();
return -1;
}
+ ctrl->consoles[ctrl->nconsoles-1].server = ctrl->server;
ctrl->consoles[ctrl->nconsoles-1].hostFd = hostFd;
ctrl->consoles[ctrl->nconsoles-1].hostWatch = -1;
@@ -663,12 +666,11 @@ static int lxcControllerClearCapabilities(void)
return 0;
}
-static bool quit = false;
static bool wantReboot = false;
static virMutex lock;
-static void virLXCControllerSignalChildIO(virNetServerPtr server ATTRIBUTE_UNUSED,
+static void virLXCControllerSignalChildIO(virNetServerPtr server,
siginfo_t *info ATTRIBUTE_UNUSED,
void *opaque)
{
@@ -678,8 +680,8 @@ static void virLXCControllerSignalChildIO(virNetServerPtr server ATTRIBUTE_UNUSE
ret = waitpid(-1, &status, WNOHANG);
if (ret == ctrl->initpid) {
+ virNetServerQuit(server);
virMutexLock(&lock);
- quit = true;
if (WIFSIGNALED(status) &&
WTERMSIG(status) == SIGHUP)
wantReboot = true;
@@ -731,7 +733,7 @@ static void virLXCControllerConsoleUpdateWatch(virLXCControllerConsolePtr consol
VIR_DEBUG(":fail");
virReportSystemError(errno, "%s",
_("Unable to add epoll fd"));
- quit = true;
+ virNetServerQuit(console->server);
goto cleanup;
}
console->hostEpoll = events;
@@ -742,8 +744,8 @@ static void virLXCControllerConsoleUpdateWatch(virLXCControllerConsolePtr consol
if (epoll_ctl(console->epollFd, EPOLL_CTL_DEL, console->hostFd, NULL) < 0) {
virReportSystemError(errno, "%s",
_("Unable to remove epoll fd"));
- VIR_DEBUG(":fail");
- quit = true;
+ VIR_DEBUG(":fail");
+ virNetServerQuit(console->server);
goto cleanup;
}
console->hostEpoll = 0;
@@ -768,7 +770,7 @@ static void virLXCControllerConsoleUpdateWatch(virLXCControllerConsolePtr consol
virReportSystemError(errno, "%s",
_("Unable to add epoll fd"));
VIR_DEBUG(":fail");
- quit = true;
+ virNetServerQuit(console->server);
goto cleanup;
}
console->contEpoll = events;
@@ -779,8 +781,8 @@ static void virLXCControllerConsoleUpdateWatch(virLXCControllerConsolePtr consol
if (epoll_ctl(console->epollFd, EPOLL_CTL_DEL, console->contFd, NULL) < 0) {
virReportSystemError(errno, "%s",
_("Unable to remove epoll fd"));
- VIR_DEBUG(":fail");
- quit = true;
+ VIR_DEBUG(":fail");
+ virNetServerQuit(console->server);
goto cleanup;
}
console->contEpoll = 0;
@@ -809,7 +811,7 @@ static void virLXCControllerConsoleEPoll(int watch, int fd, int events, void *op
continue;
virReportSystemError(errno, "%s",
_("Unable to wait on epoll"));
- quit = true;
+ virNetServerQuit(console->server);
goto cleanup;
}
@@ -926,7 +928,7 @@ error:
virEventRemoveHandle(console->contWatch);
virEventRemoveHandle(console->hostWatch);
console->contWatch = console->hostWatch = -1;
- quit = true;
+ virNetServerQuit(console->server);
virMutexUnlock(&lock);
}
@@ -995,14 +997,7 @@ static int virLXCControllerMain(virLXCControllerPtr ctrl)
}
}
- virMutexLock(&lock);
- while (!quit) {
- virMutexUnlock(&lock);
- if (virEventRunDefaultImpl() < 0)
- goto cleanup;
- virMutexLock(&lock);
- }
- virMutexUnlock(&lock);
+ virNetServerRun(ctrl->server);
err = virGetLastError();
if (!err || err->code == VIR_ERR_OK)
--
1.7.11.7
12 years
[libvirt] [PATCH] v1: allow guest to guest IPv6 without gateway definition
by Gene Czarcinski
This patch adds the capability for virtual guests to do IPv6
communication via a virtual network interface with no IPv6
(gateway) addresses specified. This capability currently
exists for IPv4.
This patch allows creation of a completely isolated IPv6 network.
Note that virtual guests cannot communication with the virtualization
host via this interface. Also note that:
net.ipv6.conf.<interface_name>.disable_ipv6 = 1
---
docs/formatnetwork.html.in | 18 ++++++++++++++++++
src/network/bridge_driver.c | 22 ++++++++++++++--------
2 files changed, 32 insertions(+), 8 deletions(-)
diff --git a/docs/formatnetwork.html.in b/docs/formatnetwork.html.in
index 49206dd..7b3b25c 100644
--- a/docs/formatnetwork.html.in
+++ b/docs/formatnetwork.html.in
@@ -773,5 +773,23 @@
</forward>
</network></pre>
+ <h3><a name="examplesNoGateway">Network config with no gateway addresses</a></h3>
+
+ <p>
+ A valid network definition can contain no IPv4 or IPv6 addresses. Such a definition
+ can be used for a "very private" or "very isolated" network since it will not be
+ possible to communicate with the virtualization host via this network. However,
+ this virtual network interface can be used for communication between virtual guest
+ systems. This works for IPv4 and <span class="since">(Since 1.0.1)</span> IPv6.
+ </p>
+
+ <pre>
+ <network>
+ <name>nogw</name>
+ <uuid>7a3b7497-1ec7-8aef-6d5c-38dff9109e93</uuid>
+ <bridge name="virbr2" stp="on" delay="0" />
+ <mac address='00:16:3E:5D:C7:9E'/>
+ </network></pre>
+
</body>
</html>
diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c
index c153d36..9c67348 100644
--- a/src/network/bridge_driver.c
+++ b/src/network/bridge_driver.c
@@ -1568,15 +1568,16 @@ networkRemoveRoutingIptablesRules(struct network_driver *driver,
}
}
-/* Add all once/network rules required for IPv6 (if any IPv6 addresses are defined) */
+/* Add all once/network rules required for IPv6.
+ * Even if no IPv6 addresses are defined, allow IPv6 commuinications
+ * between virtual systems. If any IPv6 addresses are defined, then
+ * add the rules for regular operation.
+ */
static int
networkAddGeneralIp6tablesRules(struct network_driver *driver,
virNetworkObjPtr network)
{
- if (!virNetworkDefGetIpByIndex(network->def, AF_INET6, 0))
- return 0;
-
/* Catch all rules to block forwarding to/from bridges */
if (iptablesAddForwardRejectOut(driver->iptables, AF_INET6,
@@ -1604,6 +1605,10 @@ networkAddGeneralIp6tablesRules(struct network_driver *driver,
goto err3;
}
+ /* if no IPv6 addresses are defined, we are done. */
+ if (!virNetworkDefGetIpByIndex(network->def, AF_INET6, 0))
+ return 0;
+
/* allow DNS over IPv6 */
if (iptablesAddTcpInput(driver->iptables, AF_INET6,
network->def->bridge, 53) < 0) {
@@ -1640,11 +1645,12 @@ static void
networkRemoveGeneralIp6tablesRules(struct network_driver *driver,
virNetworkObjPtr network)
{
- if (!virNetworkDefGetIpByIndex(network->def, AF_INET6, 0))
- return;
+ if (virNetworkDefGetIpByIndex(network->def, AF_INET6, 0)) {
+ iptablesRemoveUdpInput(driver->iptables, AF_INET6, network->def->bridge, 53);
+ iptablesRemoveTcpInput(driver->iptables, AF_INET6, network->def->bridge, 53);
+ }
- iptablesRemoveUdpInput(driver->iptables, AF_INET6, network->def->bridge, 53);
- iptablesRemoveTcpInput(driver->iptables, AF_INET6, network->def->bridge, 53);
+ /* the following rules are there even if no IPv6 address has been defined */
iptablesRemoveForwardAllowCross(driver->iptables, AF_INET6, network->def->bridge);
iptablesRemoveForwardRejectIn(driver->iptables, AF_INET6, network->def->bridge);
iptablesRemoveForwardRejectOut(driver->iptables, AF_INET6, network->def->bridge);
--
1.7.11.7
12 years
[libvirt] [RFC] Porting Qemu driver to FreeBSD
by Roman Bogorodskiy
Hi,
Recently I have picked up Sean's and Hiren's activities in porting
Qemu driver on FreeBSD.
At this point I have the basics working. Meaning that these things
work:
- Basic host commands (version, nodeinfo, etc)
- Can perform basic operations on the VM (start, stop, destroy, etc)
- Basic bridging (bridge creation/removing, adding/removing interfaces,
setting addresses etc)
Currently I keep FreeBSD specific info here:
https://github.com/novel/fbsd-libvirt/blob/freebsd/README-freebsd
There are a number things to be done:
- Firewall support. Currently I have just disabled iptables calls
and add general ipfw NAT rules for all VMs.
This appears to be the most tough part for me at this point for
a number of reasons:
* FreeBSD has two widely used firewall packages: pf and ipfw.
I'm not sure if they play nice together, e.g. if I choose
to use ipfw, people that have pf configuration will have
problems making libvirt work with their existing setup
* Need to design a general schema for injection of the rules
so they don't harm existing setup
ipfw seems to be more appealing for automatic control via
external applications like libvirt, but I'm still not sure
how to organise rulesets.
- Affinity stuff needs to be implemented
- Code needs a lot of clean-up, needs to be refactored to
extract common cross-platfrom code, etc
- NWFilter stuff needs to be implemented (this is sort of a long
term goal)
The code is available here: https://github.com/novel/fbsd-libvirt/tree/freebsd
Current changes could be observed here:
https://github.com/novel/fbsd-libvirt/compare/upstream_master...freebsd
I would appreciate your thoughts and feedback on that topic.
Thanks
Roman Bogorodskiy
12 years
Re: [libvirt] messed up with xml-files and configuration of a VM
by Stefan Hajnoczi
On Tue, Nov 20, 2012 at 5:13 PM, Lentes, Bernd
<bernd.lentes(a)helmholtz-muenchen.de> wrote:
> first, i'm new to kvm. I'm running KVM on a sles 11 sp2, kernel 3.0.13-0.27-default. My guest is an Ubuntu 12.0.4 LTS 64bit.
> The guest has attached a CDROM, using an iso-file from a CIFS-Share. I detached it with the virtual machine manager (0.9.0).
> I don't see the cd-rom anymore in the virtual machine manager. But when i try to start the vm, it complains about the missing iso-file.
> Why ? I detached it.
> When i like to have a look in the xml-files of the guest, i found three ! One in /var/lib/kvm/images, one in /etc/libvirt/qemu and one in /etc/kvm/vm.
> Which one should i use to configure the vm ? In the one in /etc/libvirt/qemu the cifs-share isn't mentioned any longer, in the other two it is still.
> Is it possible to configure the vm editing one of the XML-files ?
> Or shall i use virsh ? Using virsh, does the vm has to be stopped or can i edit the configuration for a running vm ?
> Why three xml-files ? Why is detaching with the virtual machine manager not working ?
Hi Bernd,
This is a libvirt question, I have CCed the libvirt mailing list.
Do not edit the XML files on disk. Instead, use virsh edit (to
modify) and virsh dumpxml (to view).
Stefan
12 years
