[libvirt] PATCH: Improve some remote driver error messages
Bug reports from users have shown diagnosing problems with the remote
driver are quite tricky, so I've been looking at improving its error
messages where possible. There's a number of places where we simply
pass in strerror(errno) as the only data in virRaiseError. This doesn't
let us narrow down just which call failed - we just get a generic message
Permission denied or Connection refused with no clue what was being
tried.
This patch adds descriptive error messages whereever possible, fixes a
place where we'd report an error to connect to IPv4 even if IPv6
succeeded, and adds some missing translations
Before
$ virsh --connect qemu:///system
libvir: Remote error : Permission denied
$ virsh --connect qemu+tcp:///system
libvir: Remote error : Connection refused
$ virsh --connect qemu+tcp://wibble/system
libvir: Remote error : invalid argument in Name or service not known
After
$ ./src/virsh --connect qemu:///system
libvir: Remote error : unable to connect to '/var/run/libvirt/libvirt-sock':
Permission denied
$ ./src/virsh --connect qemu+tcp:///system
libvir: Remote error : unable to connect to 'localhost': Connection refused
$ ./src/virsh --connect qemu+tcp://wibble/system
libvir: Remote error : unable to resolve hostname 'wibble': Name or service
not known
Daniel
Index: src/remote_internal.c
===
RCS file: /data/cvs/libvirt/src/remote_internal.c,v
retrieving revision 1.80
diff -u -r1.80 remote_internal.c
--- src/remote_internal.c 26 Jun 2008 09:37:51 - 1.80
+++ src/remote_internal.c 19 Aug 2008 10:36:32 -
@@ -371,13 +371,12 @@
priv-hostname = strdup (uri-server ? uri-server : localhost);
-if (!priv-hostname) {
-error (NULL, VIR_ERR_NO_MEMORY, _(allocating priv-hostname));
-goto failed;
-}
+if (!priv-hostname)
+goto out_of_memory;
if (uri-user) {
username = strdup (uri-user);
-if (!username) goto out_of_memory;
+if (!username)
+goto out_of_memory;
}
/* Get the variables from the query string.
@@ -491,12 +490,15 @@
// http://people.redhat.com/drepper/userapi-ipv6.html
struct addrinfo *res, *r;
struct addrinfo hints;
+int saved_errno = EINVAL;
memset (hints, 0, sizeof hints);
hints.ai_socktype = SOCK_STREAM;
hints.ai_flags = AI_ADDRCONFIG;
int e = getaddrinfo (priv-hostname, port, hints, res);
if (e != 0) {
-error (conn, VIR_ERR_INVALID_ARG, gai_strerror (e));
+errorf (conn, VIR_ERR_SYSTEM_ERROR,
+_(unable to resolve hostname '%s': %s),
+priv-hostname, gai_strerror (e));
goto failed;
}
@@ -516,7 +518,7 @@
priv-sock = socket (r-ai_family, SOCK_STREAM, 0);
if (priv-sock == -1) {
-error (conn, VIR_ERR_SYSTEM_ERROR, strerror (socket_errno ()));
+saved_errno = socket_errno();
continue;
}
@@ -526,7 +528,7 @@
sizeof no_slow_start);
if (connect (priv-sock, r-ai_addr, r-ai_addrlen) == -1) {
-error (conn, VIR_ERR_SYSTEM_ERROR, strerror (socket_errno ()));
+saved_errno = socket_errno();
close (priv-sock);
continue;
}
@@ -545,6 +547,9 @@
}
freeaddrinfo (res);
+errorf (conn, VIR_ERR_SYSTEM_ERROR,
+_(unable to connect to '%s': %s),
+priv-hostname, strerror (saved_errno));
goto failed;
tcp_connected:
@@ -563,23 +568,23 @@
uid_t uid = getuid();
if (!(pw = getpwuid(uid))) {
-error (conn, VIR_ERR_SYSTEM_ERROR, strerror (errno));
+errorf (conn, VIR_ERR_SYSTEM_ERROR,
+_(unable to lookup user '%d': %s),
+uid, strerror (errno));
goto failed;
}
if (asprintf (sockname, @%s LIBVIRTD_USER_UNIX_SOCKET,
pw-pw_dir) 0) {
-error (conn, VIR_ERR_SYSTEM_ERROR, strerror (errno));
-goto failed;
+sockname = NULL;
+goto out_of_memory;
}
} else {
if (flags VIR_DRV_OPEN_REMOTE_RO)
sockname = strdup (LIBVIRTD_PRIV_UNIX_SOCKET_RO);
else
sockname = strdup (LIBVIRTD_PRIV_UNIX_SOCKET);
-if (sockname == NULL) {
-error (conn, VIR_ERR_SYSTEM_ERROR, strerror (errno));
-goto failed;
-}
+if (sockname == NULL)
+goto out_of_memory;
}
}
@@ -598,7 +603,9 @@
autostart_retry:
[libvirt] PATCH: REmove bogus call to virStateInit in openvz driver
For some unknown reason there is a call to virStateInitialize() in the
openvz driver's open method. This is absolutely forbidden - this API is
only intended for use by the daemon. This patch removes this bogus call
and makes it call the openvz setup APIs directly.
Daniel
diff -r c2e95cd51bc3 src/openvz_driver.c
--- a/src/openvz_driver.c Wed Aug 13 12:50:55 2008 +
+++ b/src/openvz_driver.c Tue Aug 19 12:11:37 2008 +0100
@@ -81,10 +81,6 @@ static int openvzNumDomains(virConnectPt
static int openvzNumDomains(virConnectPtr conn);
static int openvzListDefinedDomains(virConnectPtr conn, char **const names,
int nnames);
static int openvzNumDefinedDomains(virConnectPtr conn);
-static int openvzStartup(void);
-static int openvzShutdown(void);
-static int openvzReload(void);
-static int openvzActive(void);
static virDomainPtr openvzDomainDefineXML(virConnectPtr conn, const char *xml);
static virDomainPtr openvzDomainCreateLinux(virConnectPtr conn, const char
*xml,
@@ -697,7 +693,8 @@ static virDrvOpenStatus openvzOpen(virCo
conn-privateData = ovz_driver;
- virStateInitialize();
+ openvzAssignUUIDs();
+
vms = openvzGetVPSInfo(conn);
ovz_driver.vms = vms;
@@ -849,27 +846,6 @@ Version: 2.2
static int openvzNumDefinedDomains(virConnectPtr conn ATTRIBUTE_UNUSED) {
return ovz_driver.num_inactive;
-}
-
-static int openvzStartup(void) {
-openvzAssignUUIDs();
-
-return 0;
-}
-
-static int openvzShutdown(void) {
-
-return 0;
-}
-
-static int openvzReload(void) {
-
-return 0;
-}
-
-static int openvzActive(void) {
-
-return 1;
}
static virDriver openvzDriver = {
@@ -934,17 +910,8 @@ static virDriver openvzDriver = {
NULL, /* nodeGetFreeMemory */
};
-static virStateDriver openvzStateDriver = {
-openvzStartup,
-openvzShutdown,
-openvzReload,
-openvzActive,
-NULL, /* sigHandler */
-};
-
int openvzRegister(void) {
virRegisterDriver(openvzDriver);
-virRegisterStateDriver(openvzStateDriver);
return 0;
}
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] PATCH: Handle case of no domains in openvz driver
If running the openvz driver on a machine with no containers currently
defined, it throws an error
# ./src/virsh --connect openvz:///system list
libvir: OpenVZ error : internal error Failed to parse vzlist output
Id Name State
--
This is because of a failure to check for the EOF condition. This patch
adds the missing check
Daniel
diff -r 1fc0d8258838 src/openvz_conf.c
--- a/src/openvz_conf.c Tue Aug 19 13:58:56 2008 +0100
+++ b/src/openvz_conf.c Tue Aug 19 13:59:51 2008 +0100
@@ -534,6 +534,9 @@ openvzGetVPSInfo(virConnectPtr conn) {
vm = *pnext;
if (fscanf(fp, %d %s\n, veid, status) != 2) {
+if (feof(fp))
+break;
+
openvzError(conn, VIR_ERR_INTERNAL_ERROR,
_(Failed to parse vzlist output));
goto error;
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Re: virsh/virt-install for dummies
Jun Koi wrote: On Tue, Aug 19, 2008 at 12:00 PM, Cole Robinson [EMAIL PROTECTED] wrote: Jun Koi wrote: On Mon, Aug 18, 2008 at 9:59 PM, Cole Robinson [EMAIL PROTECTED] wrote: Yes, virsh works well: it returns few pages of xml data. However, virt-install still has problem like below. It seems to have some thing with Xen? I dont install Xen on my machine. Could you give some hints to fix this?? Thanks, J # LIBVIRT_DEBUG=1 virt-install -c qemu:///system --name jeos2 --ram 500 --file img.jeos2 --cdrom jeos-8.04.1-jeos-i386.iso That command line has an error, you need to use --connect for the URI, -c == --cdrom. Yes, that was a mistake. I changed -c to --connect, and get the error Unsupported virtualization type now. How can I fix it? Thanks a lot, J # LIBVIRT_DEBUG=1 virt-install --connect qemu:///system --name jeos2 --ram 500 --file img.jeos2 --cdrom jeos-8.04.1-jeos-i386.i The current virt-install release doesn't pick a useful default for virtualization type: it is just hardcoded to use paravirt. Since your host doesn't have paravirt capabilities it is throwing an error. This is fixed upstream: we will default to paravirt only if on a xen host, otherwise we use hvm. You'll need to specify --hvm and --accelerate as cli params if you want to install a kvm guest. Thanks for pointing out this pitfault. I added --hvm and --accelerate to the command, and got the below error. Is it a bug, or smt else? Thanks, J # virt-install --connect qemu:///system --name jeos2 --ram 500 --file img.jeos2 --cdrom jeos-8.04.1-jeos-i386.iso -v --accelerate --debug Tue, 19 Aug 2008 12:17:18 ERRORlist index out of range Traceback (most recent call last): File /usr/bin/virt-install, line 496, in module main() File /usr/bin/virt-install, line 367, in main domain = guest.bestDomainType(options.accelerate) File /usr/lib/python2.5/site-packages/virtinst/CapabilitiesParser.py, line 177, in bestDomainType return self.domains[-1] IndexError: list index out of range Hmm, yeah we should check that and throw a more clear error message. However, the root cause is that your capabilities xml is screwy (posted a few messages back.) There is only a domain element for x86_64 qemu but you're host arch is reported as i686. What libvirt version are you using? What virt-install/python-virtinst version are you using? Is kvm installed? What distro are you on? Thanks, Cole -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 2/5: Fix signal handler race condition
Daniel P. Berrange [EMAIL PROTECTED] wrote: This is the same patch from yesterday to fix the signal handler race condition. We block signals before doing a fork(), and then in the child reset all signal handlers before finally unblocking all signals. The parent will restore its original signal mask after fork. I've fixed the incorrect return code check on pthread_sigmask() and iterate from 1 instead of 0. I'll switch to pid_t later, since that'll involve changing all callers too. In the internal.h file I also #define pthread_sigmask to sigprocmask for scenarios where we don't have pthread - as per other usage. This exposed a bug in remote_protocol.c file where it was not including the config.h file, hence that change here too This looks fine now. ACK. qemud/remote_protocol.c |1 qemud/remote_protocol.h |1 qemud/remote_protocol.x |1 src/internal.h |1 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Re: virsh/virt-install for dummies
On Tue, Aug 19, 2008 at 12:23:15PM -0400, Cole Robinson wrote: However, the root cause is that your capabilities xml is screwy (posted a few messages back.) There is only a domain element for x86_64 qemu but you're host arch is reported as i686. That's perfectly valid. It merely means he's got the qemu-system-x86_64 binary installed on an i686 host. ie QEMU emulating x86_64 arch. Slow as treacle. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Use existing QEMU image with libvirt?
Jun Koi wrote: Hi, I have some existing QEMU images. Now I want to use it with libvirt/virsh. Is there any easy way to do that? I suppose that we need an XML file for each image, but dont want to craft them from scratch. Thanks, Jun There isn't really an official way to do this, but we will probably add some explicit support for it to virt-install or virt-manager down the line. You can try something like this (obviously this is dependent on your previous virt-install troubles being fixed): virt-install --name somename --ram 256 --vnc \ --hvm --accelerate \ --cdrom /some/existing/file \ --file /path/to/existing/image \ The vnc console should pop up, but if you just pointed to some useless file for cdrom boot will fail (which is fine). Just kill virt-install, run 'virsh destroy somename' (this will hard poweroff the VM), and the VM should be good to go for future runs. - Cole -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] libvirt-java: change org.libvirt.Error implementing Serializable
Hi java-api-team (-:
could you please let org.libvirt.Error implements the serializable interface ?
Exceptions (and the content like org.libvirt.Error) should be serializable.
I got an exception on my host system connected via RMI to the client-system
running libvirt-java (libvirt-java, cvs-snapshot 2008-08-18) like this:
...
cause:java.rmi.UnmarshalException: Error unmarshaling return; nested exception
is:
java.io.WriteAbortedException: writing aborted;
java.io.NotSerializableException: org.libvirt.Error
package org.libvirt;
public class Error {
VIR_FROM_NONE,
/**
* Error at Xen hypervisor layer
*/
VIR_FROM_XEN,
thank you very much
regards
Danny
---
DT Netsolution GmbH - Taläckerstr. 30-D-70437 Stuttgart
Geschäftsführer: Daniel Schwager, Stefan Hörz - HRB Stuttgart 19870
Tel: +49-711-849910-32, Fax: -932 - Mailto:[EMAIL PROTECTED]
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] networking
Hello, I'm having trouble digging up some documentation on libvirt's network config. I'm not sure where to set this up, but I have a bridged device br0 that I would like to have available in virt-manager/virsh. Right now, I can edit the VM's xml interface element manually to use br0. Virt-manager has an option for shared physical device, but it's empty, and I can't figure out how to see it from virsh. thanks -jim -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 3/5: Allow FD for stdout/err to be passed in
Daniel P. Berrange [EMAIL PROTECTED] wrote:
The contract for virExec() currently allows the caller to pass in a NULL
for stdout/err parameters in which case the child will be connected to
/dev/null, or they can pass in a pointer to an int, in which case the
child will be connected to a pair of pipes, and the read end of the pipe
is returned to the caller.
The LXC driver will require a 3rd option - we want to pass in a existing
file handler connected to a logfile. So this patch extends the semantics
of these two parameters. If the stderr/out params are non-NULL, but are
initialized to -1, then a pipe will be allocated. If they are = 0, then
they are assumed to be existing FDs to dup onto the child's stdout/err.
This change neccessitated updating all existing callers of virExec to
make sure they initialize the parameters to -1 to maintain existing
behaviour.
ACK
No technical problems...
so here are some stylistic suggestions
diff -r 100b059a8488 src/openvz_driver.c
--- a/src/openvz_driver.c Tue Aug 12 22:12:38 2008 +0100
+++ b/src/openvz_driver.c Tue Aug 12 22:12:42 2008 +0100
@@ -736,7 +736,7 @@
static int openvzListDomains(virConnectPtr conn, int *ids, int nids) {
int got = 0;
-int veid, pid, outfd, errfd;
+int veid, pid, outfd = -1, errfd = -1;
I find this formatting a little easier to read/maintain:
[e.g., with each declaration on a separate line, independent changes to
veid and errfd might not conflict, but they surely would when they're
all on the same line. ]
int veid;
int pid;
int outfd = -1;
int errfd = -1;
int ret;
char buf[32];
char *endptr;
@@ -772,7 +772,7 @@
static int openvzListDefinedDomains(virConnectPtr conn,
char **const names, int nnames) {
int got = 0;
-int veid, pid, outfd, errfd, ret;
+int veid, pid, outfd = -1, errfd = -1, ret;
char vpsname[OPENVZ_NAME_MAX];
char buf[32];
char *endptr;
diff -r 100b059a8488 src/qemu_driver.c
--- a/src/qemu_driver.c Tue Aug 12 22:12:38 2008 +0100
+++ b/src/qemu_driver.c Tue Aug 12 22:12:42 2008 +0100
@@ -948,6 +948,8 @@
if (safewrite(vm-logfile, \n, 1) 0)
qemudLog(QEMUD_WARN, _(Unable to write argv to logfile %d: %s\n),
errno, strerror(errno));
+
+vm-stdout_fd = vm-stderr_fd = -1;
Same here, putting the common bits one above the other
makes it easier to see the parts that vary:
vm-stdout_fd = -1;
vm-stderr_fd = -1;
ret = virExecNonBlock(conn, argv, vm-pid,
vm-stdin_fd, vm-stdout_fd, vm-stderr_fd);
diff -r 100b059a8488 src/util.c
--- a/src/util.c Tue Aug 12 22:12:38 2008 +0100
+++ b/src/util.c Tue Aug 12 22:12:42 2008 +0100
@@ -110,6 +110,7 @@
int pid, null, i;
int pipeout[2] = {-1,-1};
int pipeerr[2] = {-1,-1};
+int childout = -1, childerr = -1;
And here:
int childout = -1;
int childerr = -1;
sigset_t oldmask, newmask;
struct sigaction sig_action;
@@ -132,39 +133,66 @@
goto cleanup;
}
-if ((outfd != NULL pipe(pipeout) 0) ||
-(errfd != NULL pipe(pipeerr) 0)) {
-ReportError(conn, VIR_ERR_INTERNAL_ERROR,
-_(cannot create pipe: %s), strerror(errno));
-goto cleanup;
+if (outfd != NULL) {
+if (*outfd == -1) {
+if (pipe(pipeout) 0) {
+ReportError(conn, VIR_ERR_INTERNAL_ERROR,
+_(cannot create pipe: %s), strerror(errno));
Maybe s/cannot/Failed to/?
The latter is slightly stronger/clearer,
and consistent with other messages.
+goto cleanup;
+}
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] On shutdown Destroy/Delete
Hi, I would really like to know how I can make a defined domain *gone* after shutdown :) (instead of it still be defined, after shutdown) Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 4/5: Support daemonizing child env variables
On Tue, Aug 19, 2008 at 10:51:29PM +0200, Jim Meyering wrote:
Daniel P. Berrange [EMAIL PROTECTED] wrote:
Some of the existing usage of fork/exec in libvirt is done such that the
child process is daemonized. In particular the libvirt_proxy and the
auto-spawned libvirtd for qemu:///session. Since we want to switch these
to use virExec, we need to suport a daemon mode.
This patch removes the two alternate virExec and virExecNonBlock functions
and renames the internal __virExec to virExec. It then gains a 'flags'
parameter which can be used to specify non-blocking mode, or daemon mode.
We also add the ability to pass in a list of environment variables which
get passed on to execve(). We also now explicitly close all file handles.
Although libvirt code is careful to set O_CLOSEXEC on all its file handles,
in multi-threaded apps there is a race condition between opening a FD and
setting O_CLOSEXEC. Furthermore, we can't guarentee that all applications
using libvirt are careful to set O_CLOSEXEC. Leaking FDs to a child is a
potential security risk and often causes SELinux AVCs to be raised. Thus
explicitely closing all FDs is a important safety net.
How about closing those FDs in the child instead, right after the fork?
Then, if a virExec caller has an open socket or file descriptor,
it won't be closed behind its back.
This is being done after a fork(). The diff context in this patch is
a little misleading. The fork() shown here is the 2nd optional fork() done
in daemon mode. The first fork() is higher up before we close the FDs.
diff -r 28ddf9f5791c src/util.c
...
+for (i = 3; i openmax; i++)
+if (i != infd
+i != null
+i != childout
+i != childerr)
+close(i);
+
+if (flags VIR_EXEC_DAEMON) {
+if (setsid() 0) {
+ReportError(conn, VIR_ERR_INTERNAL_ERROR,
+_(cannot become session leader: %s),
+strerror(errno));
+_exit(1);
+}
+
+if (chdir(/) 0) {
+ReportError(conn, VIR_ERR_INTERNAL_ERROR,
+_(cannot change to root directory: %s),
+strerror(errno));
+_exit(1);
+}
+
+pid = fork();
...
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 4/5: Support daemonizing child env variables
Daniel P. Berrange [EMAIL PROTECTED] wrote: On Tue, Aug 19, 2008 at 10:51:29PM +0200, Jim Meyering wrote: Daniel P. Berrange [EMAIL PROTECTED] wrote: Some of the existing usage of fork/exec in libvirt is done such that the child process is daemonized. In particular the libvirt_proxy and the auto-spawned libvirtd for qemu:///session. Since we want to switch these to use virExec, we need to suport a daemon mode. This patch removes the two alternate virExec and virExecNonBlock functions and renames the internal __virExec to virExec. It then gains a 'flags' parameter which can be used to specify non-blocking mode, or daemon mode. We also add the ability to pass in a list of environment variables which get passed on to execve(). We also now explicitly close all file handles. Although libvirt code is careful to set O_CLOSEXEC on all its file handles, in multi-threaded apps there is a race condition between opening a FD and setting O_CLOSEXEC. Furthermore, we can't guarentee that all applications using libvirt are careful to set O_CLOSEXEC. Leaking FDs to a child is a potential security risk and often causes SELinux AVCs to be raised. Thus explicitely closing all FDs is a important safety net. How about closing those FDs in the child instead, right after the fork? Then, if a virExec caller has an open socket or file descriptor, it won't be closed behind its back. This is being done after a fork(). The diff context in this patch is a little misleading. The fork() shown here is the 2nd optional fork() done in daemon mode. The first fork() is higher up before we close the FDs. I should have known. Next time I'll review with the full context. ACK, then. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] networking
James Bardin wrote: I'm not sure where to set this up, but I have a bridged device br0 that I would like to have available in virt-manager/virsh. Right now, I can edit the VM's xml interface element manually to use br0. AFAIK, you're doing the right thing (as long as you're doing a dump-xml to get the XML description out and then a define to put the updated one in; directly modifying /etc/libvirt/qemu/* is bad form). Personally, I use xmlstarlet [from shell scripts] or lxml [from python] to automate tweaking the XML host descriptions, but the details are your own call. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
