[libvirt] Unable to setup qemu-guest-agent
Could anyone please list out the steps required to run the command
$virsh qemu-agent-command
Steps that I followed:
1. Clone the latest source code of libvirt
2. Create a vm of f18 (source:liveCD)
3. Edit f18 domain xml and add this:
channel type='unix'
source mode='bind' path='/var/lib/libvirt/qemu/f16x86_64.agent'/
target type='virtio' name='org.qemu.guest_agent.0'/
/channel
4. On host: #./tools/virsh start f18
5. On guest: #yum install qemu-guest-agent -y
6. On host: # ./tools/virsh qemu-agent-command f18
'{execute:guest-network-get-interfaces}'
Expected Response:
{return:[{name:lo,ip-
addresses:[{ip-address-type:ipv4,ip-address:127.0.0.1,prefix:8},{ip-address-type:ipv6,ip-address:::1,prefix:128}],hardware-address:00:00:00:00:00:00},{name:eth0,ip-addresses:[{ip-address-type:ipv4,ip-address:192.168.122.62,prefix:24},{ip-address-type:ipv6,ip-address:fe80::5054:ff:fe14:9998,prefix:64}],hardware-address:52:54:00:14:99:98}]}
Actual result:
error: unknown procedure: 3
Where am I going wrong?
--
Nehal J. Wani
UG2, BTech CS+MS(CL)
IIIT-Hyderabad
http://commanlinewani.blogspot.com
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Document security reporting handling process
On Tue, Jun 4, 2013 at 9:29 AM, Roman Bogorodskiy bogorods...@gmail.comwrote: Daniel P. Berrange wrote: On Tue, Jun 04, 2013 at 09:33:15AM -0600, Eric Blake wrote: On 06/04/2013 04:06 AM, Daniel P. Berrange wrote: From: Daniel P. Berrange berra...@redhat.com Historically security issues in libvirt have been primarily triaged fixed by the Red Hat libvirt members Red Hat security team, who then usually notify other vendors via appropriate channels. There have been a number of times when vendors have not been properly notified ahead of announcement. It has also disadvantaged community members who have to backport fixes to releases for which there are no current libvirt stable branches. To address this, we want to make the libvirt security process entirely community focused / driven. To this end I have setup a new email address libvirt-secur...@redhat.com for end users to report bugs which have (possible) security implications. This email addr is backed by an invitation only, private archive, mailing list. The intent is for the list membership to comprise a subset of the libvirt core team, along with any vendor security team engineers who wish to participate in a responsible disclosure process for libvirt. Members of the list will be responsible for analysing the problem to determine if a security issue exists and then issue fixes for all current official stable branches git master. I am proposing the following libvirt core team people as members of the security team / list (all cc'd): Daniel Berrange (Red Hat) Eric Blake (Red Hat) Jiri Denemar (Red Hat) Daniel Veillard (Red Hat) Jim Fehlig (SUSE) Doug Goldstein (Gentoo) Guido Günther (Debian) We don't have anyone from Ubuntu on the libvirt core team. Serge Hallyn is the most frequent submitter of patches from Ubuntu in recent history, so I'd like to invite him to join. Alternatively, Serge, feel free to suggest someone else to represent Ubuntu's interests. Is it worth adding any BSD representation? Roman Bogorodskiy might be the best candidate on that front. Yep, meant to mention that. I was not sure whether any *BSD is actually distributing formal libvirt packages to users yet, or if they're still just at the code porting stage. Roman, what's the status of the FreeBSD port / packaging effort from your POV ? FreeBSD has libvirt port: http://www.freshports.org/devel/libvirt/ It is maintained by Jason Helfman (CCed), so I think he's more appropriate person for such kind of things. From my side, I'd be happy to help also. Roman Bogorodskiy Packages are supplied to users as part of our standard package distribution sets for releases and standard updates of our package sets. It has been distributed as a package since it was committed to the FreeBSD ports tree. -jgh -- Jason Helfman | FreeBSD Committer j...@freebsd.org | http://people.freebsd.org/~jgh | The Power to Serve -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvirtd 1.0.6 refuses to start
On 12/06/13 15:49, Michal Privoznik wrote: On 11.06.2013 16:59, Franky Van Liedekerke wrote: I just downloaded and compiled libvirtd on the same server as I did 1.0.4. Upon updating, libvirtd refuses to start, with this in the logfile (obfuscated the hostname by xxx's): 2013-06-11 13:43:49.154+: 3336: info : libvirt version: 1.0.6, package: 1.el6 (Unknown, 2013-06-06-14:57:07, ) 2013-06-11 13:43:49.154+: 3336: error : virFileReadAll:1195 : Failed to open file '/sys/class/fc_host//host0/max_npiv_vports': No such file or directory 2013-06-11 13:43:49.159+: 3336: error : detect_scsi_host_caps:87 : Failed to read max_npiv_vports for host1 2013-06-11 13:43:49.163+: 3336: error : virFileReadAll:1195 : Failed to open file '/sys/class/fc_host//host0/max_npiv_vports': No such file or directory 2013-06-11 13:43:49.163+: 3336: error : detect_scsi_host_caps:87 : Failed to read max_npiv_vports for host2 2013-06-11 13:43:49.386+: 3336: error : virLockManagerPluginNew:175 : Failed to load plugin /usr/lib64/libvirt/lock-driver/lockd.so: /usr/lib64/libvirt/lock-driver/lockd.so: undefined symbol: virProcessGetStartTime This symbol has been introduced in 1.0.6. So I guess you are running a new binary with old libraries which causes your problem. 2013-06-11 13:43:49.386+: 3336: error : virStateInitialize:831 : Initialization of QEMU state driver failed 2013-06-11 13:43:49.386+: 3336: error : daemonRunStateInit:887 : Driver state initialization failed So it seems two issues are present here: 1) it searches for /sys/class/fc_host//host0/max_npiv_vports for both host1 and host2. Imho this path needs to be /sys/class/fc_host//host1/max_npiv_vports and /sys/class/fc_host//host2/max_npiv_vports respectively. I guess you're right. Osier? Yes, it's expected so. It reports the correct host number. 2013-06-11 13:43:49.159+: 3336: error : detect_scsi_host_caps:87 : Failed to read max_npiv_vports for host1 But produces incorrect file path with the same host number. However, I have no idea why it happened from code. And we have test for the util helpers. If it has problems, the test should fail too. Osier -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Unable to setup qemu-guest-agent
On 17/06/13 14:00, Nehal J. Wani wrote:
Could anyone please list out the steps required to run the command
$virsh qemu-agent-command
Steps that I followed:
1. Clone the latest source code of libvirt
2. Create a vm of f18 (source:liveCD)
3. Edit f18 domain xml and add this:
channel type='unix'
source mode='bind' path='/var/lib/libvirt/qemu/f16x86_64.agent'/
target type='virtio' name='org.qemu.guest_agent.0'/
/channel
4. On host: #./tools/virsh start f18
5. On guest: #yum install qemu-guest-agent -y
6. On host: # ./tools/virsh qemu-agent-command f18
'{execute:guest-network-get-interfaces}'
Expected Response:
{return:[{name:lo,ip-
addresses:[{ip-address-type:ipv4,ip-address:127.0.0.1,prefix:8},{ip-address-type:ipv6,ip-address:::1,prefix:128}],hardware-address:00:00:00:00:00:00},{name:eth0,ip-addresses:[{ip-address-type:ipv4,ip-address:192.168.122.62,prefix:24},{ip-address-type:ipv6,ip-address:fe80::5054:ff:fe14:9998,prefix:64}],hardware-address:52:54:00:14:99:98}]}
Actual result:
error: unknown procedure: 3
What's your running libvirtd's version? It sounds like it's old enough
without
the API used by qemu-guest-agent.
Osier
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvirtd 1.0.6 refuses to start
On 06/17/2013 09:05 AM, Osier Yang wrote: On 12/06/13 15:49, Michal Privoznik wrote: On 11.06.2013 16:59, Franky Van Liedekerke wrote: So it seems two issues are present here: 1) it searches for /sys/class/fc_host//host0/max_npiv_vports for both host1 and host2. Imho this path needs to be /sys/class/fc_host//host1/max_npiv_vports and /sys/class/fc_host//host2/max_npiv_vports respectively. I guess you're right. Osier? Yes, it's expected so. It reports the correct host number. 2013-06-11 13:43:49.159+: 3336: error : detect_scsi_host_caps:87 : Failed to read max_npiv_vports for host1 But produces incorrect file path with the same host number. However, I have no idea why it happened from code. And we have test for the util helpers. If it has problems, the test should fail too. Osier Sorry, I forgot to comment on this thread. It's fixed already by: http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=371c155 Jan Bug: https://bugzilla.redhat.com/show_bug.cgi?id=973543 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Unable to setup qemu-guest-agent
The error:
# ./tools/virsh qemu-agent-command f18
'{execute:guest-network-get-interfaces}'
error: unknown procedure: 3
Comes when I clone from $git clone git://libvirt.org/libvirt.git
But when I download http://libvirt.org/sources/libvirt-1.0.6.tar.gz
and make, I get:
# ./tools/virsh qemu-agent-command f18
'{execute:guest-network-get-interfaces}'
(null)
On 6/17/13, Osier Yang jy...@redhat.com wrote:
On 17/06/13 14:00, Nehal J. Wani wrote:
Could anyone please list out the steps required to run the command
$virsh qemu-agent-command
Steps that I followed:
1. Clone the latest source code of libvirt
2. Create a vm of f18 (source:liveCD)
3. Edit f18 domain xml and add this:
channel type='unix'
source mode='bind' path='/var/lib/libvirt/qemu/f16x86_64.agent'/
target type='virtio' name='org.qemu.guest_agent.0'/
/channel
4. On host: #./tools/virsh start f18
5. On guest: #yum install qemu-guest-agent -y
6. On host: # ./tools/virsh qemu-agent-command f18
'{execute:guest-network-get-interfaces}'
Expected Response:
{return:[{name:lo,ip-
addresses:[{ip-address-type:ipv4,ip-address:127.0.0.1,prefix:8},{ip-address-type:ipv6,ip-address:::1,prefix:128}],hardware-address:00:00:00:00:00:00},{name:eth0,ip-addresses:[{ip-address-type:ipv4,ip-address:192.168.122.62,prefix:24},{ip-address-type:ipv6,ip-address:fe80::5054:ff:fe14:9998,prefix:64}],hardware-address:52:54:00:14:99:98}]}
Actual result:
error: unknown procedure: 3
What's your running libvirtd's version? It sounds like it's old enough
without
the API used by qemu-guest-agent.
Osier
--
Nehal J. Wani
UG2, BTech CS+MS(CL)
IIIT-Hyderabad
http://commanlinewani.blogspot.com
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvirtd 1.0.6 refuses to start
On 17/06/13 15:23, Ján Tomko wrote: On 06/17/2013 09:05 AM, Osier Yang wrote: On 12/06/13 15:49, Michal Privoznik wrote: On 11.06.2013 16:59, Franky Van Liedekerke wrote: So it seems two issues are present here: 1) it searches for /sys/class/fc_host//host0/max_npiv_vports for both host1 and host2. Imho this path needs to be /sys/class/fc_host//host1/max_npiv_vports and /sys/class/fc_host//host2/max_npiv_vports respectively. I guess you're right. Osier? Yes, it's expected so. It reports the correct host number. 2013-06-11 13:43:49.159+: 3336: error : detect_scsi_host_caps:87 : Failed to read max_npiv_vports for host1 But produces incorrect file path with the same host number. However, I have no idea why it happened from code. And we have test for the util helpers. If it has problems, the test should fail too. Osier Sorry, I forgot to comment on this thread. It's fixed already by: http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=371c155 Thanks for fixing it. Osier -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/7] storage: rework qemu-img command line generation
On 06/10/2013 04:12 PM, Martin Kletzander wrote:
On 06/10/2013 02:10 PM, Ján Tomko wrote:
Split out option string generation to make adding new options easier
and simplify the code.
---
src/storage/storage_backend.c | 111
++
1 file changed, 59 insertions(+), 52 deletions(-)
+if (imgformat == QEMU_IMG_BACKING_FORMAT_OPTIONS) {
+if (virStorageBackendCreateQemuImgOpts(opts,
+ backing ? backingType : NULL,
+ do_encryption, preallocate))
I guess we should use ' 0' here to unify the looks of it.
Other than that it's way more readable than the previous version, so ACK
with that fixed.
Martin
Thanks, I've squashed this in to prevent Coverity from complaining about
unused virBufferTrim's return value:
diff --git a/src/storage/storage_backend.c b/src/storage/storage_backend.c
index e7930ee..aa47871 100644
--- a/src/storage/storage_backend.c
+++ b/src/storage/storage_backend.c
@@ -643,9 +643,7 @@ virStorageBackendCreateQemuImgOpts(char **opts,
if (preallocate)
virBufferAddLit(buf, preallocation=metadata,);
-virBufferTrim(buf, ,, -1);
-
-if (virBufferError(buf)) {
+if (virBufferTrim(buf, ,, -1) 0) {
virBufferFreeAndReset(buf);
virReportOOMError();
return -1;
@@ -816,7 +814,7 @@ virStorageBackendCreateQemuImgCmd(virConnectPtr conn,
if (imgformat == QEMU_IMG_BACKING_FORMAT_OPTIONS) {
if (virStorageBackendCreateQemuImgOpts(opts,
backing ? backingType : NULL,
- do_encryption, preallocate))
+ do_encryption, preallocate) 0)
return NULL;
if (opts)
virCommandAddArgList(cmd, -o, opts, NULL);
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH V2] Expose all CPU features in host definition
On Fri, Jun 14, 2013 at 12:32:35 -0600, Don Dugger wrote: On Fri, Jun 14, 2013 at 03:06:52PM +0200, Jiri Denemark wrote: I was just trying to say that it doesn't provide anything more than it's supported by the host CPU, which gives mostly no value in the context of libvirt. Can you explain more what the use case is in which a virt client would need to know what specific feature are supported by host CPU? I feel like we should avoid people from being under the impression that they can actually use the CPU capabilities for checking whether a host can run guests that require specific CPU features. The specific use case I'm trying to address is a cloud environment where, with hundreds of hosts, you might want to schedule an instance to a host that supports a particular HW acceleration, like AES/NI. I agree, what I `really` want is an API that shows the capabilities of a specific guest that could be created on the host but, absent that API, at least knowing that a host doesn't support the feature is more information than I can get right now. Hmm, fair enough. Let's wait a few days for Daniel to return from vacation in case he wants to express his opinion here. Moreover, there's one thing that makes this issue even more complicated. As the CPU model is the most useful part of host CPU capabilities (it should be the best CPU model supported by the host), I wanted to extend the probing code to select the right model even if it's missing some features that we expect to be supported by that model. In other words, if host CPU is, e.g., SandyBridge but has some basic feature disabled, we would detect it as the best model which did not have the disabled feature, which is not optimal. We'd ideally detect the CPU as SandyBridge with just the feature disabled. That is, another reason for having feature list relative to the CPU model. On the other hand, it might be hard or even impossible to do without breaking compatibility and perhaps even doubtful without involving emulator, which would make it impossible to do within capabilities XML. If I understand you, you're proposing that you report the host as being a SandyBridge when it doesn't support all SandyBridge features? I don't like that idea as it seems really confusing. Taken to the extreme, this would mean you could take a Nehalem host and report it as a SanyBridge that lacks some features. I don't see the point of that. Yes and no :-) I'd like to report the CPU as a SandyBridge if it really is a SandyBridge but lacks a feature that we require to be present for us to detect the CPU as a SandyBridge. There are (or at least were) features that can actually be disabled on the host, e.g., by BIOS and I remember that doing so may result in that particular feature to be disabled in CPUID. For example, if NX (not sure if that's the right example that is actually masked from CPUID) is disabled, than the CPU still is a SandyBridge but libvirt would detect it as something generic and old as NX is part of all modern CPU models libvirt supports. However, as I said, this could be hard or even impossible to do in a compatible manner. Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] check return values of virBufferTrim
Just to silence Coverity:
Event check_return:
Calling function virBufferTrim(virBufferPtr, char const *, int)
without checking return value (as is done elsewhere 5 out of 6 times).
---
src/node_device/node_device_udev.c | 5 ++---
src/rpc/virnetsshsession.c | 3 +--
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/src/node_device/node_device_udev.c
b/src/node_device/node_device_udev.c
index bb58415..a37989a 100644
--- a/src/node_device/node_device_udev.c
+++ b/src/node_device/node_device_udev.c
@@ -370,9 +370,8 @@ udevLogFunction(struct udev *udev ATTRIBUTE_UNUSED,
const char *format = NULL;
virBufferAdd(buf, fmt, -1);
-virBufferTrim(buf, \n, -1);
-
-format = virBufferContentAndReset(buf);
+if (virBufferTrim(buf, \n, -1) = 0)
+format = virBufferContentAndReset(buf);
virLogVMessage(VIR_LOG_FROM_LIBRARY,
virLogPriorityFromSyslog(priority),
diff --git a/src/rpc/virnetsshsession.c b/src/rpc/virnetsshsession.c
index b6aedc8..2299871 100644
--- a/src/rpc/virnetsshsession.c
+++ b/src/rpc/virnetsshsession.c
@@ -362,9 +362,8 @@ virNetSSHCheckHostKey(virNetSSHSessionPtr sess)
* we have to use a *MAGIC* constant. */
for (i = 0; i 16; i++)
virBufferAsprintf(buff, %02hhX:, keyhash[i]);
-virBufferTrim(buff, :, 1);
-if (virBufferError(buff) != 0) {
+if (virBufferTrim(buff, :, 1) 0) {
virReportOOMError();
return -1;
}
--
1.8.1.5
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] libvirt compliation from git source fails with gnulib/tests/Makefile.in' not found error
Hi, I am compiling the libvirt from source and I am getting the following error: Don't forget to - include gnulib.mk from within gnulib/lib/Makefile.am, - include gnulib.mk from within gnulib/tests/Makefile.am, - mention -I gnulib/m4 in ACLOCAL_AMFLAGS in Makefile.am, - mention gnulib/m4/gnulib-cache.m4 in EXTRA_DIST in Makefile.am, - invoke gl_EARLY in ./configure.ac, right after AC_PROG_CC, - invoke gl_INIT in ./configure.ac. running: AUTOPOINT=true LIBTOOLIZE=true autoreconf --verbose --install --force -I gnulib/m4 --no-recursive autoreconf: Entering directory `.' autoreconf: running: true --force autoreconf: running: aclocal -I m4 --force -I m4 -I gnulib/m4 autoreconf: configure.ac: tracing autoreconf: running: true --copy --force autoreconf: running: /usr/bin/autoconf --include=gnulib/m4 --force autoreconf: running: /usr/bin/autoheader --include=gnulib/m4 --force autoreconf: running: automake --add-missing --copy --force-missing configure.ac:2424: required file `gnulib/lib/Makefile.in' not found configure.ac:2424: required file `gnulib/tests/Makefile.in' not found autoreconf: automake failed with exit status: 1 Libvirtd (libvirt) 1.0.5 we didn't any isssues. Please let us know if we are missing something. Thanks, Chandrashekar -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC] conf: Order of AddImplicitControllers and DomainDefPostParse
On 06/14/2013 02:34 PM, Viktor Mihajlovski wrote: Implicit controllers may be dependent on device definitions altered in a post-parse callback. E.g., if a console device is defined without the target type, the type will be set in QEMU's callback. In the case of s390, this is virtio, which requires an implicit virtio-serial controller. By moving the implicit controller definition after the post-parse procssing this can be fixed. OTOH the implicit controllers might need post-parse actions as well, although I am currentyl not aware of one. What would speak against swapping the order as suggested in the patch below? Feedback welcome. I can't say I'd be against that. I hope there's no implicit controller that needs post-parse function, because when there is, all the actions can be taken care of in the function. And if same things need to be checked for, deduplication of such code takes care of it. In case such code movements will show that these two functions would be better off merged together, than it can be acted upon (I'm going to extremes with this unnecessary explanation). However, it would be nice if you could also add a test case to show and check for the behavior you're trying to achieve. Other than that I'd be ok with such movement, but also happy if someone else provided his/her opinion as well. Have a nice day, Martin -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Unable to setup qemu-guest-agent
On 17.06.2013 09:21, Nehal J. Wani wrote:
The error:
# ./tools/virsh qemu-agent-command f18
'{execute:guest-network-get-interfaces}'
error: unknown procedure: 3
Comes when I clone from $git clone git://libvirt.org/libvirt.git
But when I download http://libvirt.org/sources/libvirt-1.0.6.tar.gz
and make, I get:
# ./tools/virsh qemu-agent-command f18
'{execute:guest-network-get-interfaces}'
(null)
Unfortunately, the patch which dispatches errors from qemu-agent-command has
been submitted after the 1.0.6 release:
commit 0eb2f8aa90d26e75ce5d9449da03bb553da85d2d
Author: Peter Krempa pkre...@redhat.com
AuthorDate: Mon Jun 3 16:12:52 2013 +0200
Commit: Peter Krempa pkre...@redhat.com
CommitDate: Mon Jun 3 17:25:33 2013 +0200
libvirt-qemu: Dispatch errors from virDomainQemuAgentCommand()
The original implementation didn't follow the established pattern and
did not dispatch errors in case of failure.
So if you could try out building the libvirt from git and get the real error.
Or if you want to use the 1.0.6 release, you'll find the error message in the
libvirtd log.
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] python: virConnect: fix destructor
Fixed virConnect destructor checking for attribute
existance before trying to use it.
Avoids:
Exception AttributeError: AttributeError(virConnect instance has no
attribute 'domainEventCallbacks',) in bound method virConnect.__del__
of libvirt.virConnect instance at 0x4280f38 ignored
However, something still doesn't work:
Exception TypeError: TypeError('NoneType' object is not callable,)
in bound method virConnect.__del__ of libvirt.virConnect object at
0x37576d0 ignored
Signed-off-by: Sandro Bonazzola sbona...@redhat.com
---
python/libvirt-override-virConnect.py | 32 +---
1 file changed, 17 insertions(+), 15 deletions(-)
diff --git a/python/libvirt-override-virConnect.py
b/python/libvirt-override-virConnect.py
index 5495b70..28d6d41 100644
--- a/python/libvirt-override-virConnect.py
+++ b/python/libvirt-override-virConnect.py
@@ -1,11 +1,12 @@
def __del__(self):
-try:
- for cb,opaque in self.domainEventCallbacks.items():
- del self.domainEventCallbacks[cb]
- del self.domainEventCallbacks
- libvirtmod.virConnectDomainEventDeregister(self._o, self)
-except AttributeError:
- pass
+if hasattr(self, 'domainEventCallbacks'):
+try:
+for cb,opaque in self.domainEventCallbacks.items():
+del self.domainEventCallbacks[cb]
+del self.domainEventCallbacks
+libvirtmod.virConnectDomainEventDeregister(self._o, self)
+except AttributeError:
+pass
if self._o != None:
libvirtmod.virConnectClose(self._o)
@@ -14,14 +15,15 @@
def domainEventDeregister(self, cb):
Removes a Domain Event Callback. De-registering for a
domain callback will disable delivery of this event type
-try:
-del self.domainEventCallbacks[cb]
-if len(self.domainEventCallbacks) == 0:
-del self.domainEventCallbacks
-ret = libvirtmod.virConnectDomainEventDeregister(self._o, self)
-if ret == -1: raise libvirtError
('virConnectDomainEventDeregister() failed', conn=self)
-except AttributeError:
-pass
+if hasattr(self, 'domainEventCallbacks'):
+try:
+del self.domainEventCallbacks[cb]
+if len(self.domainEventCallbacks) == 0:
+del self.domainEventCallbacks
+ret = libvirtmod.virConnectDomainEventDeregister(self._o,
self)
+if ret == -1: raise libvirtError
('virConnectDomainEventDeregister() failed', conn=self)
+except AttributeError:
+pass
def domainEventRegister(self, cb, opaque):
Adds a Domain Event Callback. Registering for a domain
--
1.8.1.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/2] Support setting the 'removable' flag for USB disks
Bump! Also: 31/05/13 16:23, Fred A. Kemp wrote: For reference, my first attempt at a patch for this feature was: 1363682454-32012-1-git-send-email-ano...@lavabit.com On second thought, an archive link might be a better reference for people that doesn't keep old emails in the inbox for very long: https://www.redhat.com/archives/libvir-list/2013-March/msg01051.html Cheers! -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Unable to setup qemu-guest-agent
I was able to solve the error. It was a stupid mistake. There was a
mismatch between versions of virsh and the libvirt daemon.
On Mon, Jun 17, 2013 at 3:56 PM, Michal Privoznik mpriv...@redhat.comwrote:
On 17.06.2013 09:21, Nehal J. Wani wrote:
The error:
# ./tools/virsh qemu-agent-command f18
'{execute:guest-network-get-interfaces}'
error: unknown procedure: 3
Comes when I clone from $git clone git://libvirt.org/libvirt.git
But when I download http://libvirt.org/sources/libvirt-1.0.6.tar.gz
and make, I get:
# ./tools/virsh qemu-agent-command f18
'{execute:guest-network-get-interfaces}'
(null)
Unfortunately, the patch which dispatches errors from qemu-agent-command
has been submitted after the 1.0.6 release:
commit 0eb2f8aa90d26e75ce5d9449da03bb553da85d2d
Author: Peter Krempa pkre...@redhat.com
AuthorDate: Mon Jun 3 16:12:52 2013 +0200
Commit: Peter Krempa pkre...@redhat.com
CommitDate: Mon Jun 3 17:25:33 2013 +0200
libvirt-qemu: Dispatch errors from virDomainQemuAgentCommand()
The original implementation didn't follow the established pattern and
did not dispatch errors in case of failure.
So if you could try out building the libvirt from git and get the real
error.
Or if you want to use the 1.0.6 release, you'll find the error message in
the libvirtd log.
Michal
--
Nehal J. Wani
UG2, BTech CS+MS(CL)
IIIT-Hyderabad
http://commanlinewani.blogspot.com
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Move virGetUserEnt() to where its needed
On 16.06.2013 23:45, Doug Goldstein wrote:
In the first if case, virGetUserEnt() isn't necessary so don't bother
calling it before determining we need it.
---
Found this trying to get libvirtd running happily on my Mac OS X machine
for qemu. Unfortunately it appears virGetUserEnt() is always failing
on Mac OS X (getpwuid_r() returns 0 each time) because we are requesting
info on a different high value UIDs each time (32xxx). That's another
issue entirely but this fix allows me to ignore that and test other
fixes on my Mac.
---
src/util/virutil.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/util/virutil.c b/src/util/virutil.c
index c5246bc..6fa0212e 100644
--- a/src/util/virutil.c
+++ b/src/util/virutil.c
@@ -759,12 +759,13 @@ static char *virGetXDGDirectory(const char *xdgenvname,
const char *xdgdefdir)
{
const char *path = getenv(xdgenvname);
char *ret = NULL;
-char *home = virGetUserEnt(geteuid(), VIR_USER_ENT_DIRECTORY);
+char *home = NULL;
if (path path[0]) {
if (virAsprintf(ret, %s/libvirt, path) 0)
goto no_memory;
} else {
+home = virGetUserEnt(geteuid(), VIR_USER_ENT_DIRECTORY);
if (virAsprintf(ret, %s/%s/libvirt, home, xdgdefdir) 0)
goto no_memory;
}
ACK
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] check return values of virBufferTrim
On 17.06.2013 10:34, Ján Tomko wrote:
Just to silence Coverity:
Event check_return:
Calling function virBufferTrim(virBufferPtr, char const *, int)
without checking return value (as is done elsewhere 5 out of 6 times).
---
src/node_device/node_device_udev.c | 5 ++---
src/rpc/virnetsshsession.c | 3 +--
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/src/node_device/node_device_udev.c
b/src/node_device/node_device_udev.c
index bb58415..a37989a 100644
--- a/src/node_device/node_device_udev.c
+++ b/src/node_device/node_device_udev.c
@@ -370,9 +370,8 @@ udevLogFunction(struct udev *udev ATTRIBUTE_UNUSED,
const char *format = NULL;
virBufferAdd(buf, fmt, -1);
-virBufferTrim(buf, \n, -1);
-
-format = virBufferContentAndReset(buf);
+if (virBufferTrim(buf, \n, -1) = 0)
+format = virBufferContentAndReset(buf);
virLogVMessage(VIR_LOG_FROM_LIBRARY,
virLogPriorityFromSyslog(priority),
diff --git a/src/rpc/virnetsshsession.c b/src/rpc/virnetsshsession.c
index b6aedc8..2299871 100644
--- a/src/rpc/virnetsshsession.c
+++ b/src/rpc/virnetsshsession.c
@@ -362,9 +362,8 @@ virNetSSHCheckHostKey(virNetSSHSessionPtr sess)
* we have to use a *MAGIC* constant. */
for (i = 0; i 16; i++)
virBufferAsprintf(buff, %02hhX:, keyhash[i]);
-virBufferTrim(buff, :, 1);
-if (virBufferError(buff) != 0) {
+if (virBufferTrim(buff, :, 1) 0) {
virReportOOMError();
return -1;
}
Shouldn't we make virBufferTrim call virBufferSetError instead? I think
it's a better approach, as it fits to calling scheme of other virBuffer*
functions better:
virBuffer buf = VIR_BUFFER_INITIALIZER;
virBufferSomething(buf, ...);
virBufferSomethingElse(buf, ...);
if (virBufferError(buf) != 0) {
virReportError(...);
} else {
char *tmp = virBufferContentAndReset(buf);
...
}
I guess it will shut the coverity up as well.
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] check return values of virBufferTrim
On 06/17/2013 02:15 PM, Michal Privoznik wrote:
On 17.06.2013 10:34, Ján Tomko wrote:
Just to silence Coverity:
Event check_return:
Calling function virBufferTrim(virBufferPtr, char const *, int)
without checking return value (as is done elsewhere 5 out of 6 times).
---
src/node_device/node_device_udev.c | 5 ++---
src/rpc/virnetsshsession.c | 3 +--
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/src/node_device/node_device_udev.c
b/src/node_device/node_device_udev.c
index bb58415..a37989a 100644
--- a/src/node_device/node_device_udev.c
+++ b/src/node_device/node_device_udev.c
@@ -370,9 +370,8 @@ udevLogFunction(struct udev *udev ATTRIBUTE_UNUSED,
const char *format = NULL;
virBufferAdd(buf, fmt, -1);
-virBufferTrim(buf, \n, -1);
-
-format = virBufferContentAndReset(buf);
+if (virBufferTrim(buf, \n, -1) = 0)
+format = virBufferContentAndReset(buf);
virLogVMessage(VIR_LOG_FROM_LIBRARY,
virLogPriorityFromSyslog(priority),
diff --git a/src/rpc/virnetsshsession.c b/src/rpc/virnetsshsession.c
index b6aedc8..2299871 100644
--- a/src/rpc/virnetsshsession.c
+++ b/src/rpc/virnetsshsession.c
@@ -362,9 +362,8 @@ virNetSSHCheckHostKey(virNetSSHSessionPtr sess)
* we have to use a *MAGIC* constant. */
for (i = 0; i 16; i++)
virBufferAsprintf(buff, %02hhX:, keyhash[i]);
-virBufferTrim(buff, :, 1);
-if (virBufferError(buff) != 0) {
+if (virBufferTrim(buff, :, 1) 0) {
virReportOOMError();
return -1;
}
Shouldn't we make virBufferTrim call virBufferSetError instead? I think
it's a better approach, as it fits to calling scheme of other virBuffer*
functions better:
Is it really an error if you can't find a string to trim?
Or we could introduce another version of virBufferTrim, without a return
value, to use anywhere we don't care about the return value (i.e. outside the
tests :))
Jan
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] check return values of virBufferTrim
On 17.06.2013 14:53, Ján Tomko wrote:
On 06/17/2013 02:15 PM, Michal Privoznik wrote:
On 17.06.2013 10:34, Ján Tomko wrote:
Just to silence Coverity:
Event check_return:
Calling function virBufferTrim(virBufferPtr, char const *, int)
without checking return value (as is done elsewhere 5 out of 6 times).
---
src/node_device/node_device_udev.c | 5 ++---
src/rpc/virnetsshsession.c | 3 +--
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/src/node_device/node_device_udev.c
b/src/node_device/node_device_udev.c
index bb58415..a37989a 100644
--- a/src/node_device/node_device_udev.c
+++ b/src/node_device/node_device_udev.c
@@ -370,9 +370,8 @@ udevLogFunction(struct udev *udev ATTRIBUTE_UNUSED,
const char *format = NULL;
virBufferAdd(buf, fmt, -1);
-virBufferTrim(buf, \n, -1);
-
-format = virBufferContentAndReset(buf);
+if (virBufferTrim(buf, \n, -1) = 0)
+format = virBufferContentAndReset(buf);
virLogVMessage(VIR_LOG_FROM_LIBRARY,
virLogPriorityFromSyslog(priority),
diff --git a/src/rpc/virnetsshsession.c b/src/rpc/virnetsshsession.c
index b6aedc8..2299871 100644
--- a/src/rpc/virnetsshsession.c
+++ b/src/rpc/virnetsshsession.c
@@ -362,9 +362,8 @@ virNetSSHCheckHostKey(virNetSSHSessionPtr sess)
* we have to use a *MAGIC* constant. */
for (i = 0; i 16; i++)
virBufferAsprintf(buff, %02hhX:, keyhash[i]);
-virBufferTrim(buff, :, 1);
-if (virBufferError(buff) != 0) {
+if (virBufferTrim(buff, :, 1) 0) {
virReportOOMError();
return -1;
}
Shouldn't we make virBufferTrim call virBufferSetError instead? I think
it's a better approach, as it fits to calling scheme of other virBuffer*
functions better:
Is it really an error if you can't find a string to trim?
No, but is an error if you don't provide a string and provide a len,
that is you call:
virBufferTrim(buf, NULL, -1);
All other combinations are valid == no error is set. So I think we need
something like this:
diff --git a/src/util/virbuffer.c b/src/util/virbuffer.c
index 693e4b2..9004b35 100644
--- a/src/util/virbuffer.c
+++ b/src/util/virbuffer.c
@@ -669,9 +669,14 @@ virBufferTrim(virBufferPtr buf, const char *str,
int len)
{
size_t len2 = 0;
-if (!buf || buf-error || (!str len 0))
+if (!buf || buf-error)
return -1;
+if (!str len 0) {
+virBufferSetError(buf, -1);
+return -1;
+}
+
if (len 0 len buf-use)
return 0;
if (str) {
I think this will both meet the scheme as I've pointed out above and
silent coverity.
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCHv2 2/2] conf: Swap order of AddImplicitControllers and DomainDefPostParse
Implicit controllers may be dependent on device definitions altered in a post-parse callback. Specifically, if a console device is defined without the target type, the type will be set in QEMU's callback. In the case of s390, this is virtio, which requires an implicit virtio-serial controller. Signed-off-by: Viktor Mihajlovski mihaj...@linux.vnet.ibm.com --- src/conf/domain_conf.c |8 .../qemuxml2xmlout-balloon-device-auto.xml |2 +- .../qemuxml2xmlout-channel-virtio-auto.xml |2 +- .../qemuxml2xmlout-console-virtio.xml |2 +- .../qemuxml2xmlout-disk-scsi-device-auto.xml |2 +- 5 files changed, 8 insertions(+), 8 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 2373397..a5c2315 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -12058,14 +12058,14 @@ virDomainDefParseXML(xmlDocPtr xml, (def-ns.parse)(xml, root, ctxt, def-namespaceData) 0) goto error; -/* Auto-add any implied controllers which aren't present */ -if (virDomainDefAddImplicitControllers(def) 0) -goto error; - /* callback to fill driver specific domain aspects */ if (virDomainDefPostParse(def, caps, xmlopt) 0) goto error; +/* Auto-add any implied controllers which aren't present */ +if (virDomainDefAddImplicitControllers(def) 0) +goto error; + virHashFree(bootHash); return def; diff --git a/tests/qemuxml2xmloutdata/qemuxml2xmlout-balloon-device-auto.xml b/tests/qemuxml2xmloutdata/qemuxml2xmlout-balloon-device-auto.xml index 6aed326..380b70f 100644 --- a/tests/qemuxml2xmloutdata/qemuxml2xmlout-balloon-device-auto.xml +++ b/tests/qemuxml2xmloutdata/qemuxml2xmlout-balloon-device-auto.xml @@ -20,8 +20,8 @@ address type='drive' controller='0' bus='0' target='0' unit='0'/ /disk controller type='usb' index='0'/ -controller type='ide' index='0'/ controller type='pci' index='0' model='pci-root'/ +controller type='ide' index='0'/ memballoon model='virtio'/ /devices /domain diff --git a/tests/qemuxml2xmloutdata/qemuxml2xmlout-channel-virtio-auto.xml b/tests/qemuxml2xmloutdata/qemuxml2xmlout-channel-virtio-auto.xml index 0175272..fd6b852 100644 --- a/tests/qemuxml2xmloutdata/qemuxml2xmlout-channel-virtio-auto.xml +++ b/tests/qemuxml2xmloutdata/qemuxml2xmlout-channel-virtio-auto.xml @@ -25,8 +25,8 @@ controller type='virtio-serial' index='1' address type='pci' domain='0x' bus='0x00' slot='0x0a' function='0x0'/ /controller -controller type='virtio-serial' index='2'/ controller type='pci' index='0' model='pci-root'/ +controller type='virtio-serial' index='2'/ channel type='pty' target type='virtio' name='org.linux-kvm.port.0'/ address type='virtio-serial' controller='0' bus='0' port='1'/ diff --git a/tests/qemuxml2xmloutdata/qemuxml2xmlout-console-virtio.xml b/tests/qemuxml2xmloutdata/qemuxml2xmlout-console-virtio.xml index 3c865c3..340430e 100644 --- a/tests/qemuxml2xmloutdata/qemuxml2xmlout-console-virtio.xml +++ b/tests/qemuxml2xmloutdata/qemuxml2xmlout-console-virtio.xml @@ -21,8 +21,8 @@ /disk controller type='usb' index='0'/ controller type='ide' index='0'/ -controller type='virtio-serial' index='0'/ controller type='pci' index='0' model='pci-root'/ +controller type='virtio-serial' index='0'/ console type='pty' target type='virtio' port='0'/ /console diff --git a/tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-scsi-device-auto.xml b/tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-scsi-device-auto.xml index 7d152bc..5ec1e94 100644 --- a/tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-scsi-device-auto.xml +++ b/tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-scsi-device-auto.xml @@ -26,8 +26,8 @@ /disk controller type='usb' index='0'/ controller type='ide' index='0'/ -controller type='scsi' index='0'/ controller type='pci' index='0' model='pci-root'/ +controller type='scsi' index='0'/ memballoon model='virtio'/ /devices /domain -- 1.7.9.5 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCHv2 1/2] S390: Testcase for console default target type (virtio)
For s390 the default console target type is virtio. This also requires that an implicit virtio-serial controller is instantiated. This testcase verifies that the target type of virtio is correctly set in the generated XML if no target element was given and that the corresponding virtio-serial element is generated too. Signed-off-by: Viktor Mihajlovski mihaj...@linux.vnet.ibm.com --- .../qemuxml2argv-s390-defaultconsole.xml | 20 .../qemuxml2xmlout-s390-defaultconsole.xml | 24 tests/qemuxml2xmltest.c|2 ++ 3 files changed, 46 insertions(+) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-s390-defaultconsole.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-s390-defaultconsole.xml diff --git a/tests/qemuxml2argvdata/qemuxml2argv-s390-defaultconsole.xml b/tests/qemuxml2argvdata/qemuxml2argv-s390-defaultconsole.xml new file mode 100644 index 000..036027c --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-s390-defaultconsole.xml @@ -0,0 +1,20 @@ +domain type='kvm' + nametest/name + uuid9aa4b45c-b9dd-45ef-91fe-862b27b4231f/uuid + memory unit='KiB'262144/memory + currentMemory unit='KiB'262144/currentMemory + vcpu placement='static'1/vcpu + os +type arch='s390x' machine='s390-virtio'hvm/type +boot dev='hd'/ + /os + clock offset='utc'/ + on_poweroffdestroy/on_poweroff + on_rebootrestart/on_reboot + on_crashdestroy/on_crash + devices +emulator/usr/bin/qemu-kvm/emulator +console type='pty'/ +memballoon model='none'/ + /devices +/domain diff --git a/tests/qemuxml2xmloutdata/qemuxml2xmlout-s390-defaultconsole.xml b/tests/qemuxml2xmloutdata/qemuxml2xmlout-s390-defaultconsole.xml new file mode 100644 index 000..9a609f8 --- /dev/null +++ b/tests/qemuxml2xmloutdata/qemuxml2xmlout-s390-defaultconsole.xml @@ -0,0 +1,24 @@ +domain type='kvm' + nametest/name + uuid9aa4b45c-b9dd-45ef-91fe-862b27b4231f/uuid + memory unit='KiB'262144/memory + currentMemory unit='KiB'262144/currentMemory + vcpu placement='static'1/vcpu + os +type arch='s390x' machine='s390-virtio'hvm/type +boot dev='hd'/ + /os + clock offset='utc'/ + on_poweroffdestroy/on_poweroff + on_rebootrestart/on_reboot + on_crashdestroy/on_crash + devices +emulator/usr/bin/qemu-kvm/emulator +controller type='usb' index='0' model='none'/ +controller type='virtio-serial' index='0'/ +console type='pty' + target type='virtio' port='0'/ +/console +memballoon model='none'/ + /devices +/domain diff --git a/tests/qemuxml2xmltest.c b/tests/qemuxml2xmltest.c index 06e4206..65e9591 100644 --- a/tests/qemuxml2xmltest.c +++ b/tests/qemuxml2xmltest.c @@ -300,6 +300,8 @@ mymain(void) DO_TEST_DIFFERENT(hostdev-scsi-autogen-address); +DO_TEST_DIFFERENT(s390-defaultconsole); + virObjectUnref(driver.caps); virObjectUnref(driver.xmlopt); -- 1.7.9.5 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCHv2 0/2] Swap order of AddImplicitControllers and DomainDefPostParse
Implicit controllers may be dependent on device definitions altered in a post-parse callback. E.g., if a console device is defined without the target type, the type will be set in QEMU's callback. In the case of s390, this is virtio, which requires an implicit virtio-serial controller. By moving the implicit controller definition after the post-parse procssing this can be fixed. As Martin pointed out, implicit controllers should not need post-parsing, so the rearranging should not hurt. Probably this is only affecting the S390 virtio console anyway. V2 Changes: - Promoted from RFC to Patch Series - Added an qemuxml2xml testcase highlighting the issue: applying the first patch only will fail make check as the implicit controller is missing. Viktor Mihajlovski (2): S390: Testcase for console default target type (virtio) conf: Swap order of AddImplicitControllers and DomainDefPostParse src/conf/domain_conf.c |8 +++ .../qemuxml2argv-s390-defaultconsole.xml | 20 .../qemuxml2xmlout-balloon-device-auto.xml |2 +- .../qemuxml2xmlout-channel-virtio-auto.xml |2 +- .../qemuxml2xmlout-console-virtio.xml |2 +- .../qemuxml2xmlout-disk-scsi-device-auto.xml |2 +- .../qemuxml2xmlout-s390-defaultconsole.xml | 24 tests/qemuxml2xmltest.c|2 ++ 8 files changed, 54 insertions(+), 8 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-s390-defaultconsole.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-s390-defaultconsole.xml -- 1.7.9.5 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] libvirt-python API for domdisplay
Hi all: Work with virsh CLI, I can easy use the CLI virsh -c qemu+tcp://127.0.0.1/system domdisplay instance-0001 successfully: [root@webmintest ~]# virsh -c qemu+tcp://127.0.0.1/system domdisplay instance-0001 Please enter your authentication name: fred Please enter your password: vnc://127.0.0.1:0 However, I can find any libvit-python API related to this CLI, does it exist ? Thanks. 2013-06-17 mzawdx-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvirt-python API for domdisplay
On 17.06.2013 17:19, mzawdx wrote: Hi all: Work with virsh CLI, I can easy use the CLI virsh -c qemu+tcp://127.0.0.1/system domdisplay instance-0001 successfully: [root@webmintest ~]# virsh -c qemu+tcp://127.0.0.1/system domdisplay instance-0001 Please enter your authentication name: fred Please enter your password: vnc://127.0.0.1:0 However, I can find any libvit-python API related to this CLI, does it exist ? No. The domdisplay command is pure virsh with a XPATH magic. The algorithm is as follows: 1) dump the XML of desired domain 2) for i in vnc, spice, rdp; do 2a) xpath = string(/domain/devices/graphics[@type='%s']/@port), %i 2b) port = xpath_query($domxml, $xpath) 2c) if !port continue 2d) xpath = string(/domain/devices/graphics[@type='%s']/@listen), %i 2e) listen = xpath_query($domxml, $xpath) 2f) if ($i == vnc) port -= 5900; 3) print %s://%s:%d, %i %listen %port The whole source is here: http://libvirt.org/git/?p=libvirt.git;a=blob;f=tools/virsh-domain.c;h=955e882151827dc69f9aeb374a870134a9777910;hb=HEAD#l8756 Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] spec: Enable KVM support on ARM
F20/rawhide has will support this.
From: Peter Robinson pbrobin...@gmail.com
---
libvirt.spec.in | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index 8d43e6d..e357a3d 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -54,7 +54,11 @@
%define with_qemu_tcg %{with_qemu}
# Change if we ever provide qemu-kvm binaries on non-x86 hosts
%if 0%{?fedora} = 18
-%define qemu_kvm_arches%{ix86} x86_64 ppc64 s390x
+%if 0%{?fedora} = 20
+%define qemu_kvm_arches%{ix86} x86_64 ppc64 s390x %{arm}
+%else
+%define qemu_kvm_arches%{ix86} x86_64 ppc64 s390x
+%endif
%else
%define qemu_kvm_arches%{ix86} x86_64
%endif
--
1.8.2.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv4] Configure native vlan modes on Open vSwitch ports
Are there any comments on this iteration?
On Thu, 2013-05-23 at 18:12 +0100, james robson wrote:
This patch adds functionality to allow libvirt to configure the
'native-tagged' and 'native-untagged' modes on openvswitch networks.
v2 changes:
Fix problems reported by Eric Blake
v3 changes:
Re work patch to address review comments
v4 changes:
Use enum for native modes
---
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 9284534..ba32185 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -3498,6 +3498,13 @@ qemu-kvm -net nic,model=? /dev/null
lt;parameters
interfaceid='09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f'/gt;
lt;/virtualportgt;
lt;/interfacegt;
+lt;interface type='bridge'gt;
+ blt;vlan trunk='yes'gt;/b
+blt;tag id='42'/gt;/b
+blt;tag id='123' nativeMode='untagged'/gt;/b
+ blt;/vlangt;/b
+ ...
+lt;/interfacegt;
lt;devicesgt;
.../pre
@@ -3524,6 +3531,15 @@ qemu-kvm -net nic,model=? /dev/null
vlan element.
/p
+p
+ For network connections using openvswitch it is possible to
+ configure the 'native-tagged' and 'native-untagged' vlan modes
+ span class=since(Since 1.0.5)./span This uses the optional
+ codenativeMode/code attribute on the codelt;taggt;/code
+ element: codenativeMode/code may be set to 'tagged' or
+ 'untagged'. The id atribute of the element sets the native vlan.
+/p
+
h5a name=elementLinkModifying virtual link state/a/h5
pre
...
diff --git a/docs/formatnetwork.html.in b/docs/formatnetwork.html.in
index a1198ce..29e12d9 100644
--- a/docs/formatnetwork.html.in
+++ b/docs/formatnetwork.html.in
@@ -446,6 +446,13 @@
lt;parameters
interfaceid='09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f'/gt;
lt;/virtualportgt;
lt;/interfacegt;
+lt;interface type='bridge'gt;
+ blt;vlan trunk='yes'gt;/b
+blt;tag id='42'/gt;/b
+blt;tag id='123' nativeMode='untagged'/gt;/b
+ blt;/vlangt;/b
+ ...
+lt;/interfacegt;
lt;devicesgt;
.../pre
@@ -469,6 +476,14 @@
be added to the vlan element.
/p
p
+ For network connections using openvswitch it is possible to
+ configure the 'native-tagged' and 'native-untagged' vlan modes
+ span class=since(Since 1.0.6)./span This uses the optional
+ codenativeMode/code attribute on the codelt;taggt;/code
+ element: codenativeMode/code may be set to 'tagged' or
+ 'untagged'. The id atribute of the element sets the native vlan.
+/p
+p
codelt;vlangt;/code elements can also be specified in
a codelt;portgroupgt;/code element, as well as directly in
a domain's codelt;interfacegt;/code element. In the case
diff --git a/docs/schemas/networkcommon.rng b/docs/schemas/networkcommon.rng
index 51ff759..e60f1fc 100644
--- a/docs/schemas/networkcommon.rng
+++ b/docs/schemas/networkcommon.rng
@@ -204,6 +204,14 @@
param name=maxInclusive4095/param
/data
/attribute
+ optional
+attribute name=nativeMode
+ choice
+valuetagged/value
+valueuntagged/value
+ /choice
+/attribute
+ /optional
empty/
/element
/oneOrMore
diff --git a/src/conf/netdev_vlan_conf.c b/src/conf/netdev_vlan_conf.c
index 13ba8c6..2b4cd48 100644
--- a/src/conf/netdev_vlan_conf.c
+++ b/src/conf/netdev_vlan_conf.c
@@ -17,6 +17,7 @@
*
* Authors:
* Laine Stump la...@redhat.com
+ * James Robson jrob...@websense.com
*/
#include config.h
@@ -27,12 +28,15 @@
#define VIR_FROM_THIS VIR_FROM_NONE
+VIR_ENUM_IMPL(virNativeVlanMode, VIR_NATIVE_VLAN_MODE_LAST, default,
tagged, untagged)
+
int
virNetDevVlanParse(xmlNodePtr node, xmlXPathContextPtr ctxt,
virNetDevVlanPtr def)
{
int ret = -1;
xmlNodePtr save = ctxt-node;
const char *trunk = NULL;
+const char *nativeMode = NULL;
xmlNodePtr *tagNodes = NULL;
int nTags, ii;
@@ -54,6 +58,8 @@ virNetDevVlanParse(xmlNodePtr node, xmlXPathContextPtr
ctxt, virNetDevVlanPtr de
goto error;
}
+def-nativeMode = 0;
+def-nativeTag = 0;
for (ii = 0; ii nTags; ii++) {
unsigned long id;
@@ -68,6 +74,19 @@ virNetDevVlanParse(xmlNodePtr node, xmlXPathContextPtr
ctxt, virNetDevVlanPtr de
_(vlan tag id %lu too large (maximum 4095)),
id);
goto error;
}
+if ((nativeMode = virXPathString(string(./@nativeMode), ctxt)) !=
NULL) {
+if (def-nativeMode != 0) {
+virReportError(VIR_ERR_XML_ERROR, %s,
+ _(duplicate native vlan setting));
+goto error;
+}
+if
Re: [libvirt] [PATCHv4] Configure native vlan modes on Open vSwitch ports
On 06/17/2013 01:56 PM, james robson wrote:
Are there any comments on this iteration?
Sorry, it somehow got lost in my unread list mail. I'll do my best to
review it before the end of the week.
On Thu, 2013-05-23 at 18:12 +0100, james robson wrote:
This patch adds functionality to allow libvirt to configure the
'native-tagged' and 'native-untagged' modes on openvswitch networks.
v2 changes:
Fix problems reported by Eric Blake
v3 changes:
Re work patch to address review comments
v4 changes:
Use enum for native modes
---
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 9284534..ba32185 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -3498,6 +3498,13 @@ qemu-kvm -net nic,model=? /dev/null
lt;parameters
interfaceid='09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f'/gt;
lt;/virtualportgt;
lt;/interfacegt;
+lt;interface type='bridge'gt;
+ blt;vlan trunk='yes'gt;/b
+blt;tag id='42'/gt;/b
+blt;tag id='123' nativeMode='untagged'/gt;/b
+ blt;/vlangt;/b
+ ...
+lt;/interfacegt;
lt;devicesgt;
.../pre
@@ -3524,6 +3531,15 @@ qemu-kvm -net nic,model=? /dev/null
vlan element.
/p
+p
+ For network connections using openvswitch it is possible to
+ configure the 'native-tagged' and 'native-untagged' vlan modes
+ span class=since(Since 1.0.5)./span This uses the optional
+ codenativeMode/code attribute on the codelt;taggt;/code
+ element: codenativeMode/code may be set to 'tagged' or
+ 'untagged'. The id atribute of the element sets the native vlan.
+/p
+
h5a name=elementLinkModifying virtual link state/a/h5
pre
...
diff --git a/docs/formatnetwork.html.in b/docs/formatnetwork.html.in
index a1198ce..29e12d9 100644
--- a/docs/formatnetwork.html.in
+++ b/docs/formatnetwork.html.in
@@ -446,6 +446,13 @@
lt;parameters
interfaceid='09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f'/gt;
lt;/virtualportgt;
lt;/interfacegt;
+lt;interface type='bridge'gt;
+ blt;vlan trunk='yes'gt;/b
+blt;tag id='42'/gt;/b
+blt;tag id='123' nativeMode='untagged'/gt;/b
+ blt;/vlangt;/b
+ ...
+lt;/interfacegt;
lt;devicesgt;
.../pre
@@ -469,6 +476,14 @@
be added to the vlan element.
/p
p
+ For network connections using openvswitch it is possible to
+ configure the 'native-tagged' and 'native-untagged' vlan modes
+ span class=since(Since 1.0.6)./span This uses the optional
+ codenativeMode/code attribute on the codelt;taggt;/code
+ element: codenativeMode/code may be set to 'tagged' or
+ 'untagged'. The id atribute of the element sets the native vlan.
+/p
+p
codelt;vlangt;/code elements can also be specified in
a codelt;portgroupgt;/code element, as well as directly in
a domain's codelt;interfacegt;/code element. In the case
diff --git a/docs/schemas/networkcommon.rng b/docs/schemas/networkcommon.rng
index 51ff759..e60f1fc 100644
--- a/docs/schemas/networkcommon.rng
+++ b/docs/schemas/networkcommon.rng
@@ -204,6 +204,14 @@
param name=maxInclusive4095/param
/data
/attribute
+ optional
+attribute name=nativeMode
+ choice
+valuetagged/value
+valueuntagged/value
+ /choice
+/attribute
+ /optional
empty/
/element
/oneOrMore
diff --git a/src/conf/netdev_vlan_conf.c b/src/conf/netdev_vlan_conf.c
index 13ba8c6..2b4cd48 100644
--- a/src/conf/netdev_vlan_conf.c
+++ b/src/conf/netdev_vlan_conf.c
@@ -17,6 +17,7 @@
*
* Authors:
* Laine Stump la...@redhat.com
+ * James Robson jrob...@websense.com
*/
#include config.h
@@ -27,12 +28,15 @@
#define VIR_FROM_THIS VIR_FROM_NONE
+VIR_ENUM_IMPL(virNativeVlanMode, VIR_NATIVE_VLAN_MODE_LAST, default,
tagged, untagged)
+
int
virNetDevVlanParse(xmlNodePtr node, xmlXPathContextPtr ctxt,
virNetDevVlanPtr def)
{
int ret = -1;
xmlNodePtr save = ctxt-node;
const char *trunk = NULL;
+const char *nativeMode = NULL;
xmlNodePtr *tagNodes = NULL;
int nTags, ii;
@@ -54,6 +58,8 @@ virNetDevVlanParse(xmlNodePtr node, xmlXPathContextPtr
ctxt, virNetDevVlanPtr de
goto error;
}
+def-nativeMode = 0;
+def-nativeTag = 0;
for (ii = 0; ii nTags; ii++) {
unsigned long id;
@@ -68,6 +74,19 @@ virNetDevVlanParse(xmlNodePtr node, xmlXPathContextPtr
ctxt, virNetDevVlanPtr de
_(vlan tag id %lu too large (maximum 4095)),
id);
goto error;
}
+if ((nativeMode = virXPathString(string(./@nativeMode), ctxt)) !=
NULL) {
+if (def-nativeMode != 0) {
+
