Re: [libvirt] Availability of Release Candidate 2 for 1.0.0
On Sun, Oct 28, 2012 at 10:19 PM, Daniel Veillard veill...@redhat.com wrote: The tree is now tagged (v1.0.0-rc2) and the tarball (and rpms) are available at the usual place: ftp://libvirt.org/libvirt/ It seems to work correctly with my limited testing, but please give it a try, and let's fix any remaining reported issue before the end of the week. I will do an rc3 on Wednesday and plan to push the final 1.0.0 this Friday, thanks ! Daniel -- Small edge case that's broken (and broken in past releases) is vol-download over qemu+ssh://. The result is a 0 byte file locally and it acts like it succeeds. Haven't had a chance to debug and work up a patch. -- Doug Goldstein -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] gitignore: ignore more files
ignore *.patch, cscope.po.out, cscope.in.out Signed-off-by: liguang lig.f...@cn.fujitsu.com --- .gitignore |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/.gitignore b/.gitignore index 1cd2d45..d2d6657 100644 --- a/.gitignore +++ b/.gitignore @@ -16,6 +16,7 @@ *.pyc *.rej *.s +*.patch *~ .deps .gdb_history @@ -185,6 +186,8 @@ TAGS coverage cscope.files cscope.out +cscope.in.out +cscope.po.out results.log stamp-h stamp-h.in -- 1.7.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Gluster-devel] [PATCH v3 UPDATED 1/2] Qemu/Gluster: Add Gluster protocol as supported network disk formats.
On 10/27/2012 11:29 AM, Bharata B Rao wrote: On Fri, Oct 26, 2012 at 10:27 PM, Harsh Prateek Bora ha...@linux.vnet.ibm.com wrote: @@ -1624,7 +1626,15 @@ td one of the sheepdog servers (default is localhost:7000) /td td zero or one /td /tr + tr +td gluster /td +td a server running glusterd daemon /td Its actually the server which contains the volume file specification of the gluster volume If a server is part of storage pool (ie, gluster peer probe is successful), the server will have 'volume file' in it, even if it is not contributing any exports from that server. So, I think the above definition still holds good. Regards, Amar -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] gitignore: ignore more files
On 10/29/2012 07:07 AM, liguang wrote: ignore *.patch, cscope.po.out, cscope.in.out Signed-off-by: liguang lig.f...@cn.fujitsu.com --- .gitignore |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/.gitignore b/.gitignore index 1cd2d45..d2d6657 100644 --- a/.gitignore +++ b/.gitignore @@ -16,6 +16,7 @@ *.pyc *.rej *.s +*.patch It shouldn't spoil the repo even if we have *.patch files in already (in docs/api_extension/), but doesn't feel clean since there are such files. Anyone feels bad about changing this to '/*.patch' or adding '!/docs/api_extension/*.patch' to this? *~ .deps .gdb_history @@ -185,6 +186,8 @@ TAGS coverage cscope.files cscope.out +cscope.in.out +cscope.po.out results.log stamp-h stamp-h.in This one is ok. BTW: Why don't we have 'tags' in .gitignore as well (created by ctags target)? Martin -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv2] xml: print uuids or shell-escaped names in the warning
On Thu, Oct 25, 2012 at 16:37:37 +0200, Ján Tomko wrote: In the XML warning, this prints uuids for domain names with special characters in them and shell-escaped names for other elements (like snapshosts and networks) with special names. --- When saving snapshots, the domain name is appended to the snapshot-edit command, so using a domain name that needs escaping would lead to something that can't be just fed to the shell as it would glue them together. diff to xml: shell-escape domain name in comment: - Domain names don't get escaped, UUIDs are preferred. - The command gets escaped too. diff to v1: don't try to use CDATA (it doesn't belong there) --- src/conf/domain_conf.c |6 +++- src/libvirt_private.syms |2 + src/qemu/qemu_domain.c |3 +- src/util/buf.c | 66 ++ src/util/buf.h |1 + src/util/xml.c | 62 ++- src/util/xml.h |1 + 7 files changed, 109 insertions(+), 32 deletions(-) I think we're making this too complicated for no real benefit. The goal is to provide a hint to anyone who looks at the autogenerated XML files and IMHO providing an escaped string (that would only work in environments for which it was designed). I would just keep it simple: - emit virsh command name in case name is nice - emit virsh command uuid in case name is ugly and uuid is known - emit virsh command in all other cases This should keep the hints in domain and network XML files in /etc/libvirt usable for copypaste (the UUID fallback works there). Snapshot files (located in /var/lib/libvirt) use virsh snapshot-edit domain snapshot, where domains are passed as part of the command and snapshots have no UUIDs. Thus to keep the code simple, I'd emit just virsh snapshot-edit, which is still a useful hint and I don't believe we need to do anything beyond that. Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] gitignore: ignore more files
On 29.10.2012 10:00, Martin Kletzander wrote: On 10/29/2012 07:07 AM, liguang wrote: ignore *.patch, cscope.po.out, cscope.in.out Signed-off-by: liguang lig.f...@cn.fujitsu.com --- .gitignore |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/.gitignore b/.gitignore index 1cd2d45..d2d6657 100644 --- a/.gitignore +++ b/.gitignore @@ -16,6 +16,7 @@ *.pyc *.rej *.s +*.patch It shouldn't spoil the repo even if we have *.patch files in already (in docs/api_extension/), but doesn't feel clean since there are such files. Anyone feels bad about changing this to '/*.patch' or adding '!/docs/api_extension/*.patch' to this? This is okay since adding *.patch to git repo doesn't feel okay (or showing it in git status output). Moreover, if somebody wants to add *.patch he would need explicit 'git add' which will make him think twice. ACK from me. *~ .deps .gdb_history @@ -185,6 +186,8 @@ TAGS coverage cscope.files cscope.out +cscope.in.out +cscope.po.out results.log stamp-h stamp-h.in This one is ok. BTW: Why don't we have 'tags' in .gitignore as well (created by ctags target)? Martin Yeah, we should add 'tags' as well. Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCHv2 7/6] net: Mark network persistent when assigning persistent definition
When assigning the new persistent definition for a transient network
(thus making it persistent) the network needs to be marked persistent
before actually atempting to assign the definition.
---
src/network/bridge_driver.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c
index 22bd99b..643b00c 100644
--- a/src/network/bridge_driver.c
+++ b/src/network/bridge_driver.c
@@ -2820,7 +2820,7 @@ cleanup:
static virNetworkPtr networkDefine(virConnectPtr conn, const char *xml) {
struct network_driver *driver = conn-networkPrivateData;
-virNetworkDefPtr def;
+virNetworkDefPtr def = NULL;
bool freeDef = true;
virNetworkObjPtr network = NULL;
virNetworkPtr ret = NULL;
@@ -2833,11 +2833,17 @@ static virNetworkPtr networkDefine(virConnectPtr conn,
const char *xml) {
if (networkValidate(driver, def, false) 0)
goto cleanup;
-if (!(network = virNetworkAssignDef(driver-networks, def, false)))
-goto cleanup;
-freeDef = false;
+if ((network = virNetworkFindByName(driver-networks, def-name))) {
+network-persistent = 1;
+if (virNetworkObjAssignDef(network, def, false) 0)
+goto cleanup;
+} else {
+if (!(network = virNetworkAssignDef(driver-networks, def, false)))
+goto cleanup;
+}
-network-persistent = 1;
+/* def was asigned */
+freeDef = false;
if (virNetworkSaveConfig(driver-networkConfigDir, def) 0) {
virNetworkRemoveInactive(driver-networks, network);
--
1.7.12.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Can we run guest OS without using NAT and iptables?
On Mon, Oct 29, 2012 at 12:55:43PM +0530, freak 62 wrote: Can we run guest o.s. on KVM without enabling NAT and iptables? The reason to do this is , I wanted to disable conntrack module from my system and to disable that I must have to delete iptable and NAT. I am getting the following message, when I start guest o.s. on KVM (iptable and NAT disabled): Error starting domain: internal error 'Network default' is not active. Is their any way to run guest o.s. with NAT disabled? or Is their any way to disable conntrack module and still can use KVM to run guest OS ? I am using Ubuntu 10.04 This is a libvirt question since libvirt sets up the networking configuration. You can try a different network config either using the virt-manager GUI tool or by editing the network XML, which is documented here: http://libvirt.org/formatnetwork.html CCed libvirt mailing list. Stefan -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv2] xml: print uuids or shell-escaped names in the warning
On 10/29/12 10:38, Jiri Denemark wrote: On Thu, Oct 25, 2012 at 16:37:37 +0200, Ján Tomko wrote: In the XML warning, this prints uuids for domain names with special characters in them and shell-escaped names for other elements (like snapshosts and networks) with special names. --- When saving snapshots, the domain name is appended to the snapshot-edit command, so using a domain name that needs escaping would lead to something that can't be just fed to the shell as it would glue them together. diff to xml: shell-escape domain name in comment: - Domain names don't get escaped, UUIDs are preferred. - The command gets escaped too. diff to v1: don't try to use CDATA (it doesn't belong there) --- src/conf/domain_conf.c |6 +++- src/libvirt_private.syms |2 + src/qemu/qemu_domain.c |3 +- src/util/buf.c | 66 ++ src/util/buf.h |1 + src/util/xml.c | 62 ++- src/util/xml.h |1 + 7 files changed, 109 insertions(+), 32 deletions(-) I think we're making this too complicated for no real benefit. The goal is to provide a hint to anyone who looks at the autogenerated XML files and IMHO providing an escaped string (that would only work in environments for which it was designed). I would just keep it simple: - emit virsh command name in case name is nice - emit virsh command uuid in case name is ugly and uuid is known - emit virsh command in all other cases This looks reasonable. This should keep the hints in domain and network XML files in /etc/libvirt usable for copypaste (the UUID fallback works there). Snapshot files (located in /var/lib/libvirt) use virsh snapshot-edit domain snapshot, where domains are passed as part of the command and snapshots have no UUIDs. Thus to keep the code simple, I'd emit just virsh snapshot-edit, which is still a useful hint and I don't believe we need to do anything beyond that. Well, we might check if the names contain dashes, and then just print the line without the names. But that's probably not worth even trying. Putting the static hint should be good enough. I'd just put there tokens that the user should replace for real values: virsh snapshot-edit 'domain-name' 'snapshot-name' or something like that. A 109+/32- patch doesn't look worth of the usability improvement that is marginal. Peter -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv2] xml: print uuids or shell-escaped names in the warning
On 10/29/2012 10:38 AM, Jiri Denemark wrote: On Thu, Oct 25, 2012 at 16:37:37 +0200, Ján Tomko wrote: In the XML warning, this prints uuids for domain names with special characters in them and shell-escaped names for other elements (like snapshosts and networks) with special names. --- When saving snapshots, the domain name is appended to the snapshot-edit command, so using a domain name that needs escaping would lead to something that can't be just fed to the shell as it would glue them together. diff to xml: shell-escape domain name in comment: - Domain names don't get escaped, UUIDs are preferred. - The command gets escaped too. diff to v1: don't try to use CDATA (it doesn't belong there) --- src/conf/domain_conf.c |6 +++- src/libvirt_private.syms |2 + src/qemu/qemu_domain.c |3 +- src/util/buf.c | 66 ++ src/util/buf.h |1 + src/util/xml.c | 62 ++- src/util/xml.h |1 + 7 files changed, 109 insertions(+), 32 deletions(-) I think we're making this too complicated for no real benefit. The goal is to provide a hint to anyone who looks at the autogenerated XML files and IMHO providing an escaped string (that would only work in environments for which it was designed). I would just keep it simple: - emit virsh command name in case name is nice - emit virsh command uuid in case name is ugly and uuid is known - emit virsh command in all other cases This should keep the hints in domain and network XML files in /etc/libvirt usable for copypaste (the UUID fallback works there). Snapshot files (located in /var/lib/libvirt) use virsh snapshot-edit domain snapshot, where domains are passed as part of the command and snapshots have no UUIDs. Thus to keep the code simple, I'd emit just virsh snapshot-edit, which is still a useful hint and I don't believe we need to do anything beyond that. Since the comment is merely a warning for people that aren't used to the commands or don't know how libvirt works, I second that opinion. I myself believe there is no need for the whole command anyway, especially when getting to know how to specify the right command-line encourages the user to get to know virsh better. Martin -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Patch replaces scriptlets with new systemd macros
On Fri, Oct 26, 2012 at 08:09:54AM +0200, Václav Pavlín wrote: Eric Blake píše v Čt 25. 10. 2012 v 10:41 -0600: Hello, Ah, then maybe you did answer the big question. Except that I don't see the updated patch - did you forget to attach it? Sure, I did forgot, sorry. Here it is... diff --git a/daemon/libvirtd.service.in b/daemon/libvirtd.service.in index b7afadf..b78c301 100644 --- a/daemon/libvirtd.service.in +++ b/daemon/libvirtd.service.in @@ -7,6 +7,7 @@ Description=Virtualization daemon Before=libvirt-guests.service After=network.target +Requires=cgconfig.service I explicitly left that out when i created the libvirtd.service file. Since systemd itself is capable of setting up cgroups by default, the common need for cgconfig.service has gone away. A minority of people may still wish to use it, but they can customize the libvirtd.service file themselves if desired - we shouldn't force cgconfig.service onto everyone esle. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Create temporary dir for socket
to avoid ENAMETOOLONG:
https://buildd.debian.org/status/fetch.php?pkg=libvirtarch=amd64ver=1.0.0~rc1-1stamp=1351453521
---
tests/qemumonitortestutils.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/tests/qemumonitortestutils.c b/tests/qemumonitortestutils.c
index 7133c99..1369cb7 100644
--- a/tests/qemumonitortestutils.c
+++ b/tests/qemumonitortestutils.c
@@ -424,9 +424,23 @@ static qemuMonitorCallbacks qemuCallbacks = {
qemuMonitorTestPtr qemuMonitorTestNew(bool json, virCapsPtr caps)
{
qemuMonitorTestPtr test;
-const char *path = abs_builddir /qemumonitorjsontest.sock;
virDomainChrSourceDef src;
+char *tmpdir = NULL, *path = NULL;
+char template[] = /tmp/libvirt_XX;
+
+tmpdir = mkdtemp(template);
+if (tmpdir == NULL) {
+virReportSystemError(errno, %s,
+ Failed to create temporary directory);
+goto error;
+}
+
+if (virAsprintf(path, %s/qemumonitorjsontest.sock, tmpdir) 0) {
+virReportOOMError();
+goto error;
+}
+
memset(src, 0, sizeof(src));
src.type = VIR_DOMAIN_CHR_TYPE_UNIX;
src.data.nix.path = (char *)path;
@@ -494,11 +508,15 @@ qemuMonitorTestPtr qemuMonitorTestNew(bool json,
virCapsPtr caps)
test-running = true;
virMutexUnlock(test-lock);
+cleanup:
+if (tmpdir)
+rmdir(tmpdir);
+VIR_FREE(path);
return test;
error:
qemuMonitorTestFree(test);
-return NULL;
+goto cleanup;
}
qemuMonitorPtr qemuMonitorTestGetMonitor(qemuMonitorTestPtr test)
--
1.7.10.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v3] xml: print uuids in the warning
In the XML warning, we print a virsh command line that can be used to
edit that XML. This patch prints UUIDs if the entity name contains
special characters (like shell metacharacters, or -- that would break
parsing of the XML comment). If the entity doesn't have a UUID, just
print the virsh command that can be used to edit it.
---
As opposed to previous versions, this doesn't use virBuffer and it
doesn't do any shell escaping at all. The name parameter can be null
now.
commit 9b704ab8235af010b1fda4886201aab02098b969
xml: omit domain name from comment if it contains double hyphen
only checked the 'name' parameter of virXMLEmitWarning. virXMLSaveFile
invocation when creating a snapshot put the domain name in 'cmd', which
means that snapshot XMLs of a domain with -- in the name still can't be
parsed by libvirt.
---
src/conf/domain_conf.c|6 +-
src/conf/network_conf.c |6 +-
src/conf/nwfilter_conf.c | 12 ++--
src/conf/storage_conf.c |6 +-
src/libvirt_private.syms |1 +
src/parallels/parallels_storage.c |3 +--
src/qemu/qemu_domain.c|9 +
src/util/xml.c| 18 +-
src/util/xml.h|1 +
9 files changed, 42 insertions(+), 20 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 90ec9aa..7bf0282 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -14288,6 +14288,7 @@ int virDomainSaveXML(const char *configDir,
virDomainDefPtr def,
const char *xml)
{
+char uuidstr[VIR_UUID_STRING_BUFLEN];
char *configFile = NULL;
int ret = -1;
@@ -14301,7 +14302,10 @@ int virDomainSaveXML(const char *configDir,
goto cleanup;
}
-ret = virXMLSaveFile(configFile, def-name, edit, xml);
+virUUIDFormat(def-uuid, uuidstr);
+ret = virXMLSaveFile(configFile,
+ virXMLPickShellSafeComment(def-name, uuidstr),
edit,
+ xml);
cleanup:
VIR_FREE(configFile);
diff --git a/src/conf/network_conf.c b/src/conf/network_conf.c
index 8976f2a..a55339d 100644
--- a/src/conf/network_conf.c
+++ b/src/conf/network_conf.c
@@ -1978,6 +1978,7 @@ int virNetworkSaveXML(const char *configDir,
virNetworkDefPtr def,
const char *xml)
{
+char uuidstr[VIR_UUID_STRING_BUFLEN];
char *configFile = NULL;
int ret = -1;
@@ -1991,7 +1992,10 @@ int virNetworkSaveXML(const char *configDir,
goto cleanup;
}
-ret = virXMLSaveFile(configFile, def-name, net-edit, xml);
+virUUIDFormat(def-uuid, uuidstr);
+ret = virXMLSaveFile(configFile,
+ virXMLPickShellSafeComment(def-name, uuidstr),
+ net-edit, xml);
cleanup:
VIR_FREE(configFile);
diff --git a/src/conf/nwfilter_conf.c b/src/conf/nwfilter_conf.c
index 27dbee8..b6d5d40 100644
--- a/src/conf/nwfilter_conf.c
+++ b/src/conf/nwfilter_conf.c
@@ -2717,6 +2717,7 @@ int virNWFilterSaveXML(const char *configDir,
virNWFilterDefPtr def,
const char *xml)
{
+char uuidstr[VIR_UUID_STRING_BUFLEN];
char *configFile = NULL;
int ret = -1;
@@ -2730,7 +2731,10 @@ int virNWFilterSaveXML(const char *configDir,
goto cleanup;
}
-ret = virXMLSaveFile(configFile, def-name, nwfilter-edit, xml);
+virUUIDFormat(def-uuid, uuidstr);
+ret = virXMLSaveFile(configFile,
+ virXMLPickShellSafeComment(def-name, uuidstr),
+ nwfilter-edit, xml);
cleanup:
VIR_FREE(configFile);
@@ -3151,6 +3155,7 @@ virNWFilterObjSaveDef(virNWFilterDriverStatePtr driver,
virNWFilterObjPtr nwfilter,
virNWFilterDefPtr def)
{
+char uuidstr[VIR_UUID_STRING_BUFLEN];
char *xml;
int ret;
@@ -3174,7 +3179,10 @@ virNWFilterObjSaveDef(virNWFilterDriverStatePtr driver,
return -1;
}
-ret = virXMLSaveFile(nwfilter-configFile, def-name, nwfilter-edit,
xml);
+virUUIDFormat(def-uuid, uuidstr);
+ret = virXMLSaveFile(nwfilter-configFile,
+ virXMLPickShellSafeComment(def-name, uuidstr),
+ nwfilter-edit, xml);
VIR_FREE(xml);
return ret;
diff --git a/src/conf/storage_conf.c b/src/conf/storage_conf.c
index 5d9e61a..9a765d8 100644
--- a/src/conf/storage_conf.c
+++ b/src/conf/storage_conf.c
@@ -1637,6 +1637,7 @@ virStoragePoolObjSaveDef(virStorageDriverStatePtr driver,
virStoragePoolObjPtr pool,
virStoragePoolDefPtr def)
{
+char uuidstr[VIR_UUID_STRING_BUFLEN];
char *xml;
int ret = -1;
@@ -1666,7 +1667,10 @@ virStoragePoolObjSaveDef(virStorageDriverStatePtr driver,
return -1;
}
-ret = virXMLSaveFile(pool-configFile,
Re: [libvirt] dhcp6, radvd, ip6tables, etc. (update)
On 10/27/2012 03:18 PM, Gene Czarcinski wrote: OK, I have the basic implementation for libvirt support of dhcp6. Let me say again that 98% of the work was already done. There is still a bunch of work today which includes writing some tests, understanding how things such as bootp, dhcp-host, etc. should be supported with dhcp6, as well as the items I discuss below. 1. Right now, the only way that dhcp6 is in effect is if there is no dhcp4 range definition. This will be fixed/expanded so that, at a minimum, you can have both a dhcp4 and dhcp6 on the same interface. However, it appears to be easier to just pass to dnsmasq ANY/EVERY dhcp4 range or dhcp6 range defined in the xml. Comments? Any input on which approach to use or avoid? For the current situation, the implementation is for one (the first) IPv4 dhcp and one (the first) IPv6 dhcp. This introduces enough little gotchas that need to be worked out. 2. I have modified radvd so both stateful (dhcp6) and stateless (SLAAC) addressing is supported with radvd for the default route. This is done on an interface basis (that is the way it works). So if any dhcp6 range is specified, then stateful is used. The way this is implemented will make it easy to add some tests verifying that the configuration parameters are working. I intend this to be an expansion to networkxml2argvtest since it has the xml specification files which determine both dnsmasq and radvd configuration parameters. NC ... working fine. 3. After completing what I thought was code that should result in a guest getting dhcp6 addresses, it was not working. Once more it took me a little time to realize that ip6tables rules were blocking it. [I have been down this path before, you would think I would realize the problem sooner.] 3a. In looking over the ip6tables rules, I saw a whole bunch of additions at the top of the INPUT chain which were accepts for udp/tcp port 53. In looking at the code in bridge_driver.c, I found that, every time a network device was started, 3 FORWARD rules and 2 INPUT rules were added, but, when the network device was destroyed, only the 3 FORWARD rules were removed. I believe this is a bug (but not high priority) and I will be submitting a separate patch to fix this. 3b. There are two different approaches for the rule which allows the dhcp6 server to work. I could add (actually insert) one rule to the INPUT chain which accepted the packet if it is -d ff02::1:2 --dport 547. Or, I could add (insert) a rule specifying -i virbr__ for every IPv6 device which would be removed when the device was destroyed. OBE - I chose the approach of adding (and removing) a rule per interface. The rule adds --dport 547 but does NOT specify -d ff02::1:2. This works With the radvd configuration and a dhcp-range specified for a ipv6 subnet, a guest will get a dhcp6 address and RA default route. 4. After getting all of this working to my satisfaction, my next mountain to climb is VM ... it really does not like network xml definitions which include a dhcp-range for an ipv6 definition. Comments? NOTE: I am implementing all of this assuming that my previous patches have been accepted ... the ones for creating a dnsmasq conf-file for parameters rather than using the dnsmasq command-line. I am sure that someone could spend the time refitting the dhcp6 patches to the old code but why get aggravated? If you folks do not want to do things that way, fine, please say so. But if it is going to be accepted, then I would like some indication of this. 5. As far as I can tell (or at least this is for dnsmasq), dhcp-no-override, enable-tftp, tftp-root=, and dhcp-boot= are all IPv4 only and thus ignored for IPv6 in bridge_driver. I have not looked to see what network_conf.c does. 6. Handling of the info for addn-hosts file and the dhcp-hostsfile. This currently works because things are forced so that one and only one IPv4 dhcp definition will be handled. With the addition of IPv6 dhcp, things fall apart. 6a. addn-hosts: The addn-hosts file is similar to the /etc/hosts file in both form and function. The dns-host specification is done on an interface bases and, thus, the processing of the data and creation of the file should only be done once. 6b. dhcp-hostsfile (dhcp-host=): This needs to be done at least for every ip definition that is processed for dhcp. Initially, this will be for dhcp4 only until I can figure out how to do it for dhcp6. 6c. Thus, networkBuildDnsmasqHostsfile() needs to be split into two functions [one for addn-hosts and one for dhcp-hosts]. Additionally, all the functions which call dnsmasqSave() need to be reworked appropriately. 7. So far, the only things I have done involving the xml specification is to enable dhcp for IPv6. However, the xml to specify a dns addn-hosts appears, IMHO, to be overly verbose and complicated. So, while allowing the current xml to be valid, I
Re: [libvirt] [PATCH v3] xml: print uuids in the warning
On 10/29/12 13:15, Ján Tomko wrote:
In the XML warning, we print a virsh command line that can be used to
edit that XML. This patch prints UUIDs if the entity name contains
special characters (like shell metacharacters, or -- that would break
parsing of the XML comment). If the entity doesn't have a UUID, just
print the virsh command that can be used to edit it.
---
As opposed to previous versions, this doesn't use virBuffer and it
doesn't do any shell escaping at all. The name parameter can be null
now.
commit 9b704ab8235af010b1fda4886201aab02098b969
xml: omit domain name from comment if it contains double hyphen
only checked the 'name' parameter of virXMLEmitWarning. virXMLSaveFile
invocation when creating a snapshot put the domain name in 'cmd', which
means that snapshot XMLs of a domain with -- in the name still can't be
parsed by libvirt.
---
src/conf/domain_conf.c|6 +-
src/conf/network_conf.c |6 +-
src/conf/nwfilter_conf.c | 12 ++--
src/conf/storage_conf.c |6 +-
src/libvirt_private.syms |1 +
src/parallels/parallels_storage.c |3 +--
src/qemu/qemu_domain.c|9 +
src/util/xml.c| 18 +-
src/util/xml.h|1 +
9 files changed, 42 insertions(+), 20 deletions(-)
[...]
diff --git a/src/util/xml.c b/src/util/xml.c
index f3dc256..dad9227 100644
--- a/src/util/xml.c
+++ b/src/util/xml.c
@@ -780,6 +780,16 @@ error:
goto cleanup;
}
+const char *virXMLPickShellSafeComment(const char *str1, const char *str2)
+{
+if(str1 !strpbrk(str1, \r\t\n !\#$'()*;?[\\]^`{|}~)
+ !strstr(str1, --))
+return str1;
+if(str2 !strpbrk(str2, \r\t\n !\#$'()*;?[\\]^`{|}~)
+ !strstr(str2, --))
+return str2;
For now, this second check is not really needed as you always pass the
UUID that is safe, but it doesn't hurt to check anyways if somebody
would like to use this helper somewhere else.
+return NULL;
+}
static int virXMLEmitWarning(int fd,
const char *name,
@@ -794,7 +804,7 @@ OVERWRITTEN AND LOST. Changes to this xml configuration
should be made using:\n\
or other application using the libvirt API.\n\
--\n\n;
Hm, I don't like formatting of these strings. I'll send a follow-up to
clean this up as it's not caused by you.
-if (fd 0 || !name || !cmd) {
+if (fd 0 || !cmd) {
errno = EINVAL;
return -1;
}
ACK pushed.
Peter
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] util: Re-format literal strings in virXMLEmitWarning
And drop a stray space at the end of the first line of the warning.
---
Yes, some lines exceed 80 columns.
---
src/util/xml.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/src/util/xml.c b/src/util/xml.c
index dad9227..30323b3 100644
--- a/src/util/xml.c
+++ b/src/util/xml.c
@@ -796,13 +796,15 @@ static int virXMLEmitWarning(int fd,
const char *cmd)
{
size_t len;
-const char *prologue = !--\n\
-WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE \n\
-OVERWRITTEN AND LOST. Changes to this xml configuration should be made
using:\n\
- virsh ;
-const char *epilogue = \n\
-or other application using the libvirt API.\n\
---\n\n;
+const char *prologue =
+!--\n
+WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO
BE\n
+OVERWRITTEN AND LOST. Changes to this xml configuration should be
made using:\n
+ virsh ;
+const char *epilogue =
+\n
+or other application using the libvirt API.\n
+--\n\n;
if (fd 0 || !cmd) {
errno = EINVAL;
--
1.7.12.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] util: Re-format literal strings in virXMLEmitWarning
On Mon, Oct 29, 2012 at 03:22:05PM +0100, Peter Krempa wrote:
And drop a stray space at the end of the first line of the warning.
---
Yes, some lines exceed 80 columns.
---
src/util/xml.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/src/util/xml.c b/src/util/xml.c
index dad9227..30323b3 100644
--- a/src/util/xml.c
+++ b/src/util/xml.c
@@ -796,13 +796,15 @@ static int virXMLEmitWarning(int fd,
const char *cmd)
{
size_t len;
-const char *prologue = !--\n\
-WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE \n\
-OVERWRITTEN AND LOST. Changes to this xml configuration should be made
using:\n\
- virsh ;
-const char *epilogue = \n\
-or other application using the libvirt API.\n\
---\n\n;
+const char *prologue =
+!--\n
+WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY
TO BE\n
+OVERWRITTEN AND LOST. Changes to this xml configuration should be
made using:\n
+ virsh ;
+const char *epilogue =
+\n
+or other application using the libvirt API.\n
+--\n\n;
ACK
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/2] qemu: Fix address/ is ignored for USB disks
On Fri, Oct 26, 2012 at 09:08:41AM +, Vladislav Bogdanov wrote: This is a follow-up to https://bugzilla.redhat.com/show_bug.cgi?id=861309 If one has USB disks configured for domain with explicit address/, libvirtd ignores that node when building qemu command line. So, disk is connected to the first free USB port implicitly by qemu. That breaks other USB devices which have explicit address/ - ports they should be connected to may be already occupied by disks. With first patch applied, if one has USB disk connected to the USB hub, qemu fails to start, because it does not know anything about hubs yet (when parsing disks). That's why second patch is needed. Vladislav Bogdanov (2): qemu: Do not ignore address for USB disks qemu: pass -usb and usb hubs earlier, so USB disks with static address are handled properly ACK to both Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvirt can not get right stats of a rbd pool
On Fri, Oct 26, 2012 at 11:04:05AM +0800, yue wrote: Allocation exceed Capacity ,but Available is not 0. #virsh pool-info 2361a6d4-0edc-3534-87ae-e7ee09199921 Name: 2361a6d4-0edc-3534-87ae-e7ee09199921 UUID: 2361a6d4-0edc-3534-87ae-e7ee09199921 State: running Persistent: yes Autostart: no Capacity: 285.57 GiB Allocation: 489.89 GiB Available: 230.59 GiB Hmm, these values do look a little bit suspect, but I don't know enough about RBD to suggest what might be going wrong. I'm copying Wido who wrote this code originally thus might have an idea. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] util: Re-format literal strings in virXMLEmitWarning
On 10/29/12 15:23, Daniel P. Berrange wrote: On Mon, Oct 29, 2012 at 03:22:05PM +0100, Peter Krempa wrote: And drop a stray space at the end of the first line of the warning. --- Yes, some lines exceed 80 columns. --- src/util/xml.c | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) Thanks, pushed. Peter -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvirt can not get right stats of a rbd pool
On 10/29/2012 03:33 PM, Daniel P. Berrange wrote: On Fri, Oct 26, 2012 at 11:04:05AM +0800, yue wrote: Allocation exceed Capacity ,but Available is not 0. #virsh pool-info 2361a6d4-0edc-3534-87ae-e7ee09199921 Name: 2361a6d4-0edc-3534-87ae-e7ee09199921 UUID: 2361a6d4-0edc-3534-87ae-e7ee09199921 State: running Persistent: yes Autostart: no Capacity: 285.57 GiB Allocation: 489.89 GiB Available: 230.59 GiB Hmm, these values do look a little bit suspect, but I don't know enough about RBD to suggest what might be going wrong. I'm copying Wido who wrote this code originally thus might have an idea. I think I know where this is coming from, a little background about RBD. RBD is a disk device striped over 4MB RADOS objects inside a Ceph cluster. RBD devices are sparse, which means that (RADOS) objects get created whenever a write comes. When a read comes for a non-existing object 4MB of nothing is returned. However, when you do: $ rbd info disk1 You will get that the object COULD be 100GB, but that doesn't mean it actually occupies 100GB of disk space. The problem is that you can't (at this point) find out how much space a RBD device actually occupies. Yes, it can be done, but that should not be done in the libvirt driver and it is pretty heavy for the Ceph cluster. Also, a RBD device of 100GB could take up 300GB of space when your replication is set to 3x. What you are seeing there is that you over provisioned your Ceph cluster by creating images which exceed 285GB in total. Wido Daniel -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] [DRAFT] handle qemu event GUEST_PANICKED
On Thu, Oct 25, 2012 at 04:04:23PM +0800, Hu Tao wrote: This is for early review, comments are welcome! qemu is adding a method to detect guest panic, and a new event GUEST_PANICKED[1]. This patch adds support for GUEST_PANICKED. But I have two questions: - to react to GUEST_PANICKED, can xml element on_crash be used as the action to take, or do I have to invent another xml element to configure the action? Using on_crash is the right thing todo, since that matches what we do with Xen. - Currently libvirt relies on watchdog to detect guest panic, but this way is not that reliable(there has to be a watchdog device, the watchdog itself has to be working when panic occurs), so it seems to be appropriate to remove this method from libvirt as there is a better one. But, will the removal cause any problems, such as backward compatibility, user confusion, etc.? I don't think we need to touch the watchdog code at all. Not all guest OS will support this new GUEST_PANICKED event, while they probably do have drivers for the watchdog devices. So it is perfectly ok to have both the panick event and the watchdog events available. Mgmt apps can decide which to use as they see fit. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] daemon: Fix LIBVIRT_DEBUG=1 default output
On Wed, Oct 24, 2012 at 05:01:54PM -0400, Cole Robinson wrote: This commit changes the behavior of LIBVIRT_DEBUG=1 libvirtd: $ git show 7022b09111d4322d21396a70d58320a9ad773962 commit 7022b09111d4322d21396a70d58320a9ad773962 Author: Daniel P. Berrange berra...@redhat.com Date: Thu Sep 27 13:13:09 2012 +0100 Automatically enable systemd journal logging Probe to see if the systemd journal is accessible, and if so enable logging to the journal by default, rather than stderr (current default under systemd). Previously 'LIBVIRT_DEBUG=1 /usr/sbin/libvirtd' would show all debug output to stderr, now it send debug output to the journal. Only use the journal by default if running in daemon mode, or if stdin is _not_ a tty. This should make libvirtd launched from systemd use the journal, but preserve the old behavior in most situations. Yep, makes total sense. I should have noticed that when writing this originally. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v2] sanlock: Introduce 'user' and 'group' conf variables
through which user set under what permissions does sanlock
daemon run so libvirt will set the same permissions for
files exposed to it.
---
diff to v1:
-update spec file so sanlock dir is installed with root:sanlock
iff group sanlock exists
docs/locking.html.in| 22 +
libvirt.spec.in |7 +++
src/locking/libvirt_sanlock.aug |2 +
src/locking/lock_driver_sanlock.c | 76 ++-
src/locking/sanlock.conf| 11 -
src/locking/test_libvirt_sanlock.aug.in |2 +
6 files changed, 118 insertions(+), 2 deletions(-)
diff --git a/docs/locking.html.in b/docs/locking.html.in
index 6d7b517..19dd6a3 100644
--- a/docs/locking.html.in
+++ b/docs/locking.html.in
@@ -121,6 +121,28 @@
/pre
p
+ If your sanlock daemon happen to run under non-root
+ privileges, you need to tell this to libvirt so it
+ chowns created files correctly. This can be done by
+ setting codeuser/code and/or codegroup/code
+ variables in the configuration file. Accepted values
+ range is specified in description to the same
+ variables in code/etc/libvirt/qemu.conf/code. For
+ example:
+/p
+
+pre
+ augtool -s set /files/etc/libvirt/qemu-sanlock.conf/user sanlock
+ augtool -s set /files/etc/libvirt/qemu-sanlock.conf/group sanlock
+/pre
+
+p
+ But remember, that if this is NFS share, you need a
+ no_root_squash-ed one for chown (and chmod possibly)
+ to succeed.
+/p
+
+p
In terms of storage requirements, if the filesystem
uses 512 byte sectors, you need to allow for code1MB/code
of storage for each guest disk. So if you have a network
diff --git a/libvirt.spec.in b/libvirt.spec.in
index ebebfab..edc43af 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -1568,6 +1568,13 @@ fi
/bin/systemctl try-restart libvirt-guests.service /dev/null 21 || :
%endif
+%pre lock-sanlock
+if $(getent group sanlock /dev/null; echo $?) == 0
+chmod 0770 %{_localstatedir}/lib/libvirt/sanlock
+chown root:sanlock %{_localstatedir}/lib/libvirt/sanlock
+endif
+
+
%files
%defattr(-, root, root)
diff --git a/src/locking/libvirt_sanlock.aug b/src/locking/libvirt_sanlock.aug
index d65b002..a78a444 100644
--- a/src/locking/libvirt_sanlock.aug
+++ b/src/locking/libvirt_sanlock.aug
@@ -22,6 +22,8 @@ module Libvirt_sanlock =
| int_entry host_id
| bool_entry require_lease_for_disks
| bool_entry ignore_readonly_and_shared_disks
+ | str_entry user
+ | str_entry group
let comment = [ label #comment . del /#[ \t]*/ # . store /([^
\t\n][^\n]*)?/ . del /\n/ \n ]
let empty = [ label #empty . eol ]
diff --git a/src/locking/lock_driver_sanlock.c
b/src/locking/lock_driver_sanlock.c
index 4682701..d988a6d 100644
--- a/src/locking/lock_driver_sanlock.c
+++ b/src/locking/lock_driver_sanlock.c
@@ -71,6 +71,10 @@ struct _virLockManagerSanlockDriver {
int hostID;
bool autoDiskLease;
char *autoDiskLeasePath;
+
+/* under which permissions does sanlock run */
+uid_t user;
+gid_t group;
};
static virLockManagerSanlockDriver *driver = NULL;
@@ -94,6 +98,7 @@ static int virLockManagerSanlockLoadConfig(const char
*configFile)
{
virConfPtr conf;
virConfValuePtr p;
+char *tmp;
if (access(configFile, R_OK) == -1) {
if (errno != ENOENT) {
@@ -142,6 +147,39 @@ static int virLockManagerSanlockLoadConfig(const char
*configFile)
else
driver-requireLeaseForDisks = !driver-autoDiskLease;
+p = virConfGetValue(conf, user);
+CHECK_TYPE(user, VIR_CONF_STRING);
+if (p) {
+if (!(tmp = strdup(p-str))) {
+virReportOOMError();
+virConfFree(conf);
+return -1;
+}
+
+if (virGetUserID(tmp, driver-user) 0) {
+VIR_FREE(tmp);
+virConfFree(conf);
+return -1;
+}
+VIR_FREE(tmp);
+}
+
+p = virConfGetValue (conf, group);
+CHECK_TYPE (group, VIR_CONF_STRING);
+if (p) {
+if (!(tmp = strdup(p-str))) {
+virReportOOMError();
+virConfFree(conf);
+return -1;
+}
+if (virGetGroupID(tmp, driver-group) 0) {
+VIR_FREE(tmp);
+virConfFree(conf);
+return -1;
+}
+VIR_FREE(tmp);
+}
+
virConfFree(conf);
return 0;
}
@@ -177,6 +215,7 @@ static int virLockManagerSanlockSetupLockspace(void)
* space allocated for it and is initialized with lease
*/
if (stat(path, st) 0) {
+int perms = 0600;
VIR_DEBUG(Lockspace %s does not yet exist, path);
if (!(dir = mdir_name(path))) {
@@ -191,7 +230,10 @@ static int virLockManagerSanlockSetupLockspace(void)
goto error;
}
-if ((fd = open(path, O_WRONLY|O_CREAT|O_EXCL,
Re: [libvirt] Can we run guest OS without using NAT and iptables?
On 10/29/2012 05:30 AM, Stefan Hajnoczi wrote: On Mon, Oct 29, 2012 at 12:55:43PM +0530, freak 62 wrote: Can we run guest o.s. on KVM without enabling NAT and iptables? The reason to do this is , I wanted to disable conntrack module from my system and to disable that I must have to delete iptable and NAT. I am getting the following message, when I start guest o.s. on KVM (iptable and NAT disabled): Error starting domain: internal error 'Network default' is not active. Is their any way to run guest o.s. with NAT disabled? or Is their any way to disable conntrack module and still can use KVM to run guest OS ? I am using Ubuntu 10.04 You can remove the default virsh network like sudo virsh net-destroy default sudo virsh net-undefine default The most common networking setup that doesn't use NAT + iptables is probably bridged networking: http://wiki.libvirt.org/page/Networking#Bridged_networking_.28aka_.22shared_physical_device.22.29 - Cole -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Xen-devel] libxl drivers for libvirt?
Ian Campbell wrote: On Fri, 2012-10-26 at 14:03 +0100, George Dunlap wrote: On 24/10/12 19:11, Jim Fehlig wrote: * What kind of Xen support for libxl is in the libvirt development branch, and do you have an idea when full support for 4.2 (at least, including migration, suspend/resume, c) might be available? Nothing has changed in git master over what is available in 0.10.2, but we are now starting to pick up this work. Our priorities are to first get the libxl driver compiling against 4.2 and all of the existing functionality that works with 4.1 working with 4.2, followed by closing the feature gap with the legacy xen driver, and finally closing the feature gap with the qemu driver where it makes sense. This is obviously quite a bit of work and any help would be appreciated :). BTW, we don't have any motivation to add features to the 4.1 version of the libvirt libxl driver. That sounds like a good plan. For 4.1, xend is still the default toolstack, and libxl is a tech preview; for 4.2, xl is the default toolstack, and (if I understand correctly) we're officially going to be supporting the libxl interface in a backwards-compatible way from here forward. It seems to me that if you have trouble supporting both libxl 4.2 and libxl 4.1, that it might be better just to drop 4.1 support and focus on 4.2. Ian Campbell / Jackson: Thoughts? CC'ing libvirt community to get their input. That's what I would do if I were them ;-) I tend to agree that this might be the best approach. The libxl in Xen 4.1 is essentially a one-off and I question whether we should pollute the libvirt libxl driver code with support for a dead, tech preview interface. Xend is still the primary toolstack in Xen 4.1.x, and libvirt has a stable, functional driver for this toolstack that can (should) be used in Xen 4.1.x deployments. Is anyone using the libvirt libxl driver with Xen 4.1 for anything other than development or experimentation? Another option would be to fork into 4.1 and 4.2+ versions and to stop adding new stuff to the 4.1 copy. That has its own downsides though. I'd like to hear what the libvirt community thinks about only supporting Xen = 4.2 in the libxl driver. Regards, Jim -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Xen-devel] libxl drivers for libvirt?
On Mon, Oct 29, 2012 at 09:55:28AM -0600, Jim Fehlig wrote: Ian Campbell wrote: On Fri, 2012-10-26 at 14:03 +0100, George Dunlap wrote: On 24/10/12 19:11, Jim Fehlig wrote: * What kind of Xen support for libxl is in the libvirt development branch, and do you have an idea when full support for 4.2 (at least, including migration, suspend/resume, c) might be available? Nothing has changed in git master over what is available in 0.10.2, but we are now starting to pick up this work. Our priorities are to first get the libxl driver compiling against 4.2 and all of the existing functionality that works with 4.1 working with 4.2, followed by closing the feature gap with the legacy xen driver, and finally closing the feature gap with the qemu driver where it makes sense. This is obviously quite a bit of work and any help would be appreciated :). BTW, we don't have any motivation to add features to the 4.1 version of the libvirt libxl driver. That sounds like a good plan. For 4.1, xend is still the default toolstack, and libxl is a tech preview; for 4.2, xl is the default toolstack, and (if I understand correctly) we're officially going to be supporting the libxl interface in a backwards-compatible way from here forward. It seems to me that if you have trouble supporting both libxl 4.2 and libxl 4.1, that it might be better just to drop 4.1 support and focus on 4.2. Ian Campbell / Jackson: Thoughts? CC'ing libvirt community to get their input. That's what I would do if I were them ;-) I tend to agree that this might be the best approach. The libxl in Xen 4.1 is essentially a one-off and I question whether we should pollute the libvirt libxl driver code with support for a dead, tech preview interface. Xend is still the primary toolstack in Xen 4.1.x, and libvirt has a stable, functional driver for this toolstack that can (should) be used in Xen 4.1.x deployments. Is anyone using the libvirt libxl driver with Xen 4.1 for anything other than development or experimentation? Another option would be to fork into 4.1 and 4.2+ versions and to stop adding new stuff to the 4.1 copy. That has its own downsides though. I'd like to hear what the libvirt community thinks about only supporting Xen = 4.2 in the libxl driver. Given that libxl was tech preview in Xen 4.1, I'm fine with any proposal to have libvirt libxl only work with Xen 4.2, if that's what you feel is the most appropriate plan. You're the primary maintainer if this libvirt driver, so I'll defer to your technical knowledge here on the supportability issues here. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemu: Report errors from iohelper
On 25.10.2012 23:56, Eric Blake wrote:
On 10/24/2012 09:49 AM, Michal Privoznik wrote:
Currently, we use iohelper when saving/restoring a domain.
However, if there's some kind of error (like I/O) it is not
propagated to libvirt. Since it is not qemu who is doing
the actual write() it will not get error. The iohelper does.
Therefore we should check for iohelper errors as it makes
libvirt more user friendly.
---
diff to v1:
-incorporate the event loop to read iohelper's stderr
@@ -3282,9 +3283,11 @@ doCoreDump(struct qemud_driver *driver,
+/* deliberately don't use virCommandNonblockingFDs here as it is all or
+ * nothing. And we want iohelper's stdin to block. */
+if (virSetNonBlock(ret-err_fd) 0) {
This comment is confusing, since you say we don't use nonblocking and
then immediately set our side of stderr to nonblocking. Maybe you meant
to say that we leave helper's stdin or stdout alone (default blocking)
because they are not tied to our event loop, but set our side of stderr
to be nonblocking so we can read it from our event loop.
ACK once you fix up that comment.
Thanks, pushed with this:
diff --git a/src/util/virfile.c b/src/util/virfile.c
index 36b3420..9593151 100644
--- a/src/util/virfile.c
+++ b/src/util/virfile.c
@@ -291,7 +291,9 @@ virFileWrapperFdNew(int *fd, const char *name, unsigned int
flags)
goto error;
/* deliberately don't use virCommandNonblockingFDs here as it is all or
- * nothing. And we want iohelper's stdin to block. */
+ * nothing. And we want iohelper's stdin and stdout to block (default).
+ * However, stderr is read within event loop and therefore it must be
+ * nonblocking.*/
if (virSetNonBlock(ret-err_fd) 0) {
virReportSystemError(errno, %s,
_(Failed to set non-blocking
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2] sanlock: Introduce 'user' and 'group' conf variables
On 29.10.2012 16:18, Michal Privoznik wrote: through which user set under what permissions does sanlock daemon run so libvirt will set the same permissions for files exposed to it. --- diff to v1: -update spec file so sanlock dir is installed with root:sanlock iff group sanlock exists docs/locking.html.in| 22 + libvirt.spec.in |7 +++ src/locking/libvirt_sanlock.aug |2 + src/locking/lock_driver_sanlock.c | 76 ++- src/locking/sanlock.conf| 11 - src/locking/test_libvirt_sanlock.aug.in |2 + 6 files changed, 118 insertions(+), 2 deletions(-) While this can be looked at as feature, in fact it is a bug fix. With recent sanlock, which does no longer run under root:root and thus is not able to access /var/lib/libvirt/sanlock belonging to root:root we need even the config file addition. So even though we entered the freeze, I'd gladly see this in. Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libxl driver doesn't build with xen 4.2
Cole Robinson wrote: On 10/26/2012 10:03 PM, Cole Robinson wrote: Hi Jim, The libvirt libxl driver doesn't build with xen 4.2. There was a small thread about it on fedora's virt list: http://lists.fedoraproject.org/pipermail/virt/2012-October/003446.html I saw that you had a few xen 4.2 patches land recently, and I'm just curious if you were aware of the libxl issues/possibly had any patches brewing. Currently in fedora we've disabled building the libxl driver so the xen guys can pull in their latest bits. Yes, I've disabled the libxl driver in openSUSE Factory as well, where we have Xen 4.2. Sounds like someone else at least is trying to fix the issues as well: http://lists.fedoraproject.org/pipermail/xen/2012-October/005923.html That was a thread asking me about the status of the libvirt libxl driver for Xen 4.2 :). Ondrej is working on some libxl driver patches to support Xen 4.2. But that thread has brought up an interesting conversation on whether it is desirable to support the libxl in Xen 4.1 at all. I'll respond to the latest message in that thread and cc libvirt list so the libvirt community can chime in. Regards, Jim -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] problem trying to use net-update
On 10/24/2012 01:31 PM, Laine Stump wrote: Well, you could indirectly trigger it by adding (and then removing) a dhcp range element with virsh net-update. Is there some way (some command) that will cause dnsmasq to be restarted (possibly with new parameters as it re-does its configuration). If this was done, then little, except some cached names, would be lost). If there is not, maybe there should be. However, there are likely limits such as not changing the gateway addresses on the interface. I recently made a patch to check for a running dnsmasq anytime libvirt is restarted. If it's not running, it will be restarted. If it is running, a SIGHUP will be sent. Aside from that, the (newly created) accepted way to change a network's config while the network is up is to use the virNetworkUpdate API (available via virsh net-update). It permits you to add/delete/modify certain parts of the network config and have those changes take effect immediately if desired. the bridge_driver backend of virNetworkUpdate decides when it is necessary to either SIGHUP or restart dnsmasq according to what parts of the network definition have changed. A live change of the entire network definition (i.e. with virNetworkDefine() isn't supported, and won't be - anything that you want to be able to change while the network is up should be added to the sections modifiable by virNetworkUpdate. This will permit us to easily figure out what re-initialization is needed for a particular change without needing to just redo everything (for example, if a dhcp static host is added, we just need to SIGHUP dnsmasq, but if a dynamic range is added/deleted, we need to restart dnsmasq. If an IP address is added/removed from the bridge, we should be able to write code to simply redo the IP addresses on the existing bridge, rather than tear it down and build a new bridge (although that one isn't implemented yet). I finally got around to testing this how is this suppose to work? Is this a work in progress? I did not try this first but it is what seemed to work ... I edited a network definition so that it space for a dhcp-range addition. Then, with the network not started, i used net-update to add a ip-dhcp-range and it worked (the file was updated). Edit the xml again to remove the added range, and start the network. Do the same thing again with net-update ... the file was updated and dnsmasq was restarted. What I started out to do and what did not work was to add a dns-host definition to a network. This should not require a restart but result a [Refresh] SIGHUP of the dnsmasq process. 1. Using net-edit to add the dns-host definition [resulted in networkCreate() being executed] and then issuing SIGHUP to the process and the addnhosts file was read and things worked as I wanted them to. 2. Trying to get the same thing accomplished using net-update [dns-host] was a failure. The only thing that happened was to get the following error message: this function is not supported by the connection driver: can't update 'dns host' section of network 'default' where I tried a bunch of different networks. Some of them already had a dns-host definition and some did not. Should I expect this to work? Is this a bug? Gene -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemu: Report errors from iohelper
On 10/29/2012 10:08 AM, Michal Privoznik wrote: On 25.10.2012 23:56, Eric Blake wrote: On 10/24/2012 09:49 AM, Michal Privoznik wrote: Currently, we use iohelper when saving/restoring a domain. However, if there's some kind of error (like I/O) it is not propagated to libvirt. Since it is not qemu who is doing the actual write() it will not get error. The iohelper does. Therefore we should check for iohelper errors as it makes libvirt more user friendly. --- ACK once you fix up that comment. Thanks, pushed with this: diff --git a/src/util/virfile.c b/src/util/virfile.c index 36b3420..9593151 100644 --- a/src/util/virfile.c +++ b/src/util/virfile.c @@ -291,7 +291,9 @@ virFileWrapperFdNew(int *fd, const char *name, unsigned int flags) goto error; /* deliberately don't use virCommandNonblockingFDs here as it is all or - * nothing. And we want iohelper's stdin to block. */ + * nothing. And we want iohelper's stdin and stdout to block (default). + * However, stderr is read within event loop and therefore it must be + * nonblocking.*/ Shoot, now I'm getting link failures: CCLD libvirt_iohelper ./.libs/libvirt_util.a(libvirt_util_la-event_poll.o): In function `virEventPollAddHandle': /home/dummy/libvirt/src/util/event_poll.c:136: undefined reference to `libvirt_event_poll_add_handle_semaphore' ... ./.libs/libvirt_util.a(libvirt_util_la-event_poll.o):(.note.stapsdt+0x24): undefined reference to `libvirt_event_poll_add_handle_semaphore' Something in this patch make libvirt_iohelper now drag in new link dependencies that aren't being met. But since you didn't see this in your testing, it's got to be some difference in the configure results for which devel libraries were found on your platform vs. mine. I'm trying to narrow down what might be the culprit, but the .note.stapsdt portion of the error message makes me think it has to do with systemtap support. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] dhcp6, radvd, ip6tables, etc. (update)
On 10/29/2012 08:26 AM, Gene Czarcinski wrote: On 10/27/2012 03:18 PM, Gene Czarcinski wrote: OK, I have the basic implementation for libvirt support of dhcp6. Let me say again that 98% of the work was already done. There is still a bunch of work today which includes writing some tests, understanding how things such as bootp, dhcp-host, etc. should be supported with dhcp6, as well as the items I discuss below. 1. Right now, the only way that dhcp6 is in effect is if there is no dhcp4 range definition. This will be fixed/expanded so that, at a minimum, you can have both a dhcp4 and dhcp6 on the same interface. However, it appears to be easier to just pass to dnsmasq ANY/EVERY dhcp4 range or dhcp6 range defined in the xml. Comments? Any input on which approach to use or avoid? For the current situation, the implementation is for one (the first) IPv4 dhcp and one (the first) IPv6 dhcp. This introduces enough little gotchas that need to be worked out. I think that is the proper thing to do for now. As discussed earlier, before supporting dhcp on multiple subnets of the same protocol (ipv6 vs ipv4) we would need to decide why and how we want to do that - IPs assigned from different subnets need to be matched with the IP address of that subnet, and it will take a more complicated dnsmasq commandline to do that, iirc. 2. I have modified radvd so both stateful (dhcp6) and stateless (SLAAC) addressing is supported with radvd for the default route. This is done on an interface basis (that is the way it works). So if any dhcp6 range is specified, then stateful is used. The way this is implemented will make it easy to add some tests verifying that the configuration parameters are working. I intend this to be an expansion to networkxml2argvtest since it has the xml specification files which determine both dnsmasq and radvd configuration parameters. NC ... working fine. 3. After completing what I thought was code that should result in a guest getting dhcp6 addresses, it was not working. Once more it took me a little time to realize that ip6tables rules were blocking it. [I have been down this path before, you would think I would realize the problem sooner.] 3a. In looking over the ip6tables rules, I saw a whole bunch of additions at the top of the INPUT chain which were accepts for udp/tcp port 53. In looking at the code in bridge_driver.c, I found that, every time a network device was started, 3 FORWARD rules and 2 INPUT rules were added, but, when the network device was destroyed, only the 3 FORWARD rules were removed. I believe this is a bug (but not high priority) and I will be submitting a separate patch to fix this. 3b. There are two different approaches for the rule which allows the dhcp6 server to work. I could add (actually insert) one rule to the INPUT chain which accepted the packet if it is -d ff02::1:2 --dport 547. Or, I could add (insert) a rule specifying -i virbr__ for every IPv6 device which would be removed when the device was destroyed. OBE - I chose the approach of adding (and removing) a rule per interface. The rule adds --dport 547 but does NOT specify -d ff02::1:2. I haven't looked at how dhcp6 works, but if its anything like dhcp4, the IP address is irrelevant and shouldn't be included in the rule. As long as your rule specifies both the interface and port, that should be fine (take a look at the rules already being added for dhcp4) (and no, I have absolutely no idea why we add a rule to allow *tcp* on the dhcp port. It's just been that way since the first day I set eyes on the code). This works With the radvd configuration and a dhcp-range specified for a ipv6 subnet, a guest will get a dhcp6 address and RA default route. Interesting - so both radvd and dnsmasq are involved, correct? 4. After getting all of this working to my satisfaction, my next mountain to climb is VM ... it really does not like network xml definitions which include a dhcp-range for an ipv6 definition. Comments? NOTE: I am implementing all of this assuming that my previous patches have been accepted ... the ones for creating a dnsmasq conf-file for parameters rather than using the dnsmasq command-line. I have no problem with the convert from long commandline to conf file patch except for the bit that points to a conf directory where user supplied conf files can be added. Aside from that part needing to be in a spearate patch, if we're going to add that kind of configurability, we need to do it in a way that will allow us to easily see that the user is playing outside the fence (otherwise we spend a lot of time chasing bugs that end up being caused by user-supplied options). Because we're in freeze right now I haven't spent a lot of time discussing that, but planned to send a message about it when I get a minute. I am sure that someone could spend the time refitting the dhcp6 patches to the old code but why get aggravated? If you
[libvirt] [PATCH] build: fix linking with systemtap probes
Commit 34e8f63a3 altered virfile.o to drag in additional symbols, which in turn led to pulling in other .o files and eventually causing a link failure when systemtap probes are enabled, such as: ./.libs/libvirt_util.a(libvirt_util_la-event_poll.o): In function `virEventPollRunOnce': /home/dummy/libvirt/src/util/event_poll.c:614: undefined reference to `libvirt_event_poll_run_semaphore' ./.libs/libvirt_util.a(libvirt_util_la-event_poll.o):(.note.stapsdt+0x24): undefined reference to `libvirt_event_poll_add_handle_semaphore' Even though libvirt_iohelper and libvirt_parthelper don't directly use the portion of virfile.o that drags in probing, it was easier to satisfy the linker and get the build back up, than to figure out whether it is even possible or worth trying to disentangle the mess. * src/Makefile.am (libvirt_iohelper_LDADD) (libvirt_parthelper_LDADD): Use libvirt_probes.lo when needed. --- Pushing under the build-breaker rule, in response to: https://www.redhat.com/archives/libvir-list/2012-October/msg01679.html src/Makefile.am | 6 ++ 1 file changed, 6 insertions(+) diff --git a/src/Makefile.am b/src/Makefile.am index 187663f..1f32263 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -1631,6 +1631,9 @@ libvirt_iohelper_LDFLAGS = $(WARN_LDFLAGS) $(AM_LDFLAGS) libvirt_iohelper_LDADD = \ libvirt_util.la \ ../gnulib/lib/libgnu.la +if WITH_DTRACE_PROBES +libvirt_iohelper_LDADD += libvirt_probes.lo +endif libvirt_iohelper_CFLAGS = $(AM_CFLAGS) endif @@ -1645,6 +1648,9 @@ libvirt_parthelper_LDADD =\ $(LIBPARTED_LIBS) \ libvirt_util.la \ ../gnulib/lib/libgnu.la +if WITH_DTRACE_PROBES +libvirt_parthelper_LDADD += libvirt_probes.lo +endif libvirt_parthelper_CFLAGS = $(LIBPARTED_CFLAGS) $(AM_CFLAGS) endif -- 1.7.11.7 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv2] xml: print uuids or shell-escaped names in the warning
On Mon, Oct 29, 2012 at 11:07:20AM +0100, Peter Krempa wrote: On 10/29/12 10:38, Jiri Denemark wrote: On Thu, Oct 25, 2012 at 16:37:37 +0200, Ján Tomko wrote: In the XML warning, this prints uuids for domain names with special characters in them and shell-escaped names for other elements (like snapshosts and networks) with special names. --- When saving snapshots, the domain name is appended to the snapshot-edit command, so using a domain name that needs escaping would lead to something that can't be just fed to the shell as it would glue them together. diff to xml: shell-escape domain name in comment: - Domain names don't get escaped, UUIDs are preferred. - The command gets escaped too. diff to v1: don't try to use CDATA (it doesn't belong there) --- src/conf/domain_conf.c |6 +++- src/libvirt_private.syms |2 + src/qemu/qemu_domain.c |3 +- src/util/buf.c | 66 ++ src/util/buf.h |1 + src/util/xml.c | 62 ++- src/util/xml.h |1 + 7 files changed, 109 insertions(+), 32 deletions(-) I think we're making this too complicated for no real benefit. The goal is to provide a hint to anyone who looks at the autogenerated XML files and IMHO providing an escaped string (that would only work in environments for which it was designed). I would just keep it simple: - emit virsh command name in case name is nice - emit virsh command uuid in case name is ugly and uuid is known - emit virsh command in all other cases This looks reasonable. This should keep the hints in domain and network XML files in /etc/libvirt usable for copypaste (the UUID fallback works there). Snapshot files (located in /var/lib/libvirt) use virsh snapshot-edit domain snapshot, where domains are passed as part of the command and snapshots have no UUIDs. Thus to keep the code simple, I'd emit just virsh snapshot-edit, which is still a useful hint and I don't believe we need to do anything beyond that. Well, we might check if the names contain dashes, and then just print the line without the names. But that's probably not worth even trying. Putting the static hint should be good enough. I'd just put there tokens that the user should replace for real values: virsh snapshot-edit 'domain-name' 'snapshot-name' or something like that. I agree; I'm pretty confident that people will understand what's meant by that and the additional complexity of adding the actual object name seems excessive. Dave A 109+/32- patch doesn't look worth of the usability improvement that is marginal. Peter -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Patch replaces scriptlets with new systemd macros
On 10/29/2012 05:56 AM, Daniel P. Berrange wrote:
On Fri, Oct 26, 2012 at 08:09:54AM +0200, Václav Pavlín wrote:
Eric Blake píše v Čt 25. 10. 2012 v 10:41 -0600:
Hello,
Ah, then maybe you did answer the big question. Except that I don't see
the updated patch - did you forget to attach it?
Sure, I did forgot, sorry. Here it is...
diff --git a/daemon/libvirtd.service.in b/daemon/libvirtd.service.in
index b7afadf..b78c301 100644
--- a/daemon/libvirtd.service.in
+++ b/daemon/libvirtd.service.in
@@ -7,6 +7,7 @@
Description=Virtualization daemon
Before=libvirt-guests.service
After=network.target
+Requires=cgconfig.service
I explicitly left that out when i created the libvirtd.service file.
Since systemd itself is capable of setting up cgroups by default, the
common need for cgconfig.service has gone away. A minority of people
may still wish to use it, but they can customize the libvirtd.service
file themselves if desired - we shouldn't force cgconfig.service onto
everyone esle.
Then why are we explicitly starting cgconfig.service in the spec file?
Shouldn't the argument go that only those people customizing the service
file to use cgconfig need cgconfig enabled in the first place? In other
words, is there anything wrong with this one-liner?
diff --git i/libvirt.spec.in w/libvirt.spec.in
index ebebfab..9d11328 100644
--- i/libvirt.spec.in
+++ w/libvirt.spec.in
@@ -1465,13 +1465,12 @@ done
%endif
%if %{with_systemd}
if [ $1 -eq 1 ] ; then
# Initial installation
/bin/systemctl enable libvirtd.service /dev/null 21 || :
-/bin/systemctl enable cgconfig.service /dev/null 21 || :
fi
%else
%if %{with_cgconfig}
# Starting with Fedora 16/RHEL-7, systemd automounts all cgroups,
# and cgconfig is no longer a necessary service.
%if (0%{?rhel} 0%{?rhel} 7) || (0%{?fedora} 0%{?fedora} 16)
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] build: place attributes in correct location
Ever since commit eefb881, ATTRIBUTE_NONNULL has been a no-op under
gcc (since it tends to cause more bugs than it cures given gcc's
current lame implementation of the macro). However, the macro is
still useful to Coverity and other static-analysis tools, but only
if we use it correctly. Gcc (and thus Coverity) accepts function
declarations with attributes at the end, but function bodies must
attach attributes to the return type. That is, these are valid:
void foo(void *arg) ATTRIBUTE_NONNULL(1);
void ATTRIBUTE_NONNULL(1) foo(void *arg);
void ATTRIBUTE_NONNULL(1) foo(void *arg) {}
but this is not:
void foo(void *arg) ATTRIBUTE_NONNULL(1) {}
Bug introduced in commit 80533ca, with these symptoms:
nodeinfo.c:206: error: expected ',' or ';' before '{' token
cc1: warning: unrecognized command line option -Wno-suggest-attribute=const
cc1: warning: unrecognized command line option -Wno-suggest-attribute=pure
make[3]: *** [libvirt_driver_la-nodeinfo.lo] Error 1
* src/nodeinfo.c (virNodeParseNode): Fix syntax error when
non-null attribute is in use.
---
Pushing under the build-breaker rule.
src/nodeinfo.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/nodeinfo.c b/src/nodeinfo.c
index d8b71dd..35c5f96 100644
--- a/src/nodeinfo.c
+++ b/src/nodeinfo.c
@@ -202,9 +202,9 @@ CPU_COUNT(cpu_set_t *set)
/* parses a node entry, returning number of processors in the node and
* filling arguments */
static int
+ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2)
+ATTRIBUTE_NONNULL(3) ATTRIBUTE_NONNULL(4)
virNodeParseNode(const char *node, int *sockets, int *cores, int *threads)
-ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2)
-ATTRIBUTE_NONNULL(3) ATTRIBUTE_NONNULL(4)
{
int ret = -1;
int processors = 0;
--
1.7.11.7
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] util: do a better job of matching up pids with their binaries
This patch resolves: https://bugzilla.redhat.com/show_bug.cgi?id=871201
If libvirt is restarted after updating the dnsmasq or radvd packages,
a subsequent virsh net-destroy will fail to kill the dnsmasq/radvd
process.
The problem is that when libvirtd restarts, it re-reads the dnsmasq
and radvd pidfiles, then does a sanity check on each pid it finds,
including checking that the symbolic link in /proc/$pid/exe actually
points to the same file as the path used by libvirt to execute the
binary in the first place. If this fails, libvirt assumes that the
process is no longer alive.
But if the original binary has been replaced, the link in /proc is set
to $binarypath (deleted) (it literally has the string (deleted)
appended to the link text stored in the filesystem), so even if a new
binary exists in the same location, attempts to resolve the link will
fail.
In the end, not only is the old dnsmasq/radvd not terminated when the
network is stopped, but a new dnsmasq can't be started when the
network is later restarted (because the original process is still
listening on the ports that the new process wants).
The solution is, when the initial use stat to check for identical
inodes check for identity between /proc/$pid/exe and $binpath fails,
to check /proc/$pid/exe for a link ending with (deleted) and if so,
truncate that part of the link and compare what's left with the
original binarypath.
A twist to this problem is that on systems with merged /sbin and
/usr/sbin (i.e. /sbin is really just a symlink to /usr/sbin; Fedora
17+ is an example of this), libvirt may have started the process using
one path, but /proc/$pid/exe lists a different path (indeed, on F17
this is the case - libvirtd uses /sbin/dnsmasq, but /proc/$pid/exe
shows /usr/sbin/dnsmasq). The further bit of code to resolve this is
to call virFileResolveAllLinks() on both the original binarypath and
on the truncated link we read from /proc/$pid/exe, and compare the
results.
The resulting code still succeeds in all the same cases it did before,
but also succeeds if the binary was deleted or replaced after it was
started.
---
src/util/virpidfile.c | 92 ---
1 file changed, 73 insertions(+), 19 deletions(-)
diff --git a/src/util/virpidfile.c b/src/util/virpidfile.c
index c2a087d..cb8a992 100644
--- a/src/util/virpidfile.c
+++ b/src/util/virpidfile.c
@@ -35,6 +35,7 @@
#include logging.h
#include virterror_internal.h
#include c-ctype.h
+#include areadlink.h
#define VIR_FROM_THIS VIR_FROM_NONE
@@ -203,38 +204,91 @@ int virPidFileRead(const char *dir,
*/
int virPidFileReadPathIfAlive(const char *path,
pid_t *pid,
- const char *binpath)
+ const char *binPath)
{
-int rc;
-char *procpath = NULL;
+int ret, retPid;
+bool isLink;
+char *procPath = NULL;
+char *procLink = NULL;
+size_t procLinkLen;
+char *resolvedBinPath = NULL;
+char *resolvedProcLink = NULL;
+const char deletedText[] = (deleted);
+size_t deletedTextLen = strlen(deletedText);
+
-rc = virPidFileReadPath(path, pid);
-if (rc 0)
-return rc;
+/* only set this at the very end on success */
+*pid = -1;
+
+if ((ret = virPidFileReadPath(path, retPid)) 0)
+goto cleanup;
#ifndef WIN32
/* Check that it's still alive. Safe to skip this sanity check on
* mingw, which lacks kill(). */
-if (kill(*pid, 0) 0) {
-*pid = -1;
-return 0;
+if (kill(retPid, 0) 0) {
+ret = 0;
+retPid = -1;
+goto cleanup;
}
#endif
-if (binpath) {
-if (virAsprintf(procpath, /proc/%lld/exe, (long long)*pid) 0) {
-*pid = -1;
-return -1;
-}
+if (!binPath) {
+/* we only knew the pid, and that pid is alive, so we can
+ * return it.
+ */
+ret = 0;
+goto cleanup;
+}
+
+if (virAsprintf(procPath, /proc/%lld/exe, (long long)retPid) 0) {
+ret = -ENOMEM;
+goto cleanup;
+}
-if (virFileIsLink(procpath)
-virFileLinkPointsTo(procpath, binpath) == 0)
-*pid = -1;
+if ((ret = virFileIsLink(procPath)) 0)
+goto cleanup;
+isLink = ret;
-VIR_FREE(procpath);
+if (isLink virFileLinkPointsTo(procPath, binPath)) {
+/* the link in /proc/$pid/exe is a symlink to a file
+ * that has the same inode as the file at binpath.
+ */
+ret = 0;
+goto cleanup;
}
-return 0;
+/* Even if virFileLinkPointsTo returns a mismatch, it could be
+ * that the binary was deleted/replaced after it was executed. In
+ * that case the link in /proc/$pid/exe will contain
+ * $procpath (deleted). Read that link, remove the (deleted)
+ * part, and see if it has the same canonicalized name as binpath.
+ */
+if (!(procLink =
[libvirt] [jbro...@redhat.com: [Users] oVirt at LinuxCon Europe Next Week]
FYI, there's a bunch of oVirt related stuff going on at LinuxCon next week. - Forwarded message from Jason Brooks jbro...@redhat.com - Date: Mon, 29 Oct 2012 14:11:29 -0700 From: Jason Brooks jbro...@redhat.com To: oVirt Mailing List us...@ovirt.org, annou...@ovirt.org Subject: [Users] oVirt at LinuxCon Europe Next Week User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1 LinuxCon Europe 2012 is taking place next week in Barcelona, Spain, alongside a cluster of related workshops and summits, several of which will focus on the oVirt Project. If you are planning on attending LinuxCon Europe next week, it should provide a great opportunity to connect with other oVirt community members in attendance. If you know others outside the community who plan to be at LinuxCon Europe, and who may be interested in learning more about oVirt, please pass along this information. On Monday November 5, from 10:30am to 7:00pm, and continuing on Tuesday from 10:30am to 4:30pm, there will be a Technology Showcase with booths from LinuxCon Europe exhibitors. The oVirt Project will be in booth #22, on the ground floor of the Hotel Fira Palace. On Tuesday November 6, the oVirt Project's own Itamar Heim, from Red Hat, will giving the talk, Introduction to the oVirt Virtualization Management Platform, from 2:15 pm to 3:10pm, at the Hotel Fira Palace, in the Verdi room, as part of the CloudOpen Summit. On Wednesday November 7, the oVirt Workshop will kick off at 9am in the L'ARIA Restaurant, before covering an introduction to oVirt, architecture and roadmap presentations, and deep dives into oVirt networking and storage, leading up to a Hands-On Install Play Lab from 3:30pm to 6:00pm. Also on Wednesday, at the KVM Forum, there will be an oVirt Demo from 5:30pm to 6:00pm in the Ambar room. On Thursday November 8, the oVirt Workshop resumes at 9:00am in the Rubi room, with a full day of sessions devoted to oVirt integration topics. Also on Thursday, at 11:15am, Red Hat's Vijay Bellur will be giving a talk on Integrating GlusterFS, oVirt and KVM as part of the Gluster Workshop, in the Vivaldi room. On Friday November 9, the oVirt Workshop will begin its final day with a brief keynote in the Ambar room, before proceeding with a day of developer-focused topics back in the Rubi room. For details on the oVirt Workshop agenda, see the schedule at http://events.linuxfoundation.org/events/kvm-forum/schedule. For information about LinuxCon Europe 2012, see event site at http://events.linuxfoundation.org/events/linuxcon-europe. ___ Users mailing list us...@ovirt.org http://lists.ovirt.org/mailman/listinfo/users - End forwarded message - -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Fwd: Need help of guest lifecycle control
Any update? Really need your help about this... zhpeng BR - Forwarded Message - From: Zhimou Peng zhp...@redhat.com To: libvir-list@redhat.com Cc: jdene...@redhat.com, Min Zhan mz...@redhat.com, YuanDan dy...@redhat.com Sent: Monday, September 24, 2012 1:45:28 PM Subject: Need help of guest lifecycle control Hi, I have a question about guest lifecycle control, many content of element not works, i don't know if i use it in a wrong way. #virsh shutdown aaa on_poweroffdestroy/on_poweroff Domain aaa shut off and not power up again. - expect on_poweroffrestart/on_poweroff should power up again but not. - not expect on_poweroffpreserve/on_poweroff guest poweroff, nothing happend. how to use it ? on_poweroffrename-restart/on_poweroff guest poweroff, and should boot up again with newname? but it's only powered off. ---not expect - #virsh reboot aaa on_rebootdestroy/on_reboot guest not boot up again. it works. on_rebootrestart/on_reboot guest boot up again. it works. on_rebootpreserve/on_reboot guest poweroff, nothing happend.- how to use it ? on_rebootrename-restart/on_reboot guest poweroff, and should boot up again with newname. but it's only powered off. ---not expect -- on_crashxxx/on_crash ---qemu not support this yet, right? https://bugzilla.redhat.com/show_bug.cgi?id=833530 zhpeng BR -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v2] helper of copy-storage-* features
help to create disk images copy-storage-* required,
try to do non-shared migration without bothering to
create disk images at target by hand.
consider this situation:
1. non-shared migration
virsh migrate --copy-storage-all ...
2. migration fails
3. create disk images required
qemu-img create ...
4 migration run smoothly
so, try do remove step 2, 3, 4
this kind of usage had been discussed before,
http://www.redhat.com/archives/libvir-list/2011-December/msg00451.html
maybe there're some flaws:
- It did not handle more about complete situations
suggested by Daniel P. Berrange,
https://www.redhat.com/archives/libvir-list/2012-October/msg00407.html
but may try to take care of them later.
so, now only normal disk image files be handled.
- for creation of disk images, size was setting as 0x boldly,
hope it can consolidate qemu, haven't constructed a comfortable
idea to solve it.
v2:
1. handle disk encrytion case
2. check kvm-img qemu-img
3. set disk image size to 0xfffK bytes blindly
Signed-off-by: liguang lig.f...@cn.fujitsu.com
---
src/qemu/qemu_migration.c | 112 -
1 files changed, 110 insertions(+), 2 deletions(-)
diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
index db69a0a..55eb98e 100644
--- a/src/qemu/qemu_migration.c
+++ b/src/qemu/qemu_migration.c
@@ -49,6 +49,7 @@
#include storage_file.h
#include viruri.h
#include hooks.h
+#include dirname.h
#define VIR_FROM_THIS VIR_FROM_QEMU
@@ -70,6 +71,7 @@ enum qemuMigrationCookieFlags {
QEMU_MIGRATION_COOKIE_FLAG_GRAPHICS,
QEMU_MIGRATION_COOKIE_FLAG_LOCKSTATE,
QEMU_MIGRATION_COOKIE_FLAG_PERSISTENT,
+QEMU_MIGRATION_COOKIE_FLAG_COPYSTORAGE,
QEMU_MIGRATION_COOKIE_FLAG_LAST
};
@@ -77,12 +79,13 @@ enum qemuMigrationCookieFlags {
VIR_ENUM_DECL(qemuMigrationCookieFlag);
VIR_ENUM_IMPL(qemuMigrationCookieFlag,
QEMU_MIGRATION_COOKIE_FLAG_LAST,
- graphics, lockstate, persistent);
+ graphics, lockstate, persistent, copystorage);
enum qemuMigrationCookieFeatures {
QEMU_MIGRATION_COOKIE_GRAPHICS = (1
QEMU_MIGRATION_COOKIE_FLAG_GRAPHICS),
QEMU_MIGRATION_COOKIE_LOCKSTATE = (1
QEMU_MIGRATION_COOKIE_FLAG_LOCKSTATE),
QEMU_MIGRATION_COOKIE_PERSISTENT = (1
QEMU_MIGRATION_COOKIE_FLAG_PERSISTENT),
+QEMU_MIGRATION_COOKIE_COPYSTORAGE = (1
QEMU_MIGRATION_COOKIE_FLAG_COPYSTORAGE),
};
typedef struct _qemuMigrationCookieGraphics qemuMigrationCookieGraphics;
@@ -439,6 +442,9 @@ qemuMigrationCookieXMLFormat(struct qemud_driver *driver,
virBufferAdjustIndent(buf, -2);
}
+if (mig-flags QEMU_MIGRATION_COOKIE_COPYSTORAGE)
+virBufferAsprintf(buf, copystorage/\n);
+
virBufferAddLit(buf, /qemu-migration\n);
return 0;
}
@@ -662,6 +668,11 @@ qemuMigrationCookieXMLParse(qemuMigrationCookiePtr mig,
VIR_FREE(nodes);
}
+if ((flags QEMU_MIGRATION_COOKIE_COPYSTORAGE)) {
+if (virXPathBoolean(count(./copystorage) 0, ctxt))
+mig-flags |= QEMU_MIGRATION_COOKIE_COPYSTORAGE;
+}
+
return 0;
error:
@@ -721,6 +732,9 @@ qemuMigrationBakeCookie(qemuMigrationCookiePtr mig,
qemuMigrationCookieAddPersistent(mig, dom) 0)
return -1;
+if (flags QEMU_MIGRATION_COOKIE_COPYSTORAGE)
+mig-flags |= QEMU_MIGRATION_COOKIE_COPYSTORAGE;
+
if (!(*cookieout = qemuMigrationCookieXMLFormatStr(driver, mig)))
return -1;
@@ -1168,6 +1182,14 @@ char *qemuMigrationBegin(struct qemud_driver *driver,
QEMU_MIGRATION_COOKIE_LOCKSTATE) 0)
goto cleanup;
+if (flags (VIR_MIGRATE_NON_SHARED_DISK |
+ VIR_MIGRATE_NON_SHARED_INC)) {
+if (qemuMigrationBakeCookie(mig, driver, vm,
+cookieout, cookieoutlen,
+QEMU_MIGRATION_COOKIE_COPYSTORAGE) 0)
+goto cleanup;
+}
+
if (xmlin) {
if (!(def = virDomainDefParseString(driver-caps, xmlin,
QEMU_EXPECTED_VIRT_TYPES,
@@ -1215,6 +1237,79 @@ qemuMigrationPrepareCleanup(struct qemud_driver *driver,
qemuDomainObjDiscardAsyncJob(driver, vm);
}
+/*
+ if gen_del is 1, find out disk images migration required,
+ so try to generate them at target,
+ if gen_del is 0, delete disk images generated before.
+*/
+static int qemuMigrationHandleDiskFiles(virDomainDefPtr def, int gen_del)
+{
+char *tmp_dir = NULL, *outbuf = NULL;
+char *size = _(0xK), *img_tool;
+virCommandPtr cmd = NULL;
+int i, ret = -1;
+
+if (!def-ndisks)
+return 0;
+
+img_tool = virFindFileInPath(kvm-img);
+if (!img_tool)
+img_tool = virFindFileInPath(qemu-img);
+if (!img_tool) {
+virReportError(VIR_ERR_INTERNAL_ERROR,
+ %s, _(unable to find kvm-img or qemu-img));
+return
