[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, 9 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
17 years, 4 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
17 years, 4 months
[Libvir] [RFC] Device attach/detach on virsh
by Masayuki Sunou
I want to add I/F to do attach/detatch of VIF and VBD to virsh with
virDomainAttachDevice()/virDomainDetachDevice().
And, I have two proposals about I/F for virsh to do attach/detach of VIF and VBD.
proposal 1:
Virsh catches MAC, bridge name, device name (physical,virtual), and another
by the command option.
ex)
------------------------------------------------------------------
# virsh help attach(detach)-vif(vbd)
NAME
attach(detach)-vif(vbd) - attach(detach) vif(vbd)
SYNOPSIS
* VIF
attach(detach)-vif <domain> <MAC> <bridge> ...
or
* VBD
attach(detach)-vbd <domain> <virt-dev> ...
DESCRIPTION
Attach(Detach) vif(vbd) device
OPTIONS
<domain> domain name, id or uuid
* VIF
<MAC> MAC address of vif
<bridge> bridge name of vif
...
* VBD
<virt-dev> virtual device name of vbd
<phy-dev> physical device name of vbd
...
------------------------------------------------------------------
<advantage>
- I/F is easy to use than proposal 1. (Because the user does not have to
make XML)
<disadvantage>
- I/F increases because I/F of VIF and VBD becomes separate. (So, the
addition of I/F is necessary at any time for supporting devices other
than VIF and VBD. )
- Handling of optional analysis, handling of XML making are necessary
in virsh.c, and processing becomes complicated.
proposal 2:
virsh catches a definition of a device by XML
ex)
------------------------------------------------------------------
# virsh help attach(detach)-device
NAME
attach(detach)-device - attach(detach) device from an XML file
SYNOPSIS
attach(detach)-device <domain> <file>
DESCRIPTION
Attach(Detach) device from an XML <file>
OPTIONS
<domain> domain name, id or uuid
<file> XML file of device description
------------------------------------------------------------------
<advantage>
- I/F is unified without affecting a device type. (I/F is simple)
- Handling of virsh.c is simple. (Optional analysis is not necessary)
<disadvantage>
- The user has to describe XML.(It is troublesome)
I think that specifications that a user is easy to use (proposal 1)
are better.
Please, give me an opinion which proposal is better.
Thanks,
Masayuki Sunou
17 years, 5 months
[Libvir] Storage manager initial requirements and thoughts
by Hugh Brock
Hi all.
At the Red Hat virtualization team meeting last week we spent some time
talking about the problem of remote storage management, which is a
requirement for at the very least creating remote guests. Remote storage
management also delivers a lot of benefits for managing guest storage,
provisioning, and a host of other issues.
Note that we don't (I think) believe that storage management should be
part of libvirt. However we might want to be able to grab storage
information with libvirt when creating a guest, for example.
Here's the tentative requirements we came up with, along with several
questions that came up.
We have two important use cases for remote storage management:
--Create a new guest against an existing physical device
--Create a new guest against a file on an existing physical device
(SELinux context must match up on both)
Requirements:
2 key requirements: enumerate devices, create files
* Enumerate devices (unallocated disks)
* storage pool
* Unallocated space
* Allocated volumes
-- free
-- in use
* Read only / Read-write
* Host availability
* Volume
-- Global unique name
-- Local device name
-- Usage
-- Mounted locally
-- Assigned to guest
read only
shared
exclusive
-- Inactive guest
* Create a backing store for a guest
* need to know what storage is available
* Can be plain file
* Can be a physical partition (local scsi/IDE, SAN)
* Can be a logical volume
* Can be network - iscsi/nbd
Cases:
Physical device
--> create partitions
Volume group
--> create logical volumes
Directory
--> create files
Todos:
Investigate gparted, one of the partition management tools we already
have (apis? remote accessibility?) (I believe Jim Meyering volunteered
to take a look at this?)
Identify what other scenarios we need to address.
Please comment; I'm hoping we can get these into a more definite form
sooner rather than later.
--
Red Hat Virtualization Group http://redhat.com/virtualization
Hugh Brock | virt-manager http://virt-manager.org
hbrock(a)redhat.com | virtualization library http://libvirt.org
17 years, 5 months
[Libvir] [PATCH] output virsh log to file
by Nobuhiro Itou
Hi,
I made the patch which output debug messages and error messages
of virsh to the log file.
I think that it is necessary to leave logs to the file for the
investigation at the failure.
Debug messages can take appointed optional information,
and error messages will make it easy to specify a cause.
Moreover, I'm thinking about outputting virterror information
to the virsh log file by the next step.
It is simple specifications as follows.
* Destination -- <USER HOME>/.virsh/virsh.log
* Log size -- 1MB(1024*1024)
* Number of Rotations -- 5
* There is process exclusion.
First, will you take in this patch ?
And, I have a plan to enhance logging functionality.
(for example, libvirt error logging)
Signed-off-by: Nobuhiro Itou <fj0873gn(a)aa.jp.fujitsu.com>
Thanks,
Nobuhiro Itou.
17 years, 5 months
[Libvir] [PATCH] Cut out "type=ioemu" on Xen3.1
by Saori Fukuta
Hi,
The definition of (type ioemu) is *not* required by Xen3.1.
So I cut out it when xendConfigVersion is 4 or later.
Signed-off-by: Saori Fukuta <fukuta.saori(a)jp.fujitsu.com>
Thanks,
Saori Fukuta.
Index: xml.c
===================================================================
RCS file: /data/cvs/libvirt/src/xml.c,v
retrieving revision 1.73
diff -u -p -r1.73 xml.c
--- xml.c 23 Apr 2007 07:41:23 -0000 1.73
+++ xml.c 31 May 2007 07:02:01 -0000
@@ -1047,6 +1047,7 @@ virDomainParseXMLDiskDesc(virConnectPtr
* @conn: pointer to the hypervisor connection
* @node: node containing the interface description
* @buf: a buffer for the result S-Expr
+ * @xendConfigVersion: xend configuration file format
*
* Parse the one interface the XML description and add it to the S-Expr in buf
* This is a temporary interface as the S-Expr interface
@@ -1056,7 +1057,7 @@ virDomainParseXMLDiskDesc(virConnectPtr
* Returns 0 in case of success, -1 in case of error.
*/
static int
-virDomainParseXMLIfDesc(virConnectPtr conn ATTRIBUTE_UNUSED, xmlNodePtr node, virBufferPtr buf, int hvm)
+virDomainParseXMLIfDesc(virConnectPtr conn ATTRIBUTE_UNUSED, xmlNodePtr node, virBufferPtr buf, int hvm, int xendConfigVersion)
{
xmlNodePtr cur;
xmlChar *type = NULL;
@@ -1129,7 +1130,8 @@ virDomainParseXMLIfDesc(virConnectPtr co
virBufferVSprintf(buf, "(script '%s')", script);
if (ip != NULL)
virBufferVSprintf(buf, "(ip '%s')", ip);
- if (hvm)
+ /* HVM type ioemu config for xen < 3.1 */
+ if (hvm && xendConfigVersion < 4)
virBufferAdd(buf, "(type ioemu)", 12);
virBufferAdd(buf, ")", 1);
@@ -1335,7 +1337,7 @@ virDomainParseXMLDesc(virConnectPtr conn
if (nb_nodes > 0) {
for (i = 0; i < nb_nodes; i++) {
virBufferAdd(&buf, "(device ", 8);
- res = virDomainParseXMLIfDesc(conn, nodes[i], &buf, hvm);
+ res = virDomainParseXMLIfDesc(conn, nodes[i], &buf, hvm, xendConfigVersion);
if (res != 0) {
free(nodes);
goto error;
@@ -1494,7 +1496,7 @@ virParseXMLDevice(virConnectPtr conn, ch
goto error;
}
else if (xmlStrEqual(node->name, BAD_CAST "interface")) {
- if (virDomainParseXMLIfDesc(conn, node, &buf, hvm) != 0)
+ if (virDomainParseXMLIfDesc(conn, node, &buf, hvm, xendConfigVersion) != 0)
goto error;
}
cleanup:
17 years, 5 months
Re: [Libvir] [PATCH] add scheduler API(take 3?)
by Richard W.M. Jones
+char *
+virDomainGetSchedulerType(virDomainPtr domain, int *nparams)
+{
+ virConnectPtr conn;
+ char *schedtype;
+
+ if (domain == NULL) {
+ TODO
+ return NULL;
+ }
Is this case an error, or were you thinking of adding more semantics
later on here?
(and the same comment for virDomainGet/SetSchedulerParameters)
+static int
+cmdSchedinfo(vshControl * ctl, vshCmd * cmd)
+{
[...]
+ char *str_weight = strdup("weight");
+ char *str_cap = strdup("cap");
+
+ nparams = malloc(sizeof(int));
+ *nparams = 0;
+
+ if (!vshConnectionUsability(ctl, ctl->conn, TRUE))
+ return FALSE;
There's still a problem memory leak here.
+ /* Currently supports Xen Credit only */
+ weight = vshCommandOptInt(cmd, "weight", &weightfound);
+ if(weightfound){ inputparam++; }
+
+ cap = vshCommandOptInt(cmd, "cap", &capfound);
+ if(capfound){ inputparam++; }
and can this be made so it isn't Xen-specific?
+ if ((domain == NULL) || (domain->conn == NULL))
+ return -1;
+
+ priv = (xenUnifiedPrivatePtr) domain->conn->privateData;
+ if (priv->handle < 0 || domain->id < 0)
+ return -1;
At the lowest level, these functions should return error messages back
to the upper layers. Otherwise users have nothing to diagnose errors with.
+ /*
+ * Support only dom_interface_version >=5
+ * (Xen3.1.0 or later)
+ */
+ if (dom_interface_version < 5)
+ return -1;
Is this because earlier hypervisors didn't support this, or is it just
not implemented?
Rich.
17 years, 5 months
[Libvir] [PATCH] Fix strange error message in virsh attach-device
by Masayuki Sunou
Hi
Now, virsh attach-device displays the following messages when "device"
attribute of "disk" element is "floppy" in XML.
# virsh attach-device HVM_RH4_file floppy.xml
libvir: Xen Daemon error : POST operation failed: (xend.err 'Invalid Configuration: XendConfig: @\x14\xce not a valid device type')
error: Failed to attach device from floppy.xml
This patch fixes this strange error message displaying "@\x14\xce".
Description of this patch
VirDomainParseXMLDiskDesc() returns 0 without putting data in virBuffer,
when "floppy" is set.
Therefore, virParseXMLDevice() returns no initialized data, and
xenDaemonAttachDevice() passes Xen this data.
Because virDomainParseXMLDesc() works wrong when this patch changes
return value of VirDomainParseXMLDiskDesc(),this patch fixes
virParseXMLDevice() as follows.
- Initialize data
- Return error if data does not change.
As a result, xenDaemonAttachDevice() doesn't pass strange data to Xen,
and Xen doesn't return strange error message.
Signed-off-by: Masayuki Sunou <fj1826dm(a)aa.jp.fujitsu.com>
Thanks,
Masayuki Sunou.
----------------------------------------------------------------------
Index: src/xml.c
===================================================================
RCS file: /data/cvs/libvirt/src/xml.c,v
retrieving revision 1.73
diff -u -p -r1.73 xml.c
--- src/xml.c 23 Apr 2007 07:41:23 -0000 1.73
+++ src/xml.c 25 May 2007 09:46:56 -0000
@@ -1481,6 +1481,7 @@ virParseXMLDevice(virConnectPtr conn, ch
return (NULL);
buf.size = 1000;
buf.use = 0;
+ memset(buf.content, 0, (size_t)buf.size);
xml = xmlReadDoc((const xmlChar *) xmldesc, "domain.xml", NULL,
XML_PARSE_NOENT | XML_PARSE_NONET |
XML_PARSE_NOERROR | XML_PARSE_NOWARNING);
@@ -1492,6 +1493,9 @@ virParseXMLDevice(virConnectPtr conn, ch
if (xmlStrEqual(node->name, BAD_CAST "disk")) {
if (virDomainParseXMLDiskDesc(conn, node, &buf, hvm, xendConfigVersion) != 0)
goto error;
+ /* SXP is not created when device is "floppy". */
+ else if (!strlen(buf.content))
+ goto error;
}
else if (xmlStrEqual(node->name, BAD_CAST "interface")) {
if (virDomainParseXMLIfDesc(conn, node, &buf, hvm) != 0)
----------------------------------------------------------------------
17 years, 5 months
[Libvir] cannot use vncviewer and VMM graphics console to access HVM guest on RHES 5
by Glen Deem
Hi all,
I've created an HVM guest under RHES 5 (Xen 3.0.3) using "xm create"
but I cannot access it with vncviewer.
The Virtual Machine Manager also informs about graphics console unavailability.
What am I doing wrong, please?
I do
> vncviewer 123.456.789.123:4,
where 4 is the guest id.
This is the xm config file is:
name = "hvmGuest"
builder = "hvm"
memory = "500"
disk = [ 'file:/var/lib/red-hat.img,hda,w', ]
vif = [ 'type=ioemu, mac=00:16:3e:34:3b:ba, bridge=xenbr0', ]
device_model = "/usr/lib/xen/bin/qemu-dm"
kernel = "/usr/lib/xen/boot/hvmloader"
vnc=1
vncunused=1
apic=1
acpi=1
pae=1
vcpus=1
serial = "pty"
on_reboot = 'restart'
on_crash = 'restart'
Thanks a lot in advance.
Glen from Ottawa, Canada
17 years, 5 months
