Re: [libvirt] [PATCH 3/4] Fix QEMU save/restore with block devices
On 04/24/2010 12:50 AM, Laine Stump wrote: Is it really necessary to add this padding even when we *aren't* using dd? (ie, when is_reg == 1). Nevermind. Now that I've actual RTFC, I see that this new code *always* use dd. However, I just noticed an SELinux complaint about dd attempting to write to a file on an NFS-mounted directory. My system is running SELinux in permissive mode, so it succeeded, but won't this be a problem if it's in enforcing mode? -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] esx: Distribute generated methods code
--- src/Makefile.am |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/Makefile.am b/src/Makefile.am index 17b2226..00ab65d 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -255,6 +255,8 @@ ESX_DRIVER_SOURCES = \ esx/esx_vmx.c esx/esx_vmx.h ESX_DRIVER_GENERATED = \ + esx/esx_vi_methods.generated.c \ + esx/esx_vi_methods.generated.h \ esx/esx_vi_types.generated.c\ esx/esx_vi_types.generated.h\ esx/esx_vi_types.generated.typedef \ -- 1.6.3.3 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] cygwin: Handle differences in the XDR implementation
Cygwin's XDR implementation defines xdr_u_int64_t instead of
xdr_uint64_t and lacks IXDR_PUT_INT32/IXDR_GET_INT32.
Alter the IXDR_GET_LONG regex in rpcgen_fix.pl so it doesn't destroy
the #define IXDR_GET_INT32 IXDR_GET_LONG in remote_protocol.x.
Also fix the remote_protocol.h regex in rpcgen_fix.pl.
---
configure.ac |3 +++
src/remote/remote_protocol.c | 11 ++-
src/remote/remote_protocol.h |9 +
src/remote/remote_protocol.x | 13 +
src/remote/rpcgen_fix.pl |4 ++--
5 files changed, 37 insertions(+), 3 deletions(-)
diff --git a/configure.ac b/configure.ac
index d75fac8..955a9e9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -124,6 +124,9 @@ AC_CHECK_LIB([portablexdr],[xdrmem_create],[],[
[AC_MSG_ERROR([Cannot find a XDR library])])
])
+dnl check for cygwin's variation in xdr function names
+AC_CHECK_FUNCS([xdr_u_int64_t],[],[],[#include rpc/xdr.h])
+
AC_CHECK_LIB([intl],[gettext],[])
dnl Do we have rpcgen?
diff --git a/src/remote/remote_protocol.c b/src/remote/remote_protocol.c
index c9816dd..eb0f9c3 100644
--- a/src/remote/remote_protocol.c
+++ b/src/remote/remote_protocol.c
@@ -4,9 +4,18 @@
* It was generated using rpcgen.
*/
-#include ./remote/remote_protocol.h
+#include remote_protocol.h
#include internal.h
#include arpa/inet.h
+#ifdef HAVE_XDR_U_INT64_T
+# define xdr_uint64_t xdr_u_int64_t
+#endif
+#ifndef IXDR_PUT_INT32
+# define IXDR_PUT_INT32 IXDR_PUT_LONG
+#endif
+#ifndef IXDR_GET_INT32
+# define IXDR_GET_INT32 IXDR_GET_LONG
+#endif
bool_t
xdr_remote_nonnull_string (XDR *xdrs, remote_nonnull_string *objp)
diff --git a/src/remote/remote_protocol.h b/src/remote/remote_protocol.h
index 57ed123..92fd6df 100644
--- a/src/remote/remote_protocol.h
+++ b/src/remote/remote_protocol.h
@@ -15,6 +15,15 @@ extern C {
#include internal.h
#include arpa/inet.h
+#ifdef HAVE_XDR_U_INT64_T
+# define xdr_uint64_t xdr_u_int64_t
+#endif
+#ifndef IXDR_PUT_INT32
+# define IXDR_PUT_INT32 IXDR_PUT_LONG
+#endif
+#ifndef IXDR_GET_INT32
+# define IXDR_GET_INT32 IXDR_GET_LONG
+#endif
#define REMOTE_MESSAGE_MAX 262144
#define REMOTE_MESSAGE_HEADER_MAX 24
#define REMOTE_MESSAGE_PAYLOAD_MAX 262120
diff --git a/src/remote/remote_protocol.x b/src/remote/remote_protocol.x
index 9aa3a7e..60f93b2 100644
--- a/src/remote/remote_protocol.x
+++ b/src/remote/remote_protocol.x
@@ -39,6 +39,19 @@
%#include internal.h
%#include arpa/inet.h
+/* cygwin's xdr implementation defines xdr_u_int64_t instead of xdr_uint64_t
+ * and lacks IXDR_PUT_INT32 and IXDR_GET_INT32
+ */
+%#ifdef HAVE_XDR_U_INT64_T
+%# define xdr_uint64_t xdr_u_int64_t
+%#endif
+%#ifndef IXDR_PUT_INT32
+%# define IXDR_PUT_INT32 IXDR_PUT_LONG
+%#endif
+%#ifndef IXDR_GET_INT32
+%# define IXDR_GET_INT32 IXDR_GET_LONG
+%#endif
+
/*- Data types. -*/
/* Maximum total message size (serialised). */
diff --git a/src/remote/rpcgen_fix.pl b/src/remote/rpcgen_fix.pl
index 4943765..3cf5479 100644
--- a/src/remote/rpcgen_fix.pl
+++ b/src/remote/rpcgen_fix.pl
@@ -31,8 +31,8 @@ while () {
s/quad_t/int64_t/g;
s/xdr_u_quad_t/xdr_uint64_t/g;
s/xdr_quad_t/xdr_int64_t/g;
-s/IXDR_GET_LONG/IXDR_GET_INT32/g;
-s,#include \./remote_protocol\.h,#include remote_protocol.h,;
+s/(?!IXDR_GET_INT32 )IXDR_GET_LONG/IXDR_GET_INT32/g;
+s,#include \./remote/remote_protocol\.h,#include remote_protocol.h,;
if (m/^}/) {
$in_function = 0;
--
1.6.3.3
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Cygwin's GCC doesn't like this .sa_handler initialization for some reason
---
examples/domain-events/events-c/event-test.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/examples/domain-events/events-c/event-test.c
b/examples/domain-events/events-c/event-test.c
index 53a3195..74eabba 100644
--- a/examples/domain-events/events-c/event-test.c
+++ b/examples/domain-events/events-c/event-test.c
@@ -380,10 +380,11 @@ int main(int argc, char **argv)
int callback5ret = -1;
int callback6ret = -1;
int callback7ret = -1;
+struct sigaction action_stop;
-struct sigaction action_stop = {
-.sa_handler = stop
-};
+memset(action_stop, 0, sizeof action_stop);
+
+action_stop.sa_handler = stop;
if(argc 1 STREQ(argv[1],--help)) {
usage(argv[0]);
--
1.6.3.3
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Re: Libvirt debug API
On 04/25/2010 06:39 AM, Anthony Liguori wrote: On 04/24/2010 04:46 AM, Avi Kivity wrote: On 04/23/2010 09:29 PM, Anthony Liguori wrote: Maybe. We'll still have issues. For example, sVirt: if a QMP command names a labeled resource, the non-libvirt user will have no way of knowing how to label it. This is orthogonal to QMP and has to do strictly with how libvirt prepares a resource for qemu. It's not orthogonal. If you allow qmp access behind libvirt's back, it's a problem that you will have. My point was, if libvirt is just exposing raw qemu features, then it should be possible for qemu to arbitrate concurrent access. If libvirt implements features on top of qemu, then no other third party will be able to co-exist with those features without interacting with qemu. It's an impossible problem for qemu to solve (arbitrating access to state stored in a third party management app). If libvirt implement features (like sVirt or network configuration) then it is indeed impossible for qemu to arbitrate. If we take all those features into qemu[d], then it becomes possible to arbitrate so long as the libvirt and the other management app don't step on each others toes. But that's impossible to guarantee if you upgrade your libvirt while keeping the other app unchanged. 1) Allow libvirt users to access features of qemu that are not exposed through libvirt That's an artificial problem. If libvirt exposes all features, you don't need to solve it. It won't. Otherwise, we wouldn't be having this discussion. Then libvirt will fade into uselessness. A successful app using libvirt will grow, and will have new requirements. As soon as libvirt doesn't meet those new requirements, the app will need to talk to qemu[d] directly. Once it does that, it may as well use qemu[d] for everything; if you can talk QMP and generate qemu command lines, there's not much that libvirt buys you. Even the cross-hypervisor support is not that hard to implement, especially if you only need to satisfy your own requirements. 2) Provide a means for non-libvirt users to interact with qemu We have qmp. It doesn't do multiple guest management. I think it's reasonable to have a qemud which does (and also does sVirt and the zillion other things libvirt does) provided we remove them from libvirt (long term). The only problem is that it's a lot of effort. It depends on what things you think are important. A lot of libvirt's complexity is based on the fact that it uses a daemon and needs to deal with the security implications of that. You don't need explicit labelling if you don't use a daemon. I don't follow. If you have multiple guests that you want off each other's turf you have to label their resources, either statically or dynamically. How is it related to a daemon being present? This is really the qemu model (as opposed to the xend model). (and the qemud model). In theory, it does support this with the session urls but they are currently second-class citizens in libvirt. The remote dispatch also adds a fair bit of complexity and at least for the use-cases I'm interested in, it's not an important feature. If libvirt needs a local wrapper for interesting use cases, then it has failed. You can't have a local wrapper with the esx driver, for example. This is off-topic, but can you detail why you don't want remote dispatch (I assume we're talking about a multiple node deployment). 3) Provide a unified and interoperable view of the world for non-libvirt and libvirt users This problem can be solved by the non-libvirt users adopting libvirt, or the libvirt users dropping libvirt. I don't understand why we need to add interoperability between users who choose an interoperability library and users who don't choose an interoperability library. What I'd like to avoid is user confusion. Should a user use libvirt or libqemu? If they make a decision to use libqemu and then down the road want to use libvirt, how hard is it to switch? Fragmentation hurts the ecosystem and discourages good applications from existing. I think it's our responsibility to ensure there's a good management API that exists for qemu that we can actively recommend to our users. libvirt is very good at typical virtualization uses of qemu but qemu is much more than just that and has lots of advanced features. Every typical virtualization use will eventually grow some non-typical requirements. If libvirt explicitly refuses to support qemu features, I don't see how we can recommend it - even if it satisfies a user's requirements today, what about tomorrow? what about future qemu feature, will they be exposed or not? If that is the case then we should develop qemud (which libvirt and other apps can use). (even if it isn't the case I think qemud is a good idea) For (1), we all agree that the best case scenario would be for libvirt to support every qemu
Re: [libvirt] [Qemu-devel] Re: Libvirt debug API
On 04/23/2010 09:33 PM, Anthony Liguori wrote: This is a different ambiguity, about the semantic results of the commands, where as I'm refering to the execution order. If I look at a libvirt log file and see a set of JSON commands logged, I want to know that this ordering from the logs, was indeed the same as order in which qemu processed them. If you have two separate monitor connection you can't be sure of the order of execution. It is key for our bug troubleshooting that given a libvirt log file, we can replay the JSON commands again and get the same results. Two monitor connections is just increasing complexity of code without any tangible benefit. I think you're assuming direct access to the second monitor? I'm not suggesting that. I'm suggesting that libvirt is still the one submitting commands to the second monitor and that it submits those commands in lock step. What about protocol extensions? For instance, pretend libvirt doesn't support async messages, what would it do when it receives one from the user's monitor? -- error compiling committee.c: too many arguments to function -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Re: Libvirt debug API
On 04/25/2010 06:51 AM, Avi Kivity wrote: It depends on what things you think are important. A lot of libvirt's complexity is based on the fact that it uses a daemon and needs to deal with the security implications of that. You don't need explicit labelling if you don't use a daemon. I don't follow. If you have multiple guests that you want off each other's turf you have to label their resources, either statically or dynamically. How is it related to a daemon being present? Because libvirt has to perform this labelling because it loses the original user's security context. If you invoke qemu with the original user's credentials that launched the guest, then you don't need to do anything special with respect to security. IOW, libvirt does not run guests as separate users which is why it needs to deal with security in the first place. This is really the qemu model (as opposed to the xend model). (and the qemud model). And I've said in the past that I don't like the idea of a qemud :-) In theory, it does support this with the session urls but they are currently second-class citizens in libvirt. The remote dispatch also adds a fair bit of complexity and at least for the use-cases I'm interested in, it's not an important feature. If libvirt needs a local wrapper for interesting use cases, then it has failed. You can't have a local wrapper with the esx driver, for example. This is off-topic, but can you detail why you don't want remote dispatch (I assume we're talking about a multiple node deployment). Because there are dozens of remote management APIs and then all have a concept of agents that run on the end nodes. When fitting virtualization management into an existing management infrastructure, you are going to always use a local API. If you use a remote management API, you then have to worry about security, authorization, and authentication. Just supporting SASL really isn't enough because there are a lot fewer actual deployments of kerberos out there (most of them are actually Active Directory and SASL alone is not enough to interoperate with AD). 3) Provide a unified and interoperable view of the world for non-libvirt and libvirt users This problem can be solved by the non-libvirt users adopting libvirt, or the libvirt users dropping libvirt. I don't understand why we need to add interoperability between users who choose an interoperability library and users who don't choose an interoperability library. What I'd like to avoid is user confusion. Should a user use libvirt or libqemu? If they make a decision to use libqemu and then down the road want to use libvirt, how hard is it to switch? Fragmentation hurts the ecosystem and discourages good applications from existing. I think it's our responsibility to ensure there's a good management API that exists for qemu that we can actively recommend to our users. libvirt is very good at typical virtualization uses of qemu but qemu is much more than just that and has lots of advanced features. Every typical virtualization use will eventually grow some non-typical requirements. If libvirt explicitly refuses to support qemu features, I don't see how we can recommend it - even if it satisfies a user's requirements today, what about tomorrow? what about future qemu feature, will they be exposed or not? If that is the case then we should develop qemud (which libvirt and other apps can use). (even if it isn't the case I think qemud is a good idea) Yeah, that's where I'm at. I'd eventually like libvirt to use our provided API and I can see where it would add value to the stack (by doing things like storage and network management). That's not what the libvirt community wants to do. We're very bias. We've made decisions about how features should be exposed and what features should be included. We want all of those features exposed exactly how we've implemented them because we think it's the right way. I'm not sure there's an obvious way forward unless we decide that there is going to be two ways to interact with qemu. One way is through the libvirt world-view and the other is through a more qemu centric view. The problem then becomes allowing those two models to co-exist happily together. I don't think there's a point in managing qemu through libvirt and directly in parallel. It means a user has to learn both APIs, and for every operation they need to check both to see what's the best way of exploiting the feature. There will invariably be some friction. Layers need to stack on top of each other, not live side by side or bypass each other. I agree with you theoretically but practically, I think it's immensely useful as a stop-gap. The alternative is to get libvirt to just act as a thin layer to expose qemu features directly. But honestly, what's the point of libvirt if they did that? For most hypervisors, that's exactly what libvirt
[libvirt] virsh is not working for other than root users.
Hi, I am using libvirt 0.8.0 on Fedora 32 bit system. When I issue virsh -c lxc:/// with root permissions I m able to see 'virsh' console. But, if I changed to other user say su srikanth, and issue the same command, I am not able to see the virsh console. I am getting authentication failed error. Can anybody please help me in solving the issue? Regards, Srikanth. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
