[Libvir] [PATCH] virsh version
by Atsushi SAKAI
Hi,
Currently virsh version is not work.
Currently just show the libvirt version only.
This is caused by mis-matching of xen(xen_unified.c) and Xen(libvirt.c) .
I do not know the policy. So I attached 2 Pattern.
Thanks
Atsushi SAKAI
=================Pattern1================
--- libvirt.orig/src/xen_unified.c 2007-04-13 09:43:57.000000000 +0900
+++ libvirt.Xen/src/xen_unified.c 2007-04-13 20:02:46.000000000 +0900
@@ -89,8 +89,8 @@ xenUnifiedOpen (virConnectPtr conn, cons
/* If name == NULL, name == "", or begins with "xen", then it's for us. */
if (!name || name[0] == '\0')
- name = "xen";
- if (strncasecmp (name, "xen", 3) != 0)
+ name = "Xen";
+ if (strncasecmp (name, "Xen", 3) != 0)
return VIR_DRV_OPEN_DECLINED;
/* Allocate per-connection private data. */
@@ -719,7 +719,7 @@ xenUnifiedDomainSetAutostart (virDomainP
/* The interface which we export upwards to libvirt.c. */
static virDriver xenUnifiedDriver = {
.no = VIR_DRV_XEN_UNIFIED,
- .name = "xen",
+ .name = "Xen",
.ver = VERSION,
.open = xenUnifiedOpen,
.close = xenUnifiedClose,
=================Pattern2================
--- libvirt.orig/src/libvirt.c 2007-04-12 23:18:39.000000000 +0900
+++ libvirt.Xen/src/libvirt.c 2007-04-13 20:09:02.000000000 +0900
@@ -246,7 +246,7 @@ virGetVersion(unsigned long *libVer, con
if (typeVer != NULL) {
if (type == NULL)
- type = "Xen";
+ type = "xen";
for (i = 0;i < virDriverTabCount;i++) {
if ((virDriverTab[i] != NULL) &&
(!strcmp(virDriverTab[i]->name, type))) {
17 years, 1 month
[Libvir] PATCH: Check for /usr/bin/qemu* binaries before starting guest
by Daniel P. Berrange
The attached patch fixes two issues
- It explicitly checks to see if the requested /usr/bin/qemu* binary
actually exists before fork()/exec()'ing it. While its technically
possible to catch the execve() failure of ENOENT, its a real pain to
feed this error back to the qemu daemon because we're in a sub-process
at that point. The obvious & easy solution is to thus check to see if
the binary exists before trying to fork.
- It only passes the -no-kqemu flag if we're running matching arch to
the host. Previously it would pass the -no-kqemu flag even if running
an x86_64 guest on i686 platform - QEMU then exited with error because
the -no-kqemu flag is not recognised on x86_64 when running on i686 host.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
17 years, 1 month
[Libvir] PATCH: Added QEMU driver for virDomainGetOSType method
by Daniel P. Berrange
For some reason we never had an impl of the virDomainGetOSType method for
the QEMU driver - and for even more bizarre reason it wasn't failing, because
the old libvirt.c code hardcoded 'linux' if there was no impl. The latter
was fixed by Rich, with the xenUnified driver, so exposing the former bug.
This patch adds a simple impl for QEMU - there's no need to talk to the
daemon in this case because QEMU guests can only ever by of type 'hvm'.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
17 years, 1 month
[Libvir] PATCH: Fix exception reporting for virNetwork / virDomain python methods
by Daniel P. Berrange
The virError() class in the python bindings will either pick up the global
error details, or will extract them from the virConnect private error
details. For the latter to work, you must pass in a virConnect object
when creating the virError. I'd previously fixed up the generator so that
was done correctly for any method on virConnectPtr, however, I forgot that
a similar fix was needed for the virDomainPtr / virNetworkPtr related
methods. Currently we're getting back zero useful information in the python
layer with a virDomain* or virNetwork* method fails.
Unfortunately, given a virDomainPtr / virNetworkPtr object in python, there
is no easy way to get back the virConnectPtr object. So this patch does
two things - it passes the virConnect python object into the constructor
of the virDomain / virNetwork python objects, and then stores it in a
private _conn attribute. Then, the virNetwork/virDomain objects are passed
into the virError() classes when needeed so it can get hold of the private
error details.
So with this patch, virt-manager will get sensible error information when
attempting to start an inactive guest, or when doing device hot-add/remove.
BTW, since we now store an explicit reference to the virConnect object,
I removed the generic 'self.ref' back-reference.
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
17 years, 1 month
[Libvir] PATCH: support Xen 3.0.5
by Daniel P. Berrange
I've been doing some testing with current xen-unstable (ie what will very
shortly be 3.0.5) and came across a whole bunch of things which needed
fixing - some expected, others not expected. The attached patch addresses
the following issues:
- Many of the hypercalls have their structs changed so that int64_t
or 'foo *' members are always 64-bit aligned even on 32-bit platforms.
This is part of the work to allow 32-bit Dom0/DomU to work on 64-bit
hypervisor.
For the int64_t types I had to annotate with __attribute__((aligned(8))).
This did not work for pointer data types, so I for those I had to do
a more complex hack with
union {
foo *v;
int64_t pad __attribute__((aligned(8)))
}
This matches what is done in the public (BSD licensed) Xen HV header
files.
We already had ways to deal with v0 vs v2 hypercalls structs. This
change is still techincally v2, but just a minor revision of the
domctl or sysctl interfaces. Thus I have named the extra structs
v2d5 or v2s3 to indicated hypercall version 2, domctl version 5
or hypercall version 2, sysctl version 3 respectively.
- The 'flags' field in the getdomaininfo hypercall now has an extra flag
defined '(1<<1)' which was previously not used, is now used to indicate
that the guest is HVM. Thus when fetching domain state, we have to mask
out that flag, otherwise we'll never match the correct paused/running/
blocked/etc states.
- In the xenHypervisorNumOfDomains method, under certain scenarios we
will re-try the hypercall, allocating a bigger memory buffer. Well
due to the ABI alignment changes we hit that scenario everytime, and
ended up allocating a multi-GB buffer :-) The fixed structs sort this
out, but as a preventative measure for any future HV changes the patch
will break out of the loop at the 10,000 guest mark to avoid allocating
GB of memory.
- The unified Xen driver broke the GetVCPUs method - it was mistakenly
checking for return value == 0, instead of > 0. Trivial fix.
- The method to open the XenD connection was calling xenDaemonGetVersion
to test if the connection succeeded. But then also calling the
xend_detect_config_version which does pretty much same thing. So I
removed the former, and now we only do the latter as a 'ping' test
when opening. This removes 1 HTTP GET which is worthwhile performance
boost given how horrifically slow XenD is.
- The HVM SEXPR for configuring the VNC / SDL graphics is no longere
part of the (image) block. it now matches the PVFB graphics config
and is an explicit (vfb) block within the (devices) block.
So if xend_config_format >= 4 we use the new style config - this
is assuming upstream XenD is patched to increment xend_config_format
from 3 to 4 - I send a patch & am confident it will be applied
very shortly.
- The QEMU device model allows a user to specify multiple devices
for the boot order, eg 'andc' to indicated 'floppy', 'network'
'cdrom', 'disk'. We assumed it was a single letter only. I now
serialize this into multiple <boot dev='XXX'/> elements, ordered
according to priority. The XML -> SEXPR conversion allows the
same.
I've tested all this on a 32-bit Dom0 running on 32-bit HV, and 64-bit HV,
but not tested a 64-bit Dom0 on 64-bit HV. I'm pretty sure it'll work,but
if anyone is runnning 64-on-64 please test this patch.
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
17 years, 1 month
[Libvir] [PATCH][RFC] shows scheduler information
by Atsushi SAKAI
Hi,
This patch intends add a showing function of scheduler information.
If apply this patch to current revision 1.490
and type virsh dominfo 0
then shows following scheduler information.
Currently I assume credit scheduler only.
getting function is implemented but setting function is not yet.
I just waiting for comments.
Id: 0
Name: Domain-0
UUID: 00000000-0000-0000-0000-000000000000
OS Type: linux
State: running
CPU(s): 1
CPU time: 432.7s
Max memory: no limit
Used memory: 1933312 kB
scheduler info 5 256 0
SchedulerID: 5
Weight: 256
Cap: 0
Thanks
Atsushi SAKAI
17 years, 1 month
[Libvir] [PATCH] Check ReadOnly-flag
by S.Sakamoto
Hi
When a general user uses command "# virsh --connect xen start domain",
don't become an error, and domain start.
Because ReadOnly-flag is not "1" when a general user uses it.
So, here's the patch adds to check ReadOnly-flag.
Signed-off-by: Shigeki Sakamoto <fj0588di(a)aa.jp.fujitsu.com>
Thanks,
Shigeki Sakamoto.
Index: src/libvirt.c
===================================================================
RCS file: /data/cvs/libvirt/src/libvirt.c,v
retrieving revision 1.66
diff -u -p -r1.66 libvirt.c
--- src/libvirt.c 4 Apr 2007 14:19:49 -0000 1.66
+++ src/libvirt.c 12 Apr 2007 07:55:32 -0000
@@ -301,6 +301,10 @@ do_open (const char *name, int flags)
break;
}
}
+
+ if (flags & VIR_DRV_OPEN_RO) {
+ ret->flags = VIR_CONNECT_RO;
+ }
return ret;
17 years, 1 month
[Libvir] [Q] about virsh-connect
by S.Sakamoto
Hi,
I have a question.
Previously(libvirt 0.2.1) We can do remote connection via URI successfully..
(virsh --connect http://127.0.0.1:8000 list)
But Current version(libvirt-current) cannot connect remotely.
This event occurs in both general user and administrator.
I investigate the code and found folloing code is included (see line 94)
If "name" is not "xen", decline connection.
("# virsh --help connect" is output with "<name> hypervisor connection URI")
Is this change intentionally?
xen_unified.c
===========================================================
84| static int
85| xenUnifiedOpen (virConnectPtr conn, const char *name, int flags)
86| {
87| int i, j;
88| xenUnifiedPrivatePtr priv;
89|
90| /* If name == NULL, name == "", or begins with "xen", then it's for us. /
91| if (!name || name[0] == '\0')
92| name = "xen";
93| if (strncasecmp (name, "xen", 3) != 0)
94| return VIR_DRV_OPEN_DECLINED;
===========================================================
Thanks,
Shigeki Sakamoto.
17 years, 1 month
[Libvir] [PATCH] virsh dumpxml and create fails with no UNAME cdrom device
by Nobuhiro Itou
Hi,
In the xmexample.hvm(/etc/xen/xmexample.hvm), no UNAME cdrom device is written.
disk = [ 'file:/var/images/min-el3-i386.img,hda,w', ',hdc:cdrom,r' ]
But virsh dumpxml fails if the domain has virtual cdrom device without UNAME.
And virsh create fails if the domain config XML has no UNAME cdrom device, too.
The attached patch adds to solve this problem.
Signed-off-by: Nobuhiro Itou <fj0873gn(a)aa.jp.fujitsu.com>
Thanks,
Nobuhiro Itou.
17 years, 1 month
[Libvir] RFC [0/3]: Re-factor QEMU daemon protocol to use XDR
by Daniel P. Berrange
I've been thinking about a way to move forward on the remote management
capabilities in libvirt since our last list discussion didn't come to any
clear agreement.
The current situation
- QEMUD daemon uses a hand-crafted protocol basically just dumping
structs on the wire. Key points:
- Fairly simple to understand code for marshalling/demarshalling
- Very low overhead on wire
- Not safe endianess
- Not safe wrt to architecture data alignment rules
- No authentication/encryption
- Server driver specific to QEMU
- The generic libvirt daemon uses SunRPC as the underlying protocol.
- Protocol versioning
- Safe wrt to endianess
- Safe wrt to architecture data alignment rules
- Added TLS encryption / SSH tunneling
- Generic for any libvirt backend
- Doesn't work with non-blocking sockets due to SunRPC limitations
- SunRPC api is not well known / 'wierd'
- Call + reply only; no async signals from server
Looking at the current impl of the generic libvirt daemon there are some
things which strike me:
1. We have an extra layer of marshalling/demarshalling calls. ie the methods
in the libvirt driver, call to the SunRPC marshalling methods, which
populate an XDR generated struct, which call the XDR routines to write
the data.
2. The main loop doesn't allow us to listen for other non-SunRPC file
handles (eg the QEMU/dnsmasq processes).
3. We've basically re-written the the SunRPC svc*_create methods to
get support for TLS / SSH
We are going to need to address 2 by creating our own mainloop impl. For
point 1 we can have the libvirt driver populate the XDR struct directly
and eliminate the SunRPC generated marshalling stubs completely. If we
did that, and given points 2 & 3, we're basically left using very little
of the SunRPC capabilities at all. Pretty much only thing it is doing for
us at that point is the protocol versioning, and giving us a horrific API
which doesn't support non-blocking IO so forces us to be multi-threads or
multi-process.
So, I'm thinking why don't we just use XDR directly & be done with it. As an
experiment I took the existing QEMU daemon & driver and re-factored the
hand written binary protocol to use XDR instead.
Looking at the diffstat - there was basically no appreciable difference
in codesize after the re-factoring, and we get the added benefit of being
endianness & alignment safe.
qemud/Makefile.am | 15 +
qemud/conf.c | 1
qemud/dispatch.c | 538 ++++++++++++++++------------------------------
qemud/dispatch.h | 2
qemud/internal.h | 21 +
qemud/protocol.h | 329 ----------------------------
qemud/protocol.x | 608 ++++++++++++++++++++++++++++++++++++++++++++++++++++
qemud/qemud.c | 189 +++++++++++-----
qemud/uuid.c | 1
src/Makefile.am | 11
src/internal.h | 2
src/qemu_internal.c | 593 ++++++++++++++++++++++++++------------------------
12 files changed, 1288 insertions(+), 1022 deletions(-)
The particular changes I'll explain in the next 3 mails where I attach the
patches.
Meanwhile though, I'm thinking we could take approach of incremental code
refactoring, pulling in all the various capabilities from the remote patch
(except for the SunRPC demarshalling itself) to the QEMU daemon. At each
stage having a working daemon & client but with ever growing capabilities,
until it provides full remote management.
1. Add an extra initial message type to do a major/minor version number
exchange. Based on the negotiated versions, the server can activate
or deactivate particular requests it allows from the client.
2. Add in the URI parsing routines to the qemud_interal.c driver, but
only allow use of QEMU initially.
3. Add in the TLS + SSH client & server socket setup code to give an
authenticated & secured remote channel
4. Re-factor qemud/dispatch.c so that it calls into the regular libvirt
API for the Xen case, but keeps calling qemud/driver.c for the QEMU
case.
BTW, these patches are not intended to be applied to CVS - they're for
discussion purposes at this stage. That said, they are fully functional
so you can apply them to your checkout & you should be able run all the
existing virsh commands against the libvirt_qemud. Just make sure you
patch & rebuild both the client & server ;-)
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
17 years, 1 month
