[libvirt] [PATCH 1/2] add --crash support to virsh dump
This patch adds the --crash option (already present in xm dump-core)
to virsh dump. virDomainCoreDump already has a flags argument, so
the API/ABI is untouched.
* include/libvirt/libvirt.h.in (virDomainCoreDumpFlags): New.
* src/test/test_driver.c (testDomainCoreDump): Do not crash
after dump unless VIR_DUMP_CRASH is given.
* src/qemu/qemu_driver.c (qemudDomainCoreDump): Shutdown the domain
instead of restarting it if --crash is passed.
* src/xen/xend_internal.c (xenDaemonDomainCoreDump): Support --crash.
* tools/virsh.c (opts_dump): Add --crash.
(cmdDump): Map it to flags for virDomainCoreDump and pass them.
---
include/libvirt/libvirt.h.in |5 +
src/qemu/qemu_driver.c | 17 -
src/test/test_driver.c | 19 ++-
src/xen/xend_internal.c |6 --
tools/virsh.c|7 ++-
5 files changed, 41 insertions(+), 13 deletions(-)
diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
index 5bc7694..c04b552 100644
--- a/include/libvirt/libvirt.h.in
+++ b/include/libvirt/libvirt.h.in
@@ -334,6 +334,11 @@ struct _virDomainInterfaceStats {
typedef virDomainInterfaceStatsStruct *virDomainInterfaceStatsPtr;
+/* Domain core dump flags. */
+typedef enum {
+VIR_DUMP_CRASH = (1 0), /* crash after dump */
+} virDomainCoreDumpFlags;
+
/* Domain migration flags. */
typedef enum {
VIR_MIGRATE_LIVE = (1 0), /* live migration */
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 92d4629..8e80144 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -3543,6 +3543,7 @@ static int qemudDomainCoreDump(virDomainPtr dom,
virDomainObjPtr vm;
int resume = 0, paused = 0;
int ret = -1, fd = -1;
+virDomainEventPtr event = NULL;
const char *args[] = {
cat,
NULL,
@@ -3633,10 +3634,17 @@ static int qemudDomainCoreDump(virDomainPtr dom,
goto endjob;
endjob:
+if ((ret == 0) (flags VIR_DUMP_CRASH)) {
+qemudShutdownVMDaemon(dom-conn, driver, vm);
+event = virDomainEventNewFromObj(vm,
+ VIR_DOMAIN_EVENT_STOPPED,
+ VIR_DOMAIN_EVENT_STOPPED_CRASHED);
+}
+
/* Since the monitor is always attached to a pty for libvirt, it
will support synchronous operations so we always get here after
the migration is complete. */
-if (resume paused) {
+else if (resume paused) {
qemuDomainObjEnterMonitor(vm);
if (qemuMonitorStartCPUs(priv-mon, dom-conn) 0) {
if (virGetLastError() == NULL)
@@ -3647,12 +3655,19 @@ endjob:
}
qemuDomainObjEndJob(vm);
+if ((ret == 0) (flags VIR_DUMP_CRASH) !vm-persistent) {
+virDomainRemoveInactive(driver-domains,
+vm);
+vm = NULL;
+}
cleanup:
if (ret != 0)
unlink(path);
if (vm)
virDomainObjUnlock(vm);
+if (event)
+qemuDomainEventQueue(driver, event);
return ret;
}
diff --git a/src/test/test_driver.c b/src/test/test_driver.c
index 35f7571..7db9a4c 100644
--- a/src/test/test_driver.c
+++ b/src/test/test_driver.c
@@ -1911,15 +1911,16 @@ static int testDomainCoreDump(virDomainPtr domain,
goto cleanup;
}
-testDomainShutdownState(domain, privdom);
-event = virDomainEventNewFromObj(privdom,
- VIR_DOMAIN_EVENT_STOPPED,
- VIR_DOMAIN_EVENT_STOPPED_CRASHED);
-
-if (!privdom-persistent) {
-virDomainRemoveInactive(privconn-domains,
-privdom);
-privdom = NULL;
+if (flags VIR_DUMP_CRASH) {
+testDomainShutdownState(domain, privdom);
+event = virDomainEventNewFromObj(privdom,
+ VIR_DOMAIN_EVENT_STOPPED,
+ VIR_DOMAIN_EVENT_STOPPED_CRASHED);
+if (!privdom-persistent) {
+virDomainRemoveInactive(privconn-domains,
+privdom);
+privdom = NULL;
+}
}
ret = 0;
diff --git a/src/xen/xend_internal.c b/src/xen/xend_internal.c
index 66d2e7f..360390d 100644
--- a/src/xen/xend_internal.c
+++ b/src/xen/xend_internal.c
@@ -3243,8 +3243,10 @@ xenDaemonDomainCoreDump(virDomainPtr domain, const char
*filename,
return(-1);
}
-return xend_op(domain-conn, domain-name, op, dump, file, filename,
- live, 0, crash, 0, NULL);
+return xend_op(domain-conn, domain-name,
+ op, dump, file, filename, live, 0,
+ crash, (flags VIR_DUMP_CRASH ? 1 : 0),
+ NULL);
}
/**
diff --git a/tools/virsh.c b/tools/virsh.c
index 9faac35..65eaa3b 100644
--- a/tools/virsh.c
+++ b/tools/virsh.c
@@ -1431,6 +1431,7 @@ static const vshCmdInfo info_dump[] = {
};
static const
[libvirt] [PATCH 2/2] add --live support to virsh dump
This is trivial for QEMU since you just have to not stop the vm before
starting the dump.
In Xen it is buggy, so I chose to not support it.
* src/qemu/qemu_driver.c (qemudDomainCoreDump): Support live dumping.
---
include/libvirt/libvirt.h.in |1 +
src/qemu/qemu_driver.c |7 +++
tools/virsh.c|3 +++
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
index c04b552..b4a7ef1 100644
--- a/include/libvirt/libvirt.h.in
+++ b/include/libvirt/libvirt.h.in
@@ -337,6 +337,7 @@ typedef virDomainInterfaceStatsStruct
*virDomainInterfaceStatsPtr;
/* Domain core dump flags. */
typedef enum {
VIR_DUMP_CRASH = (1 0), /* crash after dump */
+VIR_DUMP_LIVE= (1 1), /* live dump */
} virDomainCoreDumpFlags;
/* Domain migration flags. */
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 8e80144..7de3c45 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -3597,15 +3597,14 @@ static int qemudDomainCoreDump(virDomainPtr dom,
driver-securityDriver-domainSetSavedStateLabel(dom-conn, vm, path)
== -1)
goto endjob;
-/* Migrate will always stop the VM, so once we support live dumping
- the resume condition will stay the same, independent of whether
- the stop command is issued. */
+/* Migrate will always stop the VM, so the resume condition is
+ independent of whether the stop command is issued. */
resume = (vm-state == VIR_DOMAIN_RUNNING);
qemuDomainObjPrivatePtr priv = vm-privateData;
/* Pause domain for non-live dump */
-if (vm-state == VIR_DOMAIN_RUNNING) {
+if (!(flags VIR_DUMP_LIVE) vm-state == VIR_DOMAIN_RUNNING) {
qemuDomainObjEnterMonitor(vm);
if (qemuMonitorStopCPUs(priv-mon) 0) {
qemuDomainObjExitMonitor(vm);
diff --git a/tools/virsh.c b/tools/virsh.c
index 65eaa3b..fcbd4e6 100644
--- a/tools/virsh.c
+++ b/tools/virsh.c
@@ -1431,6 +1431,7 @@ static const vshCmdInfo info_dump[] = {
};
static const vshCmdOptDef opts_dump[] = {
+{live, VSH_OT_BOOL, 0, gettext_noop(perform a live core dump if
supported)},
{crash, VSH_OT_BOOL, 0, gettext_noop(crash the domain after core
dump)},
{domain, VSH_OT_DATA, VSH_OFLAG_REQ, gettext_noop(domain name, id or
uuid)},
{file, VSH_OT_DATA, VSH_OFLAG_REQ, gettext_noop(where to dump the
core)},
@@ -1455,6 +1456,8 @@ cmdDump(vshControl *ctl, const vshCmd *cmd)
if (!(dom = vshCommandOptDomain(ctl, cmd, name)))
return FALSE;
+if (vshCommandOptBool (cmd, live))
+flags |= VIR_DUMP_LIVE;
if (vshCommandOptBool (cmd, crash))
flags |= VIR_DUMP_CRASH;
--
1.6.5.2
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] (v2) avoid chowning domain devices if higer-level mgmt does it for us
On Sun, Nov 29, 2009 at 03:54:30PM +0200, Dan Kenigsberg wrote: Only now did I notice another problem with root_squasing nfs, unrelated to chown and unadressed by my patch: qemudDomainSave tries to create the target image file and write into it as root. How reasonable would it be to seteuid() to qemu user before doing so? The trouble with directly doing seteuid() is that it affects all threads in the process, not just the thread doing the save() operation. We would thus need to fork a tiny helper program before doing the seteuid() step to create the file. 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] add another SENTINEL attribute
On Fri, Nov 27, 2009 at 04:15:04PM +0100, Paolo Bonzini wrote:
xend_op also can benefit from the attribute.
* src/xen/xend_internal.c (xend_op): Add ATTRIBUTE_SENTINEL.
---
src/xen/xend_internal.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/xen/xend_internal.c b/src/xen/xend_internal.c
index 4d9dcd1..66d2e7f 100644
--- a/src/xen/xend_internal.c
+++ b/src/xen/xend_internal.c
@@ -552,7 +552,7 @@ xend_op_ext(virConnectPtr xend, const char *path, char
*error,
*
* Returns 0 in case of success, -1 in case of failure.
*/
-static int
+static int ATTRIBUTE_SENTINEL
xend_op(virConnectPtr xend, const char *name, const char *key, ...)
{
char buffer[1024];
Trivial, makes sense, pushed,
thanks !
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] attach-disk to freebsd based guest
On Thu, Nov 26, 2009 at 10:35:41PM +0100, Sebastian Greatful wrote: I can easily attach a disk using the following command in virsh to a linux guest: attach-disk mydomain /dev/vg0/somethnig vdb Hwoever when I try the same to a freebsd based guest it doesnt show up under /dev. I hvae tried to substitude vdb with vda1 and all sorts of other things to no avail. AFAIK, FreeBSD does not implement VirtIO, so using vda will not work. You cannot hotplug IDE, so the only remaining option is to try SCSI by specifying a device name like sda 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] how do I stop libvirt futzing with my network configuration?
On Fri, Nov 27, 2009 at 12:06:13AM +, Nix wrote: On 26 Nov 2009, Daniel P. Berrange verbalised: If you don't want libvirt to create the bridge + setup IPtables rules then don't use the net-XXX commands / XML. That functionality is not there for pointing libvirt to existing bridge devices. Ah. All comes clear. If you already have a bridge configured, then just point the guest directly at that bridge by name. That seems to work: I thought it didn't, but that was my DHCP server deciding to go catatonic on me. The only remaining obvious problem is virt-manager-related, I think: this log spam: Nov 27 00:04:38 spindle err: 00:04:38.977: error : virLibConnError:383 : this function is not supported by the hypervisor: virConnectNumOfInterfaces Nov 27 00:04:38 spindle err: 00:04:38.977: error : virLibConnError:383 : this function is not supported by the hypervisor: virConnectNumOfDefinedInterfaces Emitting this *once a second* seems a bit... extreme. Can't it try once and give up? libvirtd always logs all errors, so if you want these to go away, then virt-manager will have to stop issuing these APi calls. Best file a bug against virt-manager about this, or raise it on the virt-manager mailing list (virt-tools-l...@redhat.com) 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] how do I stop libvirt futzing with my network configuration?
On Sat, Nov 28, 2009 at 09:10:28PM +, Nix wrote: On 26 Nov 2009, Daniel P. Berrange spake thusly: On Thu, Nov 26, 2009 at 06:25:07PM +, Nix wrote: However, there appears to be no way to say 'this is what the network is already like'. That network is considered 'inactive' and can't be used by any guests, and if I try to make it active, I get this: virsh # net-start default error: Failed to start network default error: cannot create bridge 'vm-net': File exists Of course it bloody can't create that bridge: it's already there, has an IP address on the host, and has the host routing packets to it. There appears to be no option to allow libvirt to assign IPs on the host... ... should I fix that, 'net-start' tries to update iptables rules! How should I put this: I do not *not not* want libvirt pissing with the firewall in any way at all. If I want firewall rules, I'll create them. But there's no way to tell it 'hands off! This network is already active, don't try to *make* it active!' If you don't want libvirt to create the bridge + setup IPtables rules then don't use the net-XXX commands / XML. That functionality is not there for pointing libvirt to existing bridge devices. If you already have a bridge configured, then just point the guest directly at that bridge by name. OK, I still can't make this work: it worked briefly but then stopped. As far as I can tell tools like virt-manager are unwilling to *let* you connect to a network considered 'inactive', and networks are only considered active if they have a configuration file under /var/run/libvirt/network. These files are only created if libvirt has created the bridge itself as well. If no networks are considerd active, virt-manager won't let you create a guest at all: it insists on trying to start the sodding network, and when that fails doesn't let you get any further. These files are all related to the libvirt net-XXX commands, so not things that are relevant to what you are trying todo. So as far as I can tell, if you don't want libvirt creating all your bridges for you, you may as well give up hope of using virt-manager, or start hacking all this stuff out of the source. virt-manager supports two primary networking modes described here: http://wiki.libvirt.org/page/Networking The first is the NAT based networking as managed by the net-XXX commands that you don't want to use. The second is bridging of a physical ethXX device to share it with a guest 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] how do I stop libvirt futzing with my network configuration?
On Sat, Nov 28, 2009 at 10:06:16PM +, Nix wrote: On 28 Nov 2009, Ian Woodstock spake thusly: I've been running with this configuration for many months on dozens of hosts. - Created a bridge (the old fashion way) in /etc/sysconfig/network-scripts Bridge called br0 with one device eth1. - Created a VM in virt manager (or edit existing) Picked Shared Physical Device Device eth1 (Bridge br0) in the GUI. That's the mystery. I did it (directly via brctl, as it happens, 'cos I'm making several with particular properties and want to enforce them): spindle:/etc/libvirt/qemu# brctl show bridge name bridge id STP enabled interfaces linux-net 8000.06eb4e4985df no dummy0 [...] 52: linux-net: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue state UNKNOWN link/ether 06:eb:4e:49:85:df brd ff:ff:ff:ff:ff:ff inet 192.168.20.1/32 scope global linux-net (hm, the state UNKNOWN is sort of bizarre. It's up...) (dummy0 is a member of this bridge because I've previously noted that a bridge with no members at all isn't picked up by the GUI). It appears in the GUI, all right: as 'host device linux-net (not bridged)', greyed out and unselectable. Calling a bridge 'not bridged' is more than slightly bizarre. What's confusing it here is that you've not connected a real physical network interface to the bridge - it is expecting to find a ethernet device enslaved, and instead finds 'dummy0'. 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] how do I stop libvirt futzing with my network configuration?
On Sat, Nov 28, 2009 at 10:41:58PM +, Nix wrote: On 28 Nov 2009, Ian Woodstock verbalised: I suspect that's why libvirt won't let you connect to it, since libvirt is looking for a shared physical device and there's not a device in the bridge. Gah. So libvirt won't let me connect a bunch of devices to a bridge without that bridge being bridged to something already? So you can't have a pile of bridges with VMs on them *routed* to the rest of the net? Please distinguish between libvirt virt-manager. libvirt allows this find - it is happy to connect VMs to any bridge device. virt-manager is providing a higher level UI which only presents a smaller subset of the functionality. In this case is only supporting the libvirt managed NAT mode, and bridging of a physical inteface. An alternative to using virt-manager is to install your VMs using the command line 'virt-install' tool which offers a much greater level of functionality - in this case you'd be able to simply add --network bridge:linux-net to the args when installing a VM to make it use your bridge. The virt-install manpage has lots of examples of all the other args. There's no iptables at all on this particular box (at least not yet, although it may turn up later on when I put Windows guests on here: I'm not having *them* running around free). So it sounds like the root of your issue now is that you're using dummy network device. Is that being done temporarily now because you don't have a network plumbed in or is there some other use case? It was an emergency hack when I found virt-manager not noticing bridges that had nothing on them (it said 'not bridged'). I stuck the dummy device on it and it started working. However, this appears to have been transient. ... In the code, the only place where it checks if a bridge exists is in src/network/bridge_driver.c:networkFindActiveConfigs(), and it only bothers to check *that* if there's a config file in the NETWORK_STATE_DIR (/var/lib/libvirt/network): Again the network driver here is libvirt's NAT based networking, not regular physical device bridging. Yes, its a bad naming convention :-) The physical interface management APIs are provided by the 'interface' driver (ie the virsh iface-XXX commands). 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] About node device enumeration problem
On Fri, Nov 27, 2009 at 01:46:40PM +0100, Daniel Veillard wrote: On Fri, Nov 27, 2009 at 06:03:30PM +0800, ajia wrote: Hi all, I saw two sets of node device enumeration implementation in libvirt-0.7.4 source code: 1.libudev implementation 2.HAL-based implementation I want to know which kind is used in libvirt.if both are used, which kinds solution is better? Depends on the host OS. For Fedora 12 and RHEL-6 , then libvirt if 0.7.4 or later will be compiled with udev. If not it will fallback to hal It's more a question of what method s supported on the host OS rather than picking one or the other, libvirt will just use the preferred method. The reason for the switch is that HAL has been deprecated as of Fedora 12, with udev being the recommended replacement. Hence libvirt has been updted to follow recommended practice in new enough distros. 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] fix various breakages in qemu virsh dump
On Fri, Nov 27, 2009 at 06:33:13PM +0100, Paolo Bonzini wrote: 1) qemuMigrateToCommand uses so we have to truncate the file before starting the migration; 2) the command wasn't updated to chown the driver and set/restore the security lavels; 3) the VM does not have to be resumed if migration fails; 4) the file is not removed when migration fails. * src/qemu/qemu_driver.c (qemuDomainCoreDump): Truncate file before dumping, set/restore ownership and security labels for the file. --- src/qemu/qemu_driver.c | 48 +--- 1 files changed, 45 insertions(+), 3 deletions(-) ACK, looks good. 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] questions on build qemu driver with non-root
On Fri, Nov 27, 2009 at 12:33:49PM -0800, Shi Jin wrote: Hi there, I have been successful in building the latest libvirt code from the git repository. The options I used to build is ./autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var --without-xen --with-qemu --with-qemu-user=oneadmin --with-qemu-group=oneadmin --without-uml --without-vbox --without-openvz --without-lxc Please note that I have specified qemu user and group to be non-root. So far the libvirtd service and virsh both seem to work fine but I have a few issues 1. Before running virsh create, the image belongs to user oneadmin. During the run, it still does. But the as soon as I shutdown/destroy the instance, the image ownership changes to -rw-rw?? 1 root root I don't understand why. Is this a bug? 2. From the documentation at http://libvirt.org/drvqemu.html, the directories /var/run/libvirt/qemu/, /var/lib/libvirt/qemu/ and /var/cache/libvirt/qemu/ must all have their ownership set to oneadmin:oneadmin. However, mine are still set to root:root and it does not seem to affect the running of libvirt/qemu/kvm. For example, The documentation is out-dated, it will set correct ownershiup on those directories at libvirtd startup 3. The libvirtd service still shows the warning message: warning : qemudStartup:904 : Unable to create cgroup for driver: No such device or address I read from earlier posts that the --without-lxc option should get rid of this message. CGroups are not something that is turned off at compile time, they will always be present. This message simply means that you do not have the cgroups controllers mounted on this host, so libvirt has disabled that functionality at runtime. This means you won't be able to use any of the schedular APIs with QEMU guests. Aside from that it is harmless, so either ignore it, or setup cgroups as best suis you 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 2/2] add --live support to virsh dump
On Mon, Nov 30, 2009 at 10:11:11AM +0100, Paolo Bonzini wrote:
This is trivial for QEMU since you just have to not stop the vm before
starting the dump.
In Xen it is buggy, so I chose to not support it.
And for the test driver there ain't any difference anyway ...
* src/qemu/qemu_driver.c (qemudDomainCoreDump): Support live dumping.
---
include/libvirt/libvirt.h.in |1 +
src/qemu/qemu_driver.c |7 +++
tools/virsh.c|3 +++
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
index c04b552..b4a7ef1 100644
--- a/include/libvirt/libvirt.h.in
+++ b/include/libvirt/libvirt.h.in
@@ -337,6 +337,7 @@ typedef virDomainInterfaceStatsStruct
*virDomainInterfaceStatsPtr;
/* Domain core dump flags. */
typedef enum {
VIR_DUMP_CRASH = (1 0), /* crash after dump */
+VIR_DUMP_LIVE= (1 1), /* live dump */
} virDomainCoreDumpFlags;
/* Domain migration flags. */
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 8e80144..7de3c45 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -3597,15 +3597,14 @@ static int qemudDomainCoreDump(virDomainPtr dom,
driver-securityDriver-domainSetSavedStateLabel(dom-conn, vm,
path) == -1)
goto endjob;
-/* Migrate will always stop the VM, so once we support live dumping
- the resume condition will stay the same, independent of whether
- the stop command is issued. */
+/* Migrate will always stop the VM, so the resume condition is
+ independent of whether the stop command is issued. */
resume = (vm-state == VIR_DOMAIN_RUNNING);
qemuDomainObjPrivatePtr priv = vm-privateData;
/* Pause domain for non-live dump */
-if (vm-state == VIR_DOMAIN_RUNNING) {
+if (!(flags VIR_DUMP_LIVE) vm-state == VIR_DOMAIN_RUNNING) {
qemuDomainObjEnterMonitor(vm);
if (qemuMonitorStopCPUs(priv-mon) 0) {
qemuDomainObjExitMonitor(vm);
diff --git a/tools/virsh.c b/tools/virsh.c
index 65eaa3b..fcbd4e6 100644
--- a/tools/virsh.c
+++ b/tools/virsh.c
@@ -1431,6 +1431,7 @@ static const vshCmdInfo info_dump[] = {
};
static const vshCmdOptDef opts_dump[] = {
+{live, VSH_OT_BOOL, 0, gettext_noop(perform a live core dump if
supported)},
{crash, VSH_OT_BOOL, 0, gettext_noop(crash the domain after core
dump)},
{domain, VSH_OT_DATA, VSH_OFLAG_REQ, gettext_noop(domain name, id or
uuid)},
{file, VSH_OT_DATA, VSH_OFLAG_REQ, gettext_noop(where to dump the
core)},
@@ -1455,6 +1456,8 @@ cmdDump(vshControl *ctl, const vshCmd *cmd)
if (!(dom = vshCommandOptDomain(ctl, cmd, name)))
return FALSE;
+if (vshCommandOptBool (cmd, live))
+flags |= VIR_DUMP_LIVE;
if (vshCommandOptBool (cmd, crash))
flags |= VIR_DUMP_CRASH;
Looks fine to me too, depends on previous being applied, ACK !
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] Eventtest unit test failure
On Sun, Nov 29, 2009 at 11:51:06AM +0100, Soren Hansen wrote: Hi, guys. I've changed the libvirt package in Ubuntu to run the test suite with every build. However, on our build daemons, the eventtest unit test seems to almost[1] consistently fail. You can see an example build log here: http://launchpadlibrarian.net/36196282/buildlog_ubuntu-lucid-amd64.libvirt_0.7.0-1ubuntu15_FAILEDTOBUILD.txt.gz Does this look familiar to anyone? Any idea what might be causing this? FWIW, I cannot reproduce it locally, so it's likely environmental, but at this point, I don't really know where to begin to look. What HZ setting are the kernels on the problem host running with ? IIRC we had someone else report a problem with this test suite on a kernel built with HZ=100, rather than the more common HZ=1000 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] how do I stop libvirt futzing with my network configuration?
On 11/26/2009 07:06 PM, Nix wrote: The only remaining obvious problem is virt-manager-related, I think: this log spam: Nov 27 00:04:38 spindle err: 00:04:38.977: error : virLibConnError:383 : this function is not supported by the hypervisor: virConnectNumOfInterfaces Nov 27 00:04:38 spindle err: 00:04:38.977: error : virLibConnError:383 : this function is not supported by the hypervisor: virConnectNumOfDefinedInterfaces Emitting this *once a second* seems a bit... extreme. Can't it try once and give up? Sounds like you are using a recent upstream virt-manager checkout? This was a bug I just fixed yesterday (the fix is actually in virtinst, so you'll want to pull there): http://hg.fedorahosted.org/hg/python-virtinst/rev/05adb0b921e2 - Cole -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] how do I stop libvirt futzing with my network configuration?
On 11/28/2009 04:10 PM, Nix wrote: On 26 Nov 2009, Daniel P. Berrange spake thusly: On Thu, Nov 26, 2009 at 06:25:07PM +, Nix wrote: However, there appears to be no way to say 'this is what the network is already like'. That network is considered 'inactive' and can't be used by any guests, and if I try to make it active, I get this: virsh # net-start default error: Failed to start network default error: cannot create bridge 'vm-net': File exists Of course it bloody can't create that bridge: it's already there, has an IP address on the host, and has the host routing packets to it. There appears to be no option to allow libvirt to assign IPs on the host... ... should I fix that, 'net-start' tries to update iptables rules! How should I put this: I do not *not not* want libvirt pissing with the firewall in any way at all. If I want firewall rules, I'll create them. But there's no way to tell it 'hands off! This network is already active, don't try to *make* it active!' If you don't want libvirt to create the bridge + setup IPtables rules then don't use the net-XXX commands / XML. That functionality is not there for pointing libvirt to existing bridge devices. If you already have a bridge configured, then just point the guest directly at that bridge by name. OK, I still can't make this work: it worked briefly but then stopped. As far as I can tell tools like virt-manager are unwilling to *let* you connect to a network considered 'inactive', and networks are only considered active if they have a configuration file under /var/run/libvirt/network. These files are only created if libvirt has created the bridge itself as well. If no networks are considerd active, virt-manager won't let you create a guest at all: it insists on trying to start the sodding network, and when that fails doesn't let you get any further. virt-manager should be fixed here, it should offer some fallback (at least 'no networking') if it can't start the virtual network. But if you don't want the virtual network at all and it can't be started without erroring, you want to virsh net-undefine it, or delete it in virt-manager via: Edit-Host Details-Networks So as far as I can tell, if you don't want libvirt creating all your bridges for you, you may as well give up hope of using virt-manager, or start hacking all this stuff out of the source. If you create a manual bridge, virt-manager should see it. However, the virtinst bug I mentioned in my other email was conspiring to make this not work for you. Pull from virtinst, and your manually created bridge devices should show up in virt-manager. - Cole -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Move esxVMX_IndexToDiskName to util.c
On 11/20/2009 02:16 PM, Matthias Bolte wrote: I needed the inverse function to virDiskNameToIndex() for the ESX driver and added it to esx_vmx.c. The pending VirtualBox 3.1 patch needs disk index to disk name mapping too. So I want to move esxVMX_IndexToDiskName() to util.c. esxVMX_IndexToDiskName() handles indices up to 701. This limit comes from a gap in the disk name to disk index mapping of virDiskNameToIndex(): sdzy - 700 sdzz - 701 sdaaa - 728 sdaab - 729 This line in virDiskNameToIndex() causes this gap: idx = (idx + i) * 26; It can be fixed by altering this line to: idx = (idx + (i 1 ? 0 : 1)) * 26; But this change breaks compatibility for indices 701. So, I made two patches for either option and ask you for comments. Matthias I agree with Pritesh, so ACK to patch A. I highly doubt anyone is depending on the broken behavior anyways, so let's just fix the bug. - Cole -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/2] add --crash support to virsh dump
On Mon, Nov 30, 2009 at 10:11:10AM +0100, Paolo Bonzini wrote:
This patch adds the --crash option (already present in xm dump-core)
to virsh dump. virDomainCoreDump already has a flags argument, so
the API/ABI is untouched.
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 92d4629..8e80144 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -3543,6 +3543,7 @@ static int qemudDomainCoreDump(virDomainPtr dom,
virDomainObjPtr vm;
int resume = 0, paused = 0;
int ret = -1, fd = -1;
+virDomainEventPtr event = NULL;
const char *args[] = {
cat,
NULL,
@@ -3633,10 +3634,17 @@ static int qemudDomainCoreDump(virDomainPtr dom,
goto endjob;
endjob:
+if ((ret == 0) (flags VIR_DUMP_CRASH)) {
+qemudShutdownVMDaemon(dom-conn, driver, vm);
+event = virDomainEventNewFromObj(vm,
+ VIR_DOMAIN_EVENT_STOPPED,
+ VIR_DOMAIN_EVENT_STOPPED_CRASHED);
+}
+
Shouldn't we be setting 'resume=0' here otherwise
/* Since the monitor is always attached to a pty for libvirt, it
will support synchronous operations so we always get here after
the migration is complete. */
-if (resume paused) {
+else if (resume paused) {
qemuDomainObjEnterMonitor(vm);
if (qemuMonitorStartCPUs(priv-mon, dom-conn) 0) {
if (virGetLastError() == NULL)
this will try to resume CPUs on a guest we just shutdown
@@ -3647,12 +3655,19 @@ endjob:
}
qemuDomainObjEndJob(vm);
+if ((ret == 0) (flags VIR_DUMP_CRASH) !vm-persistent) {
+virDomainRemoveInactive(driver-domains,
+vm);
+vm = NULL;
+}
cleanup:
if (ret != 0)
unlink(path);
if (vm)
virDomainObjUnlock(vm);
+if (event)
+qemuDomainEventQueue(driver, event);
return ret;
}
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 2/2] add --live support to virsh dump
On Mon, Nov 30, 2009 at 10:11:11AM +0100, Paolo Bonzini wrote: This is trivial for QEMU since you just have to not stop the vm before starting the dump. In Xen it is buggy, so I chose to not support it. Well some versions of Xen are buggy, but not neccessarily all of them. IMHO we should support it in libvirt because it is a trivial change to make. This at least lets users try the functionality and see if there are bugs in their version of Xen eg, our code already does return xend_op(domain-conn, domain-name, op, dump, file, filename, live, 0, crash, 0, NULL); so it is easy to set live, 1 based on flags 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 2/2] add --live support to virsh dump
On 11/30/2009 03:29 PM, Daniel P. Berrange wrote: On Mon, Nov 30, 2009 at 10:11:11AM +0100, Paolo Bonzini wrote: This is trivial for QEMU since you just have to not stop the vm before starting the dump. In Xen it is buggy, so I chose to not support it. Well some versions of Xen are buggy, but not neccessarily all of them. IMHO we should support it in libvirt because it is a trivial change to make. This at least lets users try the functionality and see if there are bugs in their version of Xen eg, our code already does return xend_op(domain-conn, domain-name, op, dump, file, filename, live, 0, crash, 0, NULL); so it is easy to set live, 1 based on flags That's fine by me, but I would appreciate a second opinion (it can also be done as a follow up, anyway). Paolo -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/2] add --live support to virsh dump
In Xen it is buggy, so I chose to not support it. Well some versions of Xen are buggy, but not neccessarily all of them. IMHO we should support it in libvirt because it is a trivial change to make. This at least lets users try the functionality and see if there are bugs in their version of Xen eg, our code already does return xend_op(domain-conn, domain-name, op, dump, file, filename, live, 0, crash, 0, NULL); so it is easy to set live, 1 based on flags Well, the live dump implementation in xen is just bogus even upstream but I agree we should support it in xen driver because xen claims to support it and it's not our problem that their code for that is buggy. Furthermore they could fix it in the future and then it will just work. Jirka -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/2] add --crash support to virsh dump
On Mon, Nov 30, 2009 at 03:44:13PM +0100, Paolo Bonzini wrote:
On 11/30/2009 03:27 PM, Daniel P. Berrange wrote:
Shouldn't we be setting 'resume=0' here otherwise
/* Since the monitor is always attached to a pty for libvirt, it
will support synchronous operations so we always get here
after
the migration is complete. */
-if (resume paused) {
+else if (resume paused) {
qemuDomainObjEnterMonitor(vm);
if (qemuMonitorStartCPUs(priv-mon, dom-conn) 0) {
if (virGetLastError() == NULL)
this will try to resume CPUs on a guest we just shutdown
That's why I changed if to else if.
Ah, I didn't notice that was part of the same control flow
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 v2] Disk- and Controller Hotplug
On Tue, Nov 24, 2009 at 02:15:58PM +0100, Wolfgang Mauerer wrote: Hi, Daniel P. Berrange wrote: On Mon, Nov 23, 2009 at 02:15:06PM +0100, Wolfgang Mauerer wrote: Daniel P. Berrange wrote: On Tue, Nov 17, 2009 at 12:53:31AM +0100, wolfgang.maue...@siemens.com wrote: this is the second revision of a patch series to improve disk hotadd support for libvirt. It focuses on the qemu backend, but is naturally designed to be compatible with other backends as well. The objective is two-fold: 1.) Split off controller from disk handling. This is done by introducing a new domain element controller that is used to describe disk controllers. Support for hotplugging such controllers is added. Support to reference controllers by name is also included. 2.) disks can now be associated with a specific controller; this is done by means of a controller subelemnt for disks. This patch addresses the questions that were raised during the review of the initial submission, massages the code by fixing some whitespace issues, gets static controller configurations to work, and adds documentation. Notice that in contrast to the first submission I did not include the patch that adds support for disk- and controller hot_remove_. Since the qemu codebase is still in bit of a flux wrt. the necessary patches required for this functionality, it will reappear some time later as a separate submission. What libvirt version / GIT changeset did you create these patches against ? The current libvirt QEMU driver code in GIT is quite different, so the patches here don't apply for me as is. sorry for the late reply, I could not access my eMail during the last couple of days. Patches are on top of 790f0b3057787bb64, I did not realise that this one was only in the middle of qemu refactoring, not at the end :-( Do you plan any more refactorings to the qemu base in the near future, and if yes, are these already available somewhere? I'd like to avoid another useless rebase... No, the monitor code for the QEMU driver is stable now. I'll only be adding extra functionality, not changing existing stuff, so it should be good to rebase against now. okay, to avoid flooding the mailing list with nearly identical patches, I've put the rebased versions into a repository at git://git.kiszka.org/libvirt.git queue I've been taking a closer look at this, and I think the final state of patch series as a whole looks good. The minor issue is that the intermediate patches don't compile, since they rely on compile fixes at the end of the series. Rather than ask you to re-format the patches yet again, I'm going to just merge the patches into a smaller set myself. I've got just one question I'd like to understand before doing this. On the disk element's new controller element, you are allowing two mutually exclusive ways of specifying the controller disk ... controller name=identifier bus=number unit=number/ /disk and disk ... controller pci_addr=addr bus=number unit=number/ /disk I think it is going to cause unneccessary pain for applications to have to cope with two different ways of specifying the same relationship. So my intention is to remove the 'pci_addr' variant, since that information can easily be got directly from the separate top level controller device itself On a side note, once we've applied this initial series, I think we'll also need to be automatically adding a controller element in all guest domains which have IDE or SCSI controllers present by default. This is going to also force us to hook into QEMU's 'info pci' monitor command to figure out their PCI address. This is long overdue though and needed for NIC Disk devices added at startup too, so this is good motivation :-) 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] how do I stop libvirt futzing with my network configuration?
On 30 Nov 2009, Cole Robinson spake thusly: Sounds like you are using a recent upstream virt-manager checkout? This was a bug I just fixed yesterday (the fix is actually in virtinst, so you'll want to pull there): Ah, I love preemptive bugfixing. Looks fixed, thanks! :) -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] how do I stop libvirt futzing with my network configuration?
On 30 Nov 2009, Daniel P. Berrange stated: What's confusing it here is that you've not connected a real physical network interface to the bridge - it is expecting to find a ethernet device enslaved, and instead finds 'dummy0'. I'm not bothering with dummy0 anymore: my bridges are empty save for VM network interfaces (connected to the real network via ordinary routing). Let's see if this works with the virt-manager/libvirt fix Cole mentioned... -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Eventtest unit test failure
On Mon, Nov 30, 2009 at 10:26:12AM +, Daniel P. Berrange wrote: I've changed the libvirt package in Ubuntu to run the test suite with every build. However, on our build daemons, the eventtest unit test seems to almost[1] consistently fail. You can see an example build log here: http://launchpadlibrarian.net/36196282/buildlog_ubuntu-lucid-amd64.libvirt_0.7.0-1ubuntu15_FAILEDTOBUILD.txt.gz Does this look familiar to anyone? Any idea what might be causing this? FWIW, I cannot reproduce it locally, so it's likely environmental, but at this point, I don't really know where to begin to look. What HZ setting are the kernels on the problem host running with ? IIRC we had someone else report a problem with this test suite on a kernel built with HZ=100, rather than the more common HZ=1000 Ah, indeed they are running with HZ=100. So this is a known problem? Is there a known fix? -- Soren Hansen | Lead virtualisation engineer | Ubuntu Server Team Canonical Ltd. | http://www.ubuntu.com/ signature.asc Description: Digital signature -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Fix executable name and version parsing for KVM 0.11.0-stable.
---
src/qemu/qemu_conf.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
On 30 Nov 2009, Cole Robinson uttered the following:
If you create a manual bridge, virt-manager should see it. However, the
virtinst bug I mentioned in my other email was conspiring to make this not
work for you. Pull from virtinst, and your manually created bridge devices
should show up in virt-manager.
Pulled. Bridges still show up as 'not bridged', inactive.
I'm giving up. I've spent a week of free time fighting libvirt and
virt-manager and they simply don't seem to be ready for anything but the
simplest of use cases: by comparison I had qemu pretty much working from
the source in about twenty minutes, including reading the manuals from
zero qemu knowledge.
Maybe libvirt works better if you're using one of the subset of popular
distros for which netcf knows how to parse and manipulate the network
config (something which no serious site is going to allow in any case,
because they have their own network control scripts). Maybe libvirt and
virt-manager are only meant to be useful for single-user desktops and
very small sites, in which case it would be nice to, y'know, *say* that
somewhere, perhaps along with a big banner saying don't bother using
the code from upstream if you're not running unmodified Fedora or RHEL,
so people don't waste their time trying to make it work otherwise. Maybe
I overstate the case, but I don't think by much. I've looked at libvirt
support in a pile of not-completely-mainstream distros now and I haven't
yet found one in which networking works without manual bringup, because
netcf fails to parse the distro config files (yes, I know Augeas support
is possible, but not many people have written that and nobody but Debian
has contributed it upstream: a shame, Augeas is *lovely*). And that then
lands me in the same situation I've just been trying and failing to get
out of.
Whenever anything goes wrong in the virtualization layer I have to fall
back to raw qemu for monitor access in any case, because for reasons
incomprehensible to me libvirt actually bans me from accessing the
monitor or even adding a -serial mon:telnet stanza (or *anything*
user-definable) to the command line: and it insists on using VNC
consoles so I can't use the SDL console's monitor either (though this is
reasonable: you want to be able to stop virt-manager and leave the
emulator running, which VNC makes easier). So the ability to ignore the
nuts and bolts of your virtualization system's command line is
effectively lost the first time anything goes wrong, and you have to
keep everything working without libvirt as well. (Of course the qemu
guys assume you have monitor access when trying to debug problems.)
While I wish I *could* use libvirt (the ability to start VMs as a
regular user with working tun/tap alone would be excellent), it's just
not remotely ready for serious use yet, though it's a very promising
start and has all the infrastructure that it needs to be something very
nice indeed in the future. I think I'll hack up something much simpler
for now which just kicks up tun/tap devices as root and passes their fds
down to setuid() children that run specified qemus as a regular
user. You'd think someone would have written this already...
Have a patch to be going on with, anyway: libvirt can't parse the
version output of qemu-kvm 0.11.0-stable, and doesn't know the name of
its x86_64 upstream binary. (I'm not certain that this is right:
I'm not sure it can distinguish between KMM and non-KVM. I'm equally
unsure that this matters anymore now that enough KVM support to be
getting on with is upstream.)
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index 8f8d490..10efdae 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -642,7 +642,8 @@ qemudCapsInitGuest(virCapsPtr caps,
if (STREQ(info-arch, hostmachine) ||
(STREQ(hostmachine, x86_64) STREQ(info-arch, i686))) {
const char *const kvmbins[] = { /usr/bin/qemu-kvm, /* Fedora */
-/usr/bin/kvm }; /* Upstream .spec */
+/usr/bin/kvm, /* Upstream .spec */
+/usr/bin/qemu-system-x86_64 }; /*
Upstream sources */
for (i = 0; i ARRAY_CARDINALITY(kvmbins); ++i) {
if (access(kvmbins[i], X_OK) == 0
@@ -953,6 +954,7 @@ static unsigned int qemudComputeCmdFlags(const char *help,
* in parenthesis as follows:
* - qemu-kvm-x.y.z in stable releases
* - kvm-XX for kvm versions up to kvm-85
+ * - kvm-devel for kvm 0.11.0-stable
* - qemu-kvm-devel-XX for kvm version kvm-86 and later
*
* For qemu-kvm versions before 0.10.z, we need to detect
@@ -962,6 +964,7 @@ static unsigned int qemudComputeCmdFlags(const char *help,
*/
#define QEMU_VERSION_STRQEMU PC emulator version
#define QEMU_KVM_VER_PREFIX (qemu-kvm-
+#define KVM_GIT_STABLE_VER_PREFIX (kvm-devel)
#define
Re: [libvirt] how do I stop libvirt futzing with my network configuration?
On 30 Nov 2009, Daniel P. Berrange spake thusly: On Sat, Nov 28, 2009 at 09:10:28PM +, Nix wrote: So as far as I can tell, if you don't want libvirt creating all your bridges for you, you may as well give up hope of using virt-manager, or start hacking all this stuff out of the source. virt-manager supports two primary networking modes described here: http://wiki.libvirt.org/page/Networking The first is the NAT based networking as managed by the net-XXX commands that you don't want to use. The second is bridging of a physical ethXX device to share it with a guest So you have a choice of letting libvirt mess with your host's networking, or messing with its physical ethernet configuration yourself? You can't just use ordinary routing? Blast. :/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Re: [PATCH] Fix executable name and version parsing for KVM 0.11.0-stable.
On 11/30/2009 05:17 PM, Nix wrote: --- src/qemu/qemu_conf.c |8 +++- 1 files changed, 7 insertions(+), 1 deletions(-) On 30 Nov 2009, Cole Robinson uttered the following: If you create a manual bridge, virt-manager should see it. However, the virtinst bug I mentioned in my other email was conspiring to make this not work for you. Pull from virtinst, and your manually created bridge devices should show up in virt-manager. Pulled. Bridges still show up as 'not bridged', inactive. It might just be unfortunate timing. If you look at the recent virt-manager commits (as in, within the past week), the bridging code was largely refactored to deal with HAL deprecation, and optionally use libvirt nodedev and interface (aka netcf) APIs if available. This may very well have caused regressions. Might be worth a shot to try the 0.8.0 release and see if you still hit issues. Also, can you provide the output of: ~/.virt-manager/virt-manager.log brctl show virsh iface-list --all - Cole -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
