[Libvir] RFC: Supporting serial & parallel ports for QEMU (and improving Xen)
by Daniel P. Berrange
One user's feature request for our QEMU driver is to support serial ports.
Easy you might think... you'd be wrong :-)
On Xen we have very simple approach. When creating a guest simply add
<console/>
And it'll cause a serial port to be setup with an autoallocated pty, so
you get back
<console pty='/dev/pts/5'/>
In retrospect calling it 'console' was dumb, but hey we're stuck with that
now and its only a tiny naming issue so I don't mind really.
We can do the same thing with QEMU quite easily. QEMU, however, supports
many many many more ways to hooking up the serial port to Dom0. Indeed
so does Xen fullyvirt, but we don't expose this ability. Parallel ports
have identical config syntax to serial ports so we might as well deal
with both at once.
So, here's a stripped down version of the QEMU docs:
[quote http://fabrice.bellard.free.fr/qemu/qemu-doc.html#SEC10]
`-serial dev'
Redirect the virtual serial port to host character device dev. The
default device is vc in graphical mode and stdio in non graphical
mode. This option can be used several times to simulate up to 4
serials ports. Use -serial none to disable all serial ports.
Available character devices are:
vc
Virtual console
pty
[Linux only] Pseudo TTY (a new PTY is automatically allocated)
none
No device is allocated.
null
void device
/dev/XXX
[Linux only] Use host tty, e.g. `/dev/ttyS0'. The host serial port
parameters are set according to the emulated ones.
/dev/parportN
[Linux only, parallel port only] Use host parallel port N. Currently
only SPP parallel port features can be used.
file:filename
Write output to filename. No character can be read.
stdio
[Unix only] standard input/output
pipe:filename
name pipe filename
COMn
[Windows only] Use host serial port n
udp:[remote_host]:remote_port[@[src_ip]:src_port]
This implements UDP Net Console.
tcp:[host]:port[,server][,nowait][,nodelay]
The TCP Net Console has two modes of operation.
telnet:host:port[,server][,nowait][,nodelay]
The telnet protocol is used instead of raw tcp sockets.
unix:path[,server][,nowait]
A unix domain socket is used instead of a tcp socket.
[/quote]
I don't see any reason to not support all/most of these options. The things
I don't like here is that /dev/XXX, vs /dev/parportN, vs COMn differences
for connecting guest <-> host passthrough of the devices. I figure it could
be simpler if it was just represented as 'n' and we'd translate that to
be /dev/ttyS[n] or /dev/parport[n] or COM[n] as needed.
The question as ever is how to represent this in XML. For serial ports we'll
stick with '<console>', while parallel ports we might as well use a better
named '<parallel>'. Next up, I think should use a 'type' attribute on this
element to determine the main way ot connecting the device, and then more
type specific attributes or sub-elements as needed. If 'type' was not
specified then use a default of 'pty', since that gives compatability with
existing practice.
As an illustrative example
/*
* Parse the XML definition for a character device
*
* Top level node will be <console> or <parallel>, but all attributes
* and sub-elements are identical.
*
* type=vc|pty|null|host|file|pipe|udp|tcp|telnet, default is pty
*
* <console type='vc'/>
*
* <console type='pty' pty='/dev/pts/3'/>
*
* <console type='null'/>
*
* <console type='host' port='3'/>
*
* <console type='file' path='/some/file'/>
*
* <console type='pipe' path='/some/file'/>
*
* <console type='udp'>
* <sendto port='12356'/>
* </console>
*
* <console type='udp'>
* <sendto addr='127.0.0.1' port='12356'/>
* </console>
*
* <console type='udp'>
* <sendto addr='127.0.0.1' port='12356'/>
* <bind port='12356'/>
* </console>
*
* <console type='udp'>
* <sendto addr='127.0.0.1' port='12356'/>
* <bind addr='127.0.0.1' port='12356'/>
* </console>
*
* <console type='tcp'>
* <listen port='12356'/>
* </console>
*
* <console type='tcp'>
* <listen addr='127.0.0.1' port='12356'>
* <nowait/>
* <nodelay/>
* </listen>
* </console>
*
* <console type='tcp'>
* <connect addr='127.0.0.1' port='12356'>
* <nodelay/>
* </connect>
* </console>
*
* <console type='telnet'>
* <listen addr='127.0.0.1' port='12356'/>
* </console>
*
* <console type='telnet'>
* <connect addr='127.0.0.1' port='12356'/>
* </console>
*
*/
BTW, the udp, tcp, telnet options are only available on QEMU >= 0.9.0. We
already have ability to detect / validate that for both Xen & QEMU drivers.
NB, whereever there are IP addresses, hostnames can be used too, hence I
call the attriute 'addr' instead of 'ip'
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 -=|
16 years, 2 months
[Libvir] Extending libvirt to probe NUMA topology
by Ryan Harper
Hello all,
I wanted to start a discussion on how we might get libvirt to be able to
probe the NUMA topology of Xen and Linux (for QEMU/KVM). In Xen, I've
recently posted patches for exporting topology into the [1]physinfo
hypercall, as well adding a [2]hypercall to probe the Xen heap. I
believe the topology and memory info is already available in Linux.
With these, we have enough information to be able to write some simple
policy above libvirt that can create guests in a NUMA-aware fashion.
I'd like to suggest the following for discussion:
(1) A function to discover topology
(2) A function to check available memory
(3) Specifying which cpus to use prior to domain start
Thoughts?
1. http://lists.xensource.com/archives/html/xen-devel/2007-06/msg00298.html
2. http://lists.xensource.com/archives/html/xen-devel/2007-06/msg00299.html
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
ryanh(a)us.ibm.com
16 years, 8 months
[Libvir] virsh vcpupin does not work with xend
by Saori Fukuta
Hi,
The virsh vcpupin command does not work when it uses Xend(xend_internal.c).
HV(xen_internal.c) works fine.
I'm testing on Xen3.1.0(hypervisor_version=2, dom_interface_version=5,
xendConfigVersion=4), and using current libvirt(ChangeLog revision 1.546).
To solve this problem, I got the xend debug information and compared that.
* in the case of executing "virsh vcpupin 63 7 1" *
[2007-05-29 09:33:20 4258] DEBUG (XendDomain:1297) dom(63) cpu 7 cpumap [1](<type'str'>)
* in the case of executing "xm vcpu-pin 63 7 1" *
[2007-05-29 09:33:32 4258] DEBUG (XendDomain:1297) dom(63) cpu 7 cpumap [1](<type'list'>)
There is one different thing. The type of cpumap is str when executing virsh
command, but the type of cpumap is list when executing xm command.
Do you have any idea ?
Thanks,
Saori Fukuta
16 years, 10 months
[Libvir] [Q]Will virConnectNumOfNetworks and virConnectNumOfDefinedNetworks be supported by Xen ?
by S.Sakamoto
Hi,
When I use virt-manager that is connected by xen,
the following error is given at every monitoring.
libvir: Error : this function is not supported by the hypervisor: virConnectNumOfNetworks
libvir: Error : this function is not supported by the hypervisor: virConnectNumOfDefinedNetworks
Therefore I have a question.
Will virConnectNumOfNetworks and virConnectNumOfDefinedNetworks be supported by Xen ?
When is it if supported ?
Thanks,
Shigeki Sakamoto.
16 years, 10 months
Re: [Libvir] [RFC]OpenVZ XML def
by Richard W.M. Jones
Shuveb Hussain wrote:
>>
>> Daemon though? Can't the libvirt code just invoke the OpenVZ commands
>> directly?
>
> Yeah, that is very much possible. But if it were a daemon, it could be
> a Python daemon, since text processing is much simpler and I don't
> have to use the str*( ) funcs in C. What is your comment?
I'm a big advocate of using a sane language instead of C, but libvirt is
written in C for better or worse.
The problem with a separate daemon is management of that daemon.
Something needs to start it and stop it, it needs to have sockets with
the right permissions and so on. What happens if the process runs and
can't find the daemon? What is the path to the socket? etc. etc. At
the moment we have two daemons - the qemu daemon (which has two separate
functions intertwined), and a remote daemon (necessary, because there's
no other way to communicate to a remote machine).
One idea would be to have the Python code fork off from the main program
and communicate over a pipe. With this, there is no daemon management
problem.
+----------------+
| Program |
| - - - - - - - -|
| libvirt |
+----------------+
|
| fork(2) and pipe(2)
|
+-------------+
| Python code |
+-------------+
But I'm not the person who ultimately decides what would be acceptable
in libvirt. You'd need to get general agreement on the best way to do this.
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
16 years, 10 months
[Libvir] PATCH: Fix remote driver to handle network API for local non-QEMU
by Daniel P. Berrange
The remote_internal.c code is basically a no-op in its remoteNetworkOpen
method. This means the remote driver will only handle the networking
APIs, if it is also handling the main domain APIs. This works fine if
connecting to a remote URI, or if using QEMU URIs, but it does not work
if using the test or Xen drivers.
To make this work the remoteNetworkOpen method needs to open a connection
to the remote daemon IIF the remoteOpen method did not already open one.
So the attached patch adds the neccessary logic in remoteNetworkOpen. It
also adds code to remoteNetworkClose to make it shutdown& free the connection
IIF it was opened by the remoteNetworkOpen method. This is what the extra
'networkOnly' field in the 'struct private_data' is used to check.
Second, all of the implementations of virNetwork* APIs in the remote_internal.c
driver must use the 'struct private_data *' from networkPrivateData field
in virConnectPtr, not the 'privateData' field. This is because the 'privateData'
field is probably storing data related to the Xen or Test drivers.
Third, this also fixes the qemu_driver.c which incorrectly used the
privateData field insteadof the networkPrivateData field for 2 of the
networking APIs, and finally makes sure the qemu_driver.c also acccepts
the use of qemu:///session APIs for root user.
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 -=|
16 years, 10 months
[Libvir] [PATCH] Do check the UUID in __virGetDomain()
by Masayuki Sunou
Hi
This patch adds checking the UUID in __virGetDomain().
Now, the UUID of domain is wrong in the following operations.
1. Start virsh in interactive mode.
2. Execute domuuid to the domain
3. Execute undefine to the domain which executed domuuid in 2.
4. Create the domain whose name is same as the domain that executed undefine.
5. Execute domuuid for the new domain
This patch can fix it.
Signed-off-by: Masayuki Sunou <fj1826dm(a)aa.jp.fujitsu.com>
Thanks,
Masayuki Sunou.
--------------------------------------------------------------------------------
Index: src/hash.c
===================================================================
RCS file: /data/cvs/libvirt/src/hash.c,v
retrieving revision 1.22
diff -u -p -r1.22 hash.c
--- src/hash.c 8 May 2007 10:53:27 -0000 1.22
+++ src/hash.c 7 Jun 2007 02:08:41 -0000
@@ -758,8 +758,14 @@ __virGetDomain(virConnectPtr conn, const
ret = (virDomainPtr) virHashLookup(conn->domains, name);
if (ret != NULL) {
- /* TODO check the UUID */
- goto done;
+ if (memcmp(ret->uuid, uuid, 16)) {
+ if (virFreeDomain(conn, ret, 0) < 0) {
+ xmlMutexUnlock(conn->hashes_mux);
+ return(NULL);
+ }
+ } else {
+ goto done;
+ }
}
/*
@@ -813,7 +819,7 @@ error:
* Returns the reference count or -1 in case of failure.
*/
int
-virFreeDomain(virConnectPtr conn, virDomainPtr domain) {
+virFreeDomain(virConnectPtr conn, virDomainPtr domain, int lock) {
int ret = 0;
if ((!VIR_IS_CONNECT(conn)) || (!VIR_IS_CONNECTED_DOMAIN(domain)) ||
@@ -821,7 +827,8 @@ virFreeDomain(virConnectPtr conn, virDom
virHashError(conn, VIR_ERR_INVALID_ARG, __FUNCTION__);
return(-1);
}
- xmlMutexLock(conn->hashes_mux);
+ if (lock)
+ xmlMutexLock(conn->hashes_mux);
/*
* decrement the count for the domain
@@ -853,13 +860,14 @@ virFreeDomain(virConnectPtr conn, virDom
if (conn->domains != NULL)
virHashFree(conn->domains, (virHashDeallocator) virDomainFreeName);
- if (conn->hashes_mux != NULL)
+ if (conn->hashes_mux != NULL && lock)
xmlFreeMutex(conn->hashes_mux);
free(conn);
return(0);
done:
- xmlMutexUnlock(conn->hashes_mux);
+ if (lock)
+ xmlMutexUnlock(conn->hashes_mux);
return(ret);
}
Index: src/internal.h
===================================================================
RCS file: /data/cvs/libvirt/src/internal.h,v
retrieving revision 1.41
diff -u -p -r1.41 internal.h
--- src/internal.h 8 May 2007 10:53:27 -0000 1.41
+++ src/internal.h 7 Jun 2007 02:08:41 -0000
@@ -202,7 +202,7 @@ virDomainPtr __virGetDomain (virConnectP
const char *name,
const unsigned char *uuid);
int virFreeDomain (virConnectPtr conn,
- virDomainPtr domain);
+ virDomainPtr domain, int lock);
virDomainPtr virGetDomainByID(virConnectPtr conn,
int id);
virNetworkPtr __virGetNetwork (virConnectPtr conn,
Index: src/libvirt.c
===================================================================
RCS file: /data/cvs/libvirt/src/libvirt.c,v
retrieving revision 1.73
diff -u -p -r1.73 libvirt.c
--- src/libvirt.c 5 Jun 2007 12:06:08 -0000 1.73
+++ src/libvirt.c 7 Jun 2007 02:08:41 -0000
@@ -730,7 +730,7 @@ virDomainFree(virDomainPtr domain)
virLibDomainError(domain, VIR_ERR_INVALID_DOMAIN, __FUNCTION__);
return (-1);
}
- if (virFreeDomain(domain->conn, domain) < 0)
+ if (virFreeDomain(domain->conn, domain, 1) < 0)
return (-1);
return(0);
}
Index: src/qemu_internal.c
===================================================================
RCS file: /data/cvs/libvirt/src/qemu_internal.c,v
retrieving revision 1.25
diff -u -p -r1.25 qemu_internal.c
--- src/qemu_internal.c 5 Jun 2007 12:06:08 -0000 1.25
+++ src/qemu_internal.c 7 Jun 2007 02:08:42 -0000
@@ -906,7 +906,7 @@ static int qemuUndefine(virDomainPtr dom
}
cleanup:
- if (virFreeDomain(dom->conn, dom) < 0)
+ if (virFreeDomain(dom->conn, dom, 1) < 0)
ret = -1;
return ret;
Index: src/xend_internal.c
===================================================================
RCS file: /data/cvs/libvirt/src/xend_internal.c,v
retrieving revision 1.116
diff -u -p -r1.116 xend_internal.c
--- src/xend_internal.c 5 Jun 2007 12:06:09 -0000 1.116
+++ src/xend_internal.c 7 Jun 2007 02:08:42 -0000
@@ -1900,7 +1900,7 @@ error:
virXendError(conn, VIR_ERR_INTERNAL_ERROR,
_("failed to parse Xend domain information"));
if (ret != NULL)
- virFreeDomain(conn, ret);
+ virFreeDomain(conn, ret, 1);
return(NULL);
}
#endif /* !PROXY */
@@ -3055,7 +3055,7 @@ xenDaemonCreateLinux(virConnectPtr conn,
/* Make sure we don't leave a still-born domain around */
if (dom != NULL) {
xenDaemonDomainDestroy(dom);
- virFreeDomain(dom->conn, dom);
+ virFreeDomain(dom->conn, dom, 1);
}
if (name != NULL)
free(name);
16 years, 10 months
[Libvir] request for libvirt documentation improvement
by Philippe Berthault
The documentation of libvirt doesn't indicate which functions are for
Xen or QEMU or both. The only way to know that, is by searching in
libvirt sources.
It would be interesting for libvirt users to add in the documentation,
for each function, a mention such as "QEMU only", "Xen(TM) only", "QEMU
and Xen(TM)", etc..
Regards.
Libvirt 0.2.3 functions dedicated to QEMU only:
virConnectListDefinedNetworks
virConnectListNetworks
virConnectNumOfDefinedNetworks
virConnectNumOfNetworks
virDomainGetAutostart
virDomainSetAutostart
virNetworkCreate
virNetworkCreateXML
virNetworkDefineXML
virNetworkDestroy
virNetworkFree
virNetworkGetAutostart
virNetworkGetBridgeName
virNetworkGetName
virNetworkGetUUID
virNetworkGetUUIDString
virNetworkGetXMLDesc
virNetworkLookupByName
virNetworkLookupByUUID
virNetworkLookupByUUIDString
virNetworkSetAutostart
virNetworkUndefine
Libvirt 0.2.3 functions dedicated to Xen(TM) only:
virConnectGetMaxVcpus
virConnectGetType
virDomainAttachDevice
virDomainCoreDump
virDomainDetachDevice
virDomainGetMaxMemory
virDomainGetSchedulerParameters
virDomainGetSchedulerType
virDomainPinVcpu
virDomainReboot
virDomainSetMaxMemory
virDomainSetMemory
virDomainSetSchedulerParameters
virDomainSetVcpus
16 years, 10 months
