Re: [libvirt] Update on host interface configuration
On Tue, Feb 24, 2009 at 11:06:02PM +, David Lutterkort wrote:
On Tue, 2009-02-24 at 18:24 +0200, Dan Kenigsberg wrote:
I know I'm arriving very late to this discussion and should have read
it all before posting, but...
The project I'm working on wanted to be able to setup network
configuration without making persistant changes to configuration files.
This would allow testing if everything works well, and reboot without
fear if things got broken. The greatest fear when configuring network
remotely, is being locked out of your host.
Do you plan something like this feature in netcf?
No, not for netcf or libvirt. The host interface mgmt uses the
distribution's native network scripts, which implies that all config
changes are changes to those scripts.
The fundamental difficulty with providing some sort of rollback
functionality at the libvirt level is that libvirt has no idea whether
the new config is working or not, and doesn't know how to test it. So
any (syntactically valid) configuration of a network interface is as
good as any other from libvirt's POV.
That means that this type of functionality really belongs in a layer
above libvirt - the API (will) make it pretty easy though to implement
that: if you know that the current config for an interface is
good/working, just do something like
goodConfig = virInterfaceGetXmlDesc(..);
virInterfaceDefine(newConfig);
virInterfaceRestart(ifaceName);
The real issue is, that in this stage, management may have lost
connectivity to the node.
if (! newConfigIsWorking()) {
virInterfaceDefine(goodConfig);
virInterfaceRestart(ifaceName);
}
How about having netcf/libvirt be aware of what is a goodConfig (with
additional API verb), and back it up somewhere? Any change to to network
configuration would have immediate effect, but unless explicitly set as
good, reverted on next boot.
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvirt tls vnc
On Thu, Feb 26, 2009 at 10:47:37PM +0100, Michael Kress wrote: My questions: 1) Isn't there a more comfortable end user compatible method to connect to the beast? (Because with this method, users obviously are urged to have Linux on the client side. Or would the purchase of real vnc enterprise edition would be the solution there?) This is an ongoing area of development. The VeNCrypt extension provides two core capabilities - Data encryption of the session (only server CA certs required) - Crude authentication (if using client clients too) For Fedora 11, I have been working on integrating SASL as an additional authenication mechanism. This provides a pluggable system for auth methods, which includes such things as - Username/password auth against PAM, LDAP, SQL database - One time passwords - GSSAPI Kerberos single sign on https://fedoraproject.org/wiki/Features/VirtVNCAuth Most of the auth methods require that you already have a secure data channel, so you'd have to layer them over the VeNCrypt extension. The last GSSAPI though is particularly interesting, because GSSAPI also provides data encryption, avoiding any need for VeNCRypt. So you will have a wide variety of options for accessing VNC - VNC on localhost, access remotely over SSH, authenticate VNC with any SASL auth method - VNC on public IP addr, using TLS for encryption, and any SASL auth method - VNC on public IP addr, using GSSAPI SASL auth method for auth and encryption 2) I simulated an interested user owning a certificate and walked through the different screens of the host (before, I created a few). I could easily access them by just chosing to connect to localhost:0 localhost:1 ... (given the requirement to have an ssh tunnel which the client machine easily can build) Is it possible to let him only view what he's supposed to? How? In libvirt we do not yet any a way to setup per-VM access control lists. This is the next item on the TODO list 3) Is there a way to stick one certificate to one virtual machine? e.g. stick client-cert-user001.pem to /etc/libvirt-bin/qemu/user001-vm01.xml (trying to find a solution to question 2) with this question). You wouldn't really want todo this. All VMs on a host should typically use the same certificate. To get per-user access control, we need libvirt to get some kind of per-VM allow/deny list. You can see more about what i'm experimenting with here http://lists.gnu.org/archive/html/qemu-devel/2009-02/msg01426.html 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: 0/3: Run QEMU guests within a CGroup
On Thu, Feb 26, 2009 at 10:40:54PM +, David Lutterkort wrote: On Thu, 2009-02-26 at 16:36 +, Daniel P. Berrange wrote: Recent Linux kernels have a new concept of 'CGroups' which is a way to group tasks on the system and apply policy to them as a whole. We already use this in the LXC container driver, to control total memory usage of things runing within a container. This patch series is a proof of concept to make use of CGroups in the QEMU driver. The idea is that we have a 3 level cgroup hierarchy - Top level; contains the libvirtd daemon itself - 2nd level: one per libvirt driver, but dos not contain any processes. - 3rd level: one per guest VM. Contains the QEMU process Why the separate group for the driver ? Do you see partitioning of resources by driver as an important requirement ? It is mostly a namespacing issue. The per-VM group names on the filesystem are based off the VM name. VM names are only unique within scope of a driver. Since both LXC and QEMU drivers use CGroups, we need to make sure they have separate namespace in cgroups. A per-driver cgroup solves this nicely. 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
[libvirt] [PATCH]: Fix non-live migration failure
There is a logic error in the Qemu driver when doing a non-live migrate.
During a non-live migrate, on the source host during the Perform step, we
pause the domain; however, if there was ever a failure, we were forgetting
to unpause the domain, meaning that the domain was paused forever. Add a
flag to tell us when we should unpause the domain after a failure.
Also, as pointed out by DV, we were unnecessarily using a snprintf to a
buffer to execute qemu monitor commands, when we could get away with
just sending a static string. Fix that as well.
Signed-off-by: Chris Lalancette clala...@redhat.com
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index a8a2ae7..11782b4 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -4331,6 +4331,7 @@ qemudDomainMigratePerform (virDomainPtr dom,
char cmd[HOST_NAME_MAX+50];
char *info = NULL;
int ret = -1;
+int paused = 0;
qemuDriverLock(driver);
vm = virDomainFindByID(driver-domains, dom-id);
@@ -4348,10 +4349,14 @@ qemudDomainMigratePerform (virDomainPtr dom,
if (!(flags VIR_MIGRATE_LIVE)) {
/* Pause domain for non-live migration */
-snprintf(cmd, sizeof cmd, %s, stop);
-qemudMonitorCommand (vm, cmd, info);
+if (qemudMonitorCommand (vm, stop, info) 0) {
+qemudReportError(dom-conn, dom, NULL, VIR_ERR_OPERATION_FAILED,
+ %s, _(off-line migration specified, but suspend operation failed));
+goto cleanup;
+}
DEBUG (stop reply: %s, info);
VIR_FREE(info);
+paused = 1;
event = virDomainEventNewFromObj(vm,
VIR_DOMAIN_EVENT_SUSPENDED,
@@ -4396,6 +4401,7 @@ qemudDomainMigratePerform (virDomainPtr dom,
/* Clean up the source domain. */
qemudShutdownVMDaemon (dom-conn, driver, vm);
+paused = 0;
event = virDomainEventNewFromObj(vm,
VIR_DOMAIN_EVENT_STOPPED,
@@ -4407,7 +4413,31 @@ qemudDomainMigratePerform (virDomainPtr dom,
ret = 0;
cleanup:
+/* Note that we have to free info *first*, since we are re-using the
+ * variable below (and otherwise might cause a memory leak)
+ */
VIR_FREE(info);
+
+if (paused) {
+/* we got here through some sort of failure; start the domain again */
+if (qemudMonitorCommand (vm, cont, info) 0) {
+/* Hm, we already know we are in error here. We don't want to
+ * overwrite the previous error, though, so we just throw something
+ * to the logs and hope for the best
+ */
+qemudLog(QEMUD_ERROR, _(Failed to resume guest %s after failure\n),
+ vm-def-name);
+}
+else {
+DEBUG (cont reply: %s, info);
+VIR_FREE(info);
+}
+
+event = virDomainEventNewFromObj(vm,
+ VIR_DOMAIN_EVENT_RESUMED,
+ VIR_DOMAIN_EVENT_RESUMED_MIGRATED);
+}
+
if (vm)
virDomainObjUnlock(vm);
if (event)
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvirt tls vnc
Michael Kress napsal(a): Michael Kress wrote: Then I'll give a try on linux and mail the results later. 2009.02.26 19:09:44 LOG7[14644:3086588128]: Certificate: /home/kress/keys/client-cert.pem 2009.02.26 19:09:44 LOG7[14644:3086588128]: Certificate loaded 2009.02.26 19:09:44 LOG7[14644:3086588128]: Key file: /home/kress/keys/client-cert.pem 2009.02.26 19:09:44 LOG3[14644:3086588128]: error stack: 140B3009 : error:140B3009:SSL routines:SSL_CTX_use_RSAPrivateKey_file:PEM lib 2009.02.26 19:09:44 LOG3[14644:3086588128]: SSL_CTX_use_RSAPrivateKey_file: 906D06C: error:0906D06C:PEM routines:PEM_read_bio:no start line vncviewer: VNC server closed connection Is the private key stored in client-cert.pem with the certificate itself? I've noticed you generate client-key.pem but I am not sure whether you combine these two files somewhere. The lines from log state that the private key can not be found in /home/kress/keys/client-cert.pem Radek smime.p7s Description: S/MIME Cryptographic Signature -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] using virsh remotely
I can use virsh as a command line tool, for exampe virsh list gives me the list of the running machines and I am back to the prompt. When I make virsh -c qemu+ssh://maschine-2/system list I get the list of the running machine on the remote machine-2 - but that's it, I am not back to the prompt automatically. I want virsh to behave used remotely as used locally - execute the command and go back to the prompt. How this can be done? mfg ar -- Hier könnte keine Signatur stehen. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] using virsh remotely
On Fri, Feb 27, 2009 at 03:36:15PM +0100, Andreas Rittershofer wrote: I can use virsh as a command line tool, for exampe virsh list gives me the list of the running machines and I am back to the prompt. When I make virsh -c qemu+ssh://maschine-2/system list I get the list of the running machine on the remote machine-2 - but that's it, I am not back to the prompt automatically. What version of libvirt have you got ? There is a bug in 0.6.0 which causes it to hang when disconnecting from the remote server http://www.redhat.com/archives/libvir-list/2009-February/msg00104.html 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] using virsh remotely
Am 27.02.2009 um 15:40 schrieb Daniel P. Berrange: On Fri, Feb 27, 2009 at 03:36:15PM +0100, Andreas Rittershofer wrote: I can use virsh as a command line tool, for exampe virsh list gives me the list of the running machines and I am back to the prompt. When I make virsh -c qemu+ssh://maschine-2/system list I get the list of the running machine on the remote machine-2 - but that's it, I am not back to the prompt automatically. What version of libvirt have you got ? There is a bug in 0.6.0 which causes it to hang when disconnecting from the remote server http://www.redhat.com/archives/libvir-list/2009-February/msg00104.html I'm using Debian testing and therein is 0.5.1-6. mfg ar -- Hier könnte keine Signatur stehen. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvirt tls vnc
Daniel P. Berrange wrote: You can see more about what i'm experimenting with here http://lists.gnu.org/archive/html/qemu-devel/2009-02/msg01426.html Hello Daniel, Hello Radek, thanks so much for your great help - you've teached me a lot and you have given me a good orientation. What I will follow now is this way: specify allowed port-forwards (ssh tunnels) in the authorized_keys file on the server, as proposed by Radek. Allowed port forwards should be secure enough. Moreover I will go back to non-encrypted vnc which will be listening on 127.0.0.1. Non-encrypted because it will work with standard clients (realvnc+putty). Building up a tunnel is not that difficult, it even can be clicked and written together on one msdos .bat file for the convenience of the (end) user. Anyways, I will follow the development of libvirt and the surrounding products, it seems thrilling to me! :-) Kind regards thanks again Michael -- Michael Kress, kr...@hal.saar.de http://www.michael-kress.de / http://kress.net P E N G U I N S A R E C O O L -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 1/3: Put each QEMU guest in a cgroup
On Thu, Feb 26, 2009 at 04:38:25PM +, Daniel P. Berrange wrote:
This patch sets up the cgroups for QEMU instances. It creates a cgroup
when starting a guest, uses an exec hook to place the process into the
correct cgroup, and cleans up empty cgroup when the QEMU process shuts
down.
@@ -1185,8 +1261,11 @@ static int qemudStartVMDaemon(virConnect
emulator = vm-def-emulator;
if (!emulator)
emulator = virDomainDefDefaultEmulator(conn, vm-def, driver-caps);
-if (!emulator)
-return -1;
+if (!emulator) {
+close(vm-logfile);
+vm-logfile = -1;
+return -1;
+}
/* Make sure the binary we are about to try exec'ing exists.
* Technically we could catch the exec() failure, but that's
@@ -1196,6 +1275,8 @@ static int qemudStartVMDaemon(virConnect
virReportSystemError(conn, errno,
_(Cannot find QEMU binary %s),
emulator);
+close(vm-logfile);
+vm-logfile = -1;
return -1;
}
@@ -1205,7 +1286,14 @@ static int qemudStartVMDaemon(virConnect
qemudReportError(conn, NULL, NULL, VIR_ERR_INTERNAL_ERROR,
_(Cannot determine QEMU argv syntax %s),
emulator);
-return -1;
+close(vm-logfile);
+vm-logfile = -1;
+return -1;
+}
+
+if (qemuSetupCgroup(conn, driver, vm) 0) {
+close(vm-logfile);
+vm-logfile = -1;
}
vm-def-id = driver-nextvmid++;
Seems the logfile changes are cleanups not directly related,
but yes this all looks sounds to me,
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 2/3: Implement schedular params for QEMU
On Thu, Feb 26, 2009 at 04:40:18PM +, Daniel P. Berrange wrote:
This patch implements the schedular parameter APIs. This adds a
single tunable 'cpu_shares' that is provided by cgroups. This is
a slightly more fancy way of doing nice priorities, giving a way
to tune relative priority of VMs
The scheduler API is one of the parts I'm most afraid of from an
API perspective...
[...]
+static int qemuSetSchedulerParameters(virDomainPtr domain,
+ virSchedParameterPtr params,
+ int nparams)
[...]
+for (i = 0; i nparams; i++) {
+virSchedParameterPtr param = params[i];
+
+if (STREQ(param-field, cpu_shares)) {
I think we should also check param-type to be of type
VIR_DOMAIN_SCHED_FIELD_ULLONG before passing value.ui
+if (virCgroupSetCpuShares(group, params[i].value.ui) != 0)
maybe use param-value.ui since we have a pointer handy, avoid
index trouble if the code evolves.
+goto cleanup;
+} else {
+qemudReportError(domain-conn, domain, NULL, VIR_ERR_INVALID_ARG,
+ _(Invalid parameter `%s'), param-field);
+goto cleanup;
+}
+}
+ret = 0;
Patch looks fine otherwise,
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Remove redundant monitorWatch
Daniel P. Berrange wrote:
On Mon, Feb 16, 2009 at 06:42:11PM -0500, Cole Robinson wrote:
For some reason there are two VMDef members being used to keep track of
monitor event handles: monitor_watch and monitorWatch. Remove the latter.
Can you remove the 'monitor_watch' instead - all the other variables
in the domain_conf.h structs use leading capital letters for separating
words, and not underscores.
Yup, sorry for not noticing that before.
Updated patch attached.
Thanks,
Cole
commit a70387b6075d9a9d663a7fb1f9a1309324327bc8
Author: Cole (Work Acct) crobi...@virt1.(none)
Date: Thu Feb 26 22:18:58 2009 -0500
Remove redundant monitor watch variable (s/monitor_watch/monitorWatch/)
diff --git a/src/domain_conf.c b/src/domain_conf.c
index 622665c..603b87b 100644
--- a/src/domain_conf.c
+++ b/src/domain_conf.c
@@ -503,7 +503,7 @@ virDomainObjPtr virDomainAssignDef(virConnectPtr conn,
virDomainObjLock(domain);
domain-state = VIR_DOMAIN_SHUTOFF;
domain-def = def;
-domain-monitor_watch = -1;
+domain-monitorWatch = -1;
domain-monitor = -1;
if (VIR_REALLOC_N(doms-objs, doms-count + 1) 0) {
diff --git a/src/domain_conf.h b/src/domain_conf.h
index b6f6b43..491df06 100644
--- a/src/domain_conf.h
+++ b/src/domain_conf.h
@@ -473,7 +473,6 @@ struct _virDomainObj {
virMutex lock;
int monitor;
-int monitor_watch;
char *monitorpath;
int monitorWatch;
int logfile;
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index a8a2ae7..34854dd 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -775,9 +775,9 @@ static int qemudOpenMonitor(virConnectPtr conn,
goto error;
}
-if ((vm-monitor_watch = virEventAddHandle(vm-monitor, 0,
- qemudDispatchVMEvent,
- driver, NULL)) 0)
+if ((vm-monitorWatch = virEventAddHandle(vm-monitor, 0,
+ qemudDispatchVMEvent,
+ driver, NULL)) 0)
goto error;
@@ -1329,9 +1329,9 @@ static void qemudShutdownVMDaemon(virConnectPtr conn ATTRIBUTE_UNUSED,
_(Failed to send SIGTERM to %s (%d)),
vm-def-name, vm-pid);
-if (vm-monitor_watch != -1) {
-virEventRemoveHandle(vm-monitor_watch);
-vm-monitor_watch = -1;
+if (vm-monitorWatch != -1) {
+virEventRemoveHandle(vm-monitorWatch);
+vm-monitorWatch = -1;
}
if (close(vm-logfile) 0) {
@@ -1379,7 +1379,7 @@ qemudDispatchVMEvent(int watch, int fd, int events, void *opaque) {
virDomainObjPtr tmpvm = driver-domains.objs[i];
virDomainObjLock(tmpvm);
if (virDomainIsActive(tmpvm)
-tmpvm-monitor_watch == watch) {
+tmpvm-monitorWatch == watch) {
vm = tmpvm;
break;
}
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Mark defined networks as persistent
We aren't setting the persistent bit when a network is defined, so
'destroy' makes them disappear (though they will reappear later since
their persistent config is never removed).
Attached patch fixes this.
Thanks,
Cole
Mark 'defined' networks as persistent.
diff --git a/src/network_conf.c b/src/network_conf.c
index e19f0fe..6ad0d01 100644
--- a/src/network_conf.c
+++ b/src/network_conf.c
@@ -747,6 +747,7 @@ virNetworkObjPtr virNetworkLoadConfig(virConnectPtr conn,
goto error;
net-autostart = autostart;
+net-persistent = 1;
VIR_FREE(configFile);
VIR_FREE(autostartLink);
diff --git a/src/network_driver.c b/src/network_driver.c
index 3c765c8..4b9c666 100644
--- a/src/network_driver.c
+++ b/src/network_driver.c
@@ -1153,6 +1153,8 @@ static virNetworkPtr networkDefine(virConnectPtr conn, const char *xml) {
goto cleanup;
def = NULL;
+network-persistent = 1;
+
if (virNetworkSaveConfig(conn,
driver-networkConfigDir,
network-newDef ? network-newDef : network-def) 0) {
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Account for defined networks when generating bridge names
Daniel P. Berrange wrote:
On Mon, Feb 16, 2009 at 06:40:59PM -0500, Cole Robinson wrote:
diff --git a/src/network_driver.c b/src/network_driver.c
index d750565..d83f902 100644
--- a/src/network_driver.c
+++ b/src/network_driver.c
@@ -812,7 +812,12 @@ static int networkStartNetworkDaemon(virConnectPtr conn,
return -1;
}
-if ((err = brAddBridge(driver-brctl, network-def-bridge))) {
+if (!network-def-bridge
+!(network-def-bridge = virNetworkAllocateBridge(conn,
+
driver-networks)))
+return -1;
+
+if ((err = brAddBridge(driver-brctl, network-def-bridge))) {
This will cause a thread deadlock once you add the locking I describe
for virNetworkBridgeInUse() in the previous patch. This is because
the current virNetworkObjPtr 'network' here will be locked, then
the function you're calling with then try to lock it again.
A deep called function like networkStartNetworkDaemon() shouldn't be
iterating over all network objects, so this is the wrong place to try
and fix this problem.
I'm guessing you're trying to fix up existing defined networks without
a bridge here, so IMHO, this is better done at daemon startup, where
we load all the configs off disk. This will avoid the locking trouble
Do it in 'networkStartup',m just after the virNetworkLoadAllConfigs
call, but before autostart is done.
Okay, I rolled these changes and the BridgeInUse changes into one patch
(along with Jim's suggestions).
I added a helper function SetBridgeName which basically does:
if user passed bridge name:
verify it doesn't collide
else:
generate bridge name
We call this in Define and CreateXML. When loading configs from a driver
restart, we only attempt to generate a bridge: if checking for
collisions failed, the network wouldn't even be defined, which would
only cause more pain for users.
Patch below.
Thanks,
Cole
Generate network bridge names if none passed at define/create time.
diff --git a/src/bridge.c b/src/bridge.c
index 668dcf0..46dc407 100644
--- a/src/bridge.c
+++ b/src/bridge.c
@@ -49,7 +49,7 @@
#include util.h
#include logging.h
-#define MAX_BRIDGE_ID 256
+#define MAX_TAP_ID 256
#define JIFFIES_TO_MS(j) (((j)*1000)/HZ)
#define MS_TO_JIFFIES(ms) (((ms)*HZ)/1000)
@@ -127,32 +127,13 @@ brShutdown(brControl *ctl)
#ifdef SIOCBRADDBR
int
brAddBridge(brControl *ctl,
-char **name)
+const char *name)
{
if (!ctl || !ctl-fd || !name)
return EINVAL;
-if (*name) {
-if (ioctl(ctl-fd, SIOCBRADDBR, *name) == 0)
-return 0;
-} else {
-int id = 0;
-do {
-char try[50];
-
-snprintf(try, sizeof(try), virbr%d, id);
-
-if (ioctl(ctl-fd, SIOCBRADDBR, try) == 0) {
-if (!(*name = strdup(try))) {
-ioctl(ctl-fd, SIOCBRDELBR, name);
-return ENOMEM;
-}
-return 0;
-}
-
-id++;
-} while (id MAX_BRIDGE_ID);
-}
+if (ioctl(ctl-fd, SIOCBRADDBR, name) == 0)
+return 0;
return errno;
}
@@ -547,7 +528,7 @@ brAddTap(brControl *ctl,
}
id++;
-} while (subst id = MAX_BRIDGE_ID);
+} while (subst id = MAX_TAP_ID);
error:
close(fd);
diff --git a/src/bridge.h b/src/bridge.h
index f37ab72..e06ff41 100644
--- a/src/bridge.h
+++ b/src/bridge.h
@@ -47,7 +47,7 @@ int brInit (brControl **ctl);
voidbrShutdown (brControl *ctl);
int brAddBridge (brControl *ctl,
- char **name);
+ const char *name);
int brDeleteBridge (brControl *ctl,
const char *name);
int brHasBridge (brControl *ctl,
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index c38e142..b8cca00 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -206,6 +206,7 @@ virNetworkObjListFree;
virNetworkDefParseNode;
virNetworkRemoveInactive;
virNetworkSaveConfig;
+virNetworkSetBridgeName;
virNetworkObjLock;
virNetworkObjUnlock;
diff --git a/src/network_conf.c b/src/network_conf.c
index 6ad0d01..5de164e 100644
--- a/src/network_conf.c
+++ b/src/network_conf.c
@@ -43,6 +43,7 @@
#include buf.h
#include c-ctype.h
+#define MAX_BRIDGE_ID 256
#define VIR_FROM_THIS VIR_FROM_NETWORK
VIR_ENUM_DECL(virNetworkForward)
@@ -743,6 +744,12 @@ virNetworkObjPtr virNetworkLoadConfig(virConnectPtr conn,
goto error;
}
+/* Generate a bridge if none is found, but don't check for collisions
+ * if a bridge is hardcoded, so the network is at least defined
+ */
+if (!def-bridge !(def-bridge = virNetworkAllocateBridge(conn, nets)))
+goto error;
+
if (!(net = virNetworkAssignDef(conn, nets, def)))
goto error;
Re: [libvirt] PATCH: 3/3: Control file device access
On Thu, Feb 26, 2009 at 04:42:59PM +, Daniel P. Berrange wrote:
This patch is more focused on access control. CGroups has a controller
that enforces ACLs on device nodes. This allows us to restrict exactly
what block/character devices a guest is allowed to access. So in the
absence of something like SELinux sVirt, you can get a degree of
isolation between VMs on block device backed disks.
Will that work for dynamically plugged block devices ? This seems to
have the potential to break things there, isn't-it ?
This sets up an initial deny-all policy, and then iterates over all
the disks defined for a VM, allowing each one in turn. Finally it
allows a handy of common nodes like /dev/null, /dev/random, /dev/ptmx
and friends, which all processes need to use.
[...]
+if (virCgroupAllowDeviceMajor(cgroup, 'c', 136) 0) {
errr ... what is 136 ? Maybe a descriptive constant would help :-)
In gneral how much testing do we need before pushing those patches ?
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH]: Fix non-live migration failure
On Fri, Feb 27, 2009 at 01:12:40PM +0100, Chris Lalancette wrote: There is a logic error in the Qemu driver when doing a non-live migrate. During a non-live migrate, on the source host during the Perform step, we pause the domain; however, if there was ever a failure, we were forgetting to unpause the domain, meaning that the domain was paused forever. Add a flag to tell us when we should unpause the domain after a failure. Also, as pointed out by DV, we were unnecessarily using a snprintf to a buffer to execute qemu monitor commands, when we could get away with just sending a static string. Fix that as well. Oh right I had missed the leak :-) Looks fine to me now, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Recognize available media in nodedev hal driver
The host device hal driver can't tell when a storage device has media
available, the culprit being an incorrect return value check. The
attached patch fixes this.
Unfortunately the driver also doesn't properly detect media eject and
media inserted hal events. I've been poking at this but it's a more
involved fix.
Thanks,
Cole
Recognize ejectable media in hostdev hal driver.
diff --git a/src/node_device_hal.c b/src/node_device_hal.c
index cb4f86b..25ae12c 100644
--- a/src/node_device_hal.c
+++ b/src/node_device_hal.c
@@ -242,8 +242,8 @@ static int gather_storage_cap(LibHalContext *ctx, const char *udi,
(void)get_str_prop(ctx, udi, storage.vendor, d-storage.vendor);
if (get_bool_prop(ctx, udi, storage.removable, val) == 0 val) {
d-storage.flags |= VIR_NODE_DEV_CAP_STORAGE_REMOVABLE;
-if (get_bool_prop(ctx, udi,
- storage.removable.media_available, val) val) {
+if (get_bool_prop(ctx, udi, storage.removable.media_available,
+ val) == 0 val) {
d-storage.flags |=
VIR_NODE_DEV_CAP_STORAGE_REMOVABLE_MEDIA_AVAILABLE;
(void)get_uint64_prop(ctx, udi, storage.removable.media_size,
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Don't validate disk type in virsh attach-disk
virsh attempts to validate the requested disk type, rather than just let
the underlying driver do it. This was erroneously denying floppy device
attaches. Patch attached.
Thanks,
Cole
commit 3481061f6ed960269d9b29a4a1380367d557cf37
Author: Cole Robinson crobi...@redhat.com
Date: Fri Feb 27 10:47:49 2009 -0500
Let virt driver validate disk type for us in virsh attach-disk.
diff --git a/src/virsh.c b/src/virsh.c
index 298dde0..5c9c49f 100644
--- a/src/virsh.c
+++ b/src/virsh.c
@@ -5022,13 +5022,6 @@ cmdAttachDisk(vshControl *ctl, const vshCmd *cmd)
type = vshCommandOptString(cmd, type, NULL);
mode = vshCommandOptString(cmd, mode, NULL);
-if (type) {
-if (STRNEQ(type, cdrom) STRNEQ(type, disk)) {
-vshError(ctl, FALSE, _(No support %s in command 'attach-disk'), type);
-goto cleanup;
-}
-}
-
if (driver) {
if (STREQ(driver, file) || STREQ(driver, tap)) {
isFile = 1;
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH]: Fix non-live migration failure
Daniel Veillard wrote: On Fri, Feb 27, 2009 at 01:12:40PM +0100, Chris Lalancette wrote: There is a logic error in the Qemu driver when doing a non-live migrate. During a non-live migrate, on the source host during the Perform step, we pause the domain; however, if there was ever a failure, we were forgetting to unpause the domain, meaning that the domain was paused forever. Add a flag to tell us when we should unpause the domain after a failure. Also, as pointed out by DV, we were unnecessarily using a snprintf to a buffer to execute qemu monitor commands, when we could get away with just sending a static string. Fix that as well. Oh right I had missed the leak :-) Looks fine to me now, Great, thanks for looking again. Now committed. -- Chris Lalancette -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Better error reporting in qemu AttachDevice
The attached patch fixes qemu AttachDevice to show the invalid disk bus
or type in it's error messages. This also adds an error message where
previously we could fall through, leading virsh to print 'Unknown Error'
if attempting to hotplug an IDE disk.
Thanks,
Cole
commit abc32756bebac926acc0fde94ea42d2df2ca9946
Author: Cole Robinson crobi...@redhat.com
Date: Fri Feb 27 10:48:22 2009 -0500
Better error reporting from qemu AttachDevice
diff --git a/src/domain_conf.c b/src/domain_conf.c
index 603b87b..95ad32f 100644
--- a/src/domain_conf.c
+++ b/src/domain_conf.c
@@ -73,6 +73,14 @@ VIR_ENUM_IMPL(virDomainLifecycle, VIR_DOMAIN_LIFECYCLE_LAST,
rename-restart,
preserve)
+VIR_ENUM_IMPL(virDomainDevice, VIR_DOMAIN_DEVICE_LAST,
+ disk,
+ filesystem,
+ interface,
+ input,
+ sound,
+ hostdev)
+
VIR_ENUM_IMPL(virDomainDisk, VIR_DOMAIN_DISK_TYPE_LAST,
block,
file)
diff --git a/src/domain_conf.h b/src/domain_conf.h
index 491df06..015ea8b 100644
--- a/src/domain_conf.h
+++ b/src/domain_conf.h
@@ -342,6 +342,8 @@ enum virDomainDeviceType {
VIR_DOMAIN_DEVICE_INPUT,
VIR_DOMAIN_DEVICE_SOUND,
VIR_DOMAIN_DEVICE_HOSTDEV,
+
+VIR_DOMAIN_DEVICE_LAST,
};
typedef struct _virDomainDeviceDef virDomainDeviceDef;
@@ -621,6 +623,7 @@ VIR_ENUM_DECL(virDomainVirt)
VIR_ENUM_DECL(virDomainBoot)
VIR_ENUM_DECL(virDomainFeature)
VIR_ENUM_DECL(virDomainLifecycle)
+VIR_ENUM_DECL(virDomainDevice)
VIR_ENUM_DECL(virDomainDisk)
VIR_ENUM_DECL(virDomainDiskDevice)
VIR_ENUM_DECL(virDomainDiskBus)
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index b8cca00..b8691a3 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -68,6 +68,7 @@ virDomainDefParseString;
virDomainDeleteConfig;
virDomainDeviceDefFree;
virDomainDeviceDefParse;
+virDomainDeviceTypeToString;
virDomainDiskBusTypeToString;
virDomainDiskDefFree;
virDomainDiskDeviceTypeToString;
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index 34854dd..3b9b08a 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -3470,17 +3470,25 @@ static int qemudDomainAttachDevice(virDomainPtr dom,
case VIR_DOMAIN_DISK_DEVICE_FLOPPY:
ret = qemudDomainChangeEjectableMedia(dom-conn, vm, dev);
break;
+
case VIR_DOMAIN_DISK_DEVICE_DISK:
if (dev-data.disk-bus == VIR_DOMAIN_DISK_BUS_USB) {
ret = qemudDomainAttachUsbMassstorageDevice(dom-conn, vm, dev);
} else if (dev-data.disk-bus == VIR_DOMAIN_DISK_BUS_SCSI ||
dev-data.disk-bus == VIR_DOMAIN_DISK_BUS_VIRTIO) {
ret = qemudDomainAttachPciDiskDevice(dom-conn, vm, dev);
+} else {
+qemudReportError(dom-conn, dom, NULL, VIR_ERR_NO_SUPPORT,
+ _(disk bus '%s' cannot be hotplugged.),
+ virDomainDiskBusTypeToString(dev-data.disk-bus));
+goto cleanup;
}
break;
+
default:
qemudReportError(dom-conn, dom, NULL, VIR_ERR_NO_SUPPORT,
- %s, _(this disk device type cannot be attached));
+ _(disk device type '%s' cannot be hotplugged),
+ virDomainDiskDeviceTypeToString(dev-data.disk-device));
goto cleanup;
}
} else if (dev-type == VIR_DOMAIN_DEVICE_HOSTDEV
@@ -3489,7 +3497,8 @@ static int qemudDomainAttachDevice(virDomainPtr dom,
ret = qemudDomainAttachHostDevice(dom-conn, vm, dev);
} else {
qemudReportError(dom-conn, dom, NULL, VIR_ERR_NO_SUPPORT,
- %s, _(this device type cannot be attached));
+ _(device type '%s' cannot be attached),
+ virDomainDeviceTypeToString(dev-type));
goto cleanup;
}
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
RE: [libvirt] internal error Timed out while reading console log output
I have discovered that this timeout is due to kvm-84 being really slow to start (~10-15 seconds just to get to the bios screen). Is there any way that this timeout can be set via the Libvirt.conf with a reasonable default. It seems as though the current default is only around 3 seconds which seems a little too optimistic to me. Regards, -J From: libvir-list-boun...@redhat.com [mailto:libvir-list-boun...@redhat.com] On Behalf Of jmandawg Sent: Wednesday, February 25, 2009 8:28 AM To: libvir-list@redhat.com Subject: [libvirt] internal error Timed out while reading console log output Hi, I just compiled installed Libvirt from the latest git repo, and for some reason when I try to start a VM from virsh I get the following error: virsh # start XPTest error: Failed to start domain XPTest error: internal error unable to start guest: and the corresponding output from libvirtd running in verbose mode: 08:19:53.163: info : Received unexpected signal 17 08:20:00.083: info : Received unexpected signal 17 08:20:00.095: info : Received unexpected signal 17 08:20:03.200: error : internal error Timed out while reading console log output libvir: QEMU error : internal error Timed out while reading console log output 08:20:03.200: error : internal error unable to start guest: libvir: QEMU error : internal error unable to start guest: Here is the command virsh is trying to run from the Libvirt log file: LC_ALL=C PATH=/usr/bin:/bin:/root/bin:/usr/X11R6/bin:/usr/local/kvm/bin:/usr/local/sb in:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games HOME=/root USER=root LOGNAME=root /usr/bin/kvm -S -M pc -m 512 -smp 1 -name XPTest -uuid 732fcba8-b71f-face-e067-cf8431fc94aa -monitor pty -pidfile /var/run/libvirt/qemu//XPTest.pid -localtime -no-acpi -boot c -drive file=/var/kvm-images/XPTest/XP_Test.img,if=ide,index=0,boot=on -net nic,macaddr=00:0c:29:f6:c4:f8,vlan=0,model=e1000 -net tap,fd=20,script=,vlan=0,ifname=vnet3 -serial none -parallel none -usb -usbdevice tablet -vnc 0.0.0.0:9 If I start the VM from the commandline manually using this command and then shutdown, I can successfully start it from Virsh qemu-system-x86_64 -no-acpi -m 512 -hda XP_Test.img \ -net nic,macaddr=00:0C:29:F6:C4:F8 \ -net tap \ -usb -usbdevice tablet \ -monitor unix:monitor,server,nowait \ -soundhw all \ -pidfile pid virsh # version Compiled against library: libvir 0.6.0 Using library: libvir 0.6.0 Using API: QEMU 0.6.0 Running hypervisor: QEMU 0.9.1 Any help would be appreciated. Thanks, John -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
RE: [libvirt] Help with bridged networking
Hi, Thanks all for your help, I installed libvirt 0.6.0-4 and kvm 84-1 from fedora's rawhide and that solved the problem. However know I have a new problem I tried the other virtual machines and some of them just don't start, they seem to stop when the bios jumps to the disk and grub, any ideas? The only thing I can think of is to upgrade the host kernel but if I'm not wrong I have to upgrade to Fedora 9 or 10, and I would like to try something else before because I want to have everything running before leaving xen completely Subject: RE: [libvirt] Help with bridged networking From: lut...@redhat.com To: observ...@hotmail.es Date: Fri, 27 Feb 2009 08:48:13 -0800 On Fri, 2009-02-27 at 00:55 +, Jesus Urroa wrote: My mistake I see the lines for the ip config commented out in the file and I place them again Anyway I remove the card from the bridge to simplify the problem a little, this the output of brctl show for the bridge using only xen (no libvirt at all) and using kvm with libvirt and running only 2 vms: worknet 8000.feff no vif1.0 vif4.0 vif5.0 vif6.1 vif7.1 vif8.0 worknet 8000.00ff52959073 no vnet0 vnet3 With the non-Xen setup, your bridge should have the same IP address as the enslaved NIC. What exactly is not working ? Can VM's on the same bridge ping each other ? Did you add teh following iptables rule (to forward packages from the bridge to the outside): # echo -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT /etc/sysconfig/iptables-forward-bridged # lokkit --custom-rules=ipv4:filter:/etc/sysconfig/iptables-forward-bridged # service libvirtd reload Otherwise, your VM;s can't talk to the outside. David _ Anímate y disfruta con los mejores juegos de Messenger, ¡descúbrelos! http://www.vivelive.com/juegos/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Updated James Morris patch to apply to libvirt-0.6.0 version
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Another patch off latest repository. This patch does not require the XML to include a label, although this is still supported. Implemented most of the comments from Jim. make check and make syntax-check passes, Added seclabeltest.c to run in tests, Updated capability.rng, although not really sure I did it right. This patch will generate random MCS Labels and relabels the image files to match. Seems to work well on F11. I will back port some policy to allow it to work on F10. I think we need a mechanism in libvirtd.conf to turn this off. And allow perhaps three modes. svirt=Disabled. No Security Driver. svirt=MLS (Requires context in xml, no relabel of disks) svirt=Standard, (If no XML label, then random generate one and reset file context). How should I read config from libvirt.conf and and not enable he SecurityModel? http://people.fedoraproject.org/~dwalsh/SELinux/svirt.patch -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkmoTyMACgkQrlYvE4MpobPuHwCgkJqZenEwCWov96tTv+h3x8ec wmEAoMecJotrN009adtO3JOmkNLR3uXN =waHN -END PGP SIGNATURE- -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Update on host interface configuration
On Fri, 2009-02-27 at 10:07 +0200, Dan Kenigsberg wrote:
The real issue is, that in this stage, management may have lost
connectivity to the node.
What exactly is the scenario here ? Are you trying to manage any old
node as long as it has libvirt installed ? As soon as you need any sort
of management-specific code on the node, you might as well implement the
logic below in your management code.
if (! newConfigIsWorking()) {
virInterfaceDefine(goodConfig);
virInterfaceRestart(ifaceName);
}
How about having netcf/libvirt be aware of what is a goodConfig (with
additional API verb), and back it up somewhere? Any change to to network
configuration would have immediate effect, but unless explicitly set as
good, reverted on next boot.
While what you suggest will work in theory (with the minor caveat that
reverting to a good config can only be triggered by a restart of
libvirtd, not a reboot) it is a poor man's workaround for management
systems that do not provide proper failsafe functionality.
In particular, if you are part of the management system, you have a much
better idea (on the node) what it means to have a working network
configuration, and can recover from misconfigured network much more
gracefully than with the big hammer of a system reboot.
David
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] virDomainGetVcpus error with Fedora 10
Daniel P. Berrange wrote: On Fri, Feb 13, 2009 at 03:37:22PM -0800, Kaitlin Rupert wrote: Hi, I'm running Fedora 10 with the following libvirt version: libvirt-0.6.0-3 I'm calling virDomainGetVcpus() with the following parameters: virDomainGetVcpus(dom, info, max, NULL, 0); where max = 2 and dom and info are both non-NULL. However, I'm getting the following error from libvirt: libvir: Domain error : invalid argument in virDomainGetVcpus I tracked this down, and it's failing the if (cpumaps != NULL maplen 1) check in libvirt.c because cpumaps is non-NULL. Which is very strange because I'm definitely passing a NULL value. The qemud/remote.c helper for the virDomainGetVcpus method is just doing a totally bogus calculation/allocation for the cpumaps field. It needs fixing somehow, but I'm not sure how yet Yep, I took a look at this bit of code, but I wasn't sure of a clear solution either. Have you taken another look at this? -- Kaitlin Rupert IBM Linux Technology Center kait...@linux.vnet.ibm.com -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Multpile network interfaces have same MAC address
On Feb 25, 2009, at 7:29 AM, David Mueller wrote: On Wed, Feb 25, 2009 at 3:21 AM, Daniel P. Berrange berra...@redhat.com wrote: Last time I saw this was with QEMU and the rtl8139 nic, where there was a bug setting up the MMIO space, so all NICs were reading their mac from the first NIC's region instead of their own. I think I understand this, but I'm not sure it helps me fix the problem. Is this something that will require an updated libvirt or qemu or is there a simple change to make somewhere? CentOS 5.3 is running a bit behind and I'm not sure where to check to see what the versions of these packages are in RHEL 5.3 to know if I can just wait for the updated CentOS or should roll my own updated package. To follow up, I just found the bug that dealt with the problem: https://bugzilla.redhat.com/show_bug.cgi?id=247641 So it looks like the fix is an updated version of qemu? - David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
