Re: [libvirt] virsh console giving Error
by Amit Tewari
Hi,
I added this (in /etc/grub.conf)
----
console=tty0 console=ttyS0,115200
-----
But still same error is coming.
-----Original Message-----
From: libvir-list-bounces(a)redhat.com
[mailto:libvir-list-bounces@redhat.com] On Behalf Of Amit Tewari
Sent: Monday, December 12, 2011 12:36 PM
To: Kashyap Chamarthy
Cc: libvir-list(a)redhat.com
Subject: Re: [libvirt] virsh console giving Error
Hi,
I am using libvirt 0.9.7
-----Original Message-----
From: Kashyap Chamarthy [mailto:kchamart@redhat.com]
Sent: Monday, December 12, 2011 12:32 PM
To: Amit Tewari
Cc: libvir-list(a)redhat.com
Subject: Re: [libvirt] virsh console giving Error
On 12/12/2011 12:16 PM, Amit Tewari wrote:
> Hi all,
>
> Following is my test environment
>
> Host os= rhel6.1
>
> Guest os=rhel6.1
>
> Hypervisor - kvm
>
>
>
> I have a created a guest machine using virt-install command. And it
has created guest
> successfully.
>
> But now when I issue following command
>
> #virsh console guest
>
>
>
> Following error is displayed -
>
>
>
> "Error: internal error character device (null) is not using a PTY"
>
>
>
> Please let me no how can I avoid this error.
You have not specified what distribution, version of libvirt are you
using.
First, can you ensure if you have serial console set up in your guest by
checking if you
have the below directives in your guest kernel's command line options
(in /etc/grub.conf)
----
console=tty0 console=ttyS0,115200
----
If not, you can add it by running the below (ensure the guest is
shut-off):
# virt-edit guest /etc/grub.conf
'virt-edit' tool comes with libguestfs-tools-c package.
--
/kashyap
>
>
>
> Regards
>
> Amit Tewari
>
>
>
> --
> libvir-list mailing list
> libvir-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
DISCLAIMER:
------------------------------------------------------------------------
-----------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and
intended
for the named recipient(s) only.
It shall not attach any liability on the originator or NECHCL or its
affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily
reflect the
opinions of NECHCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure,
modification,
distribution and / or publication of
this message without the prior written consent of the author of this
e-mail is
strictly prohibited. If you have
received this email in error please delete it and notify the sender
immediately. .
------------------------------------------------------------------------
-----------------------------------------------
--
libvir-list mailing list
libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and
intended
for the named recipient(s) only.
It shall not attach any liability on the originator or NECHCL or its
affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect the
opinions of NECHCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of
this message without the prior written consent of the author of this e-mail is
strictly prohibited. If you have
received this email in error please delete it and notify the sender
immediately. .
-----------------------------------------------------------------------------------------------------------------------
13 years, 4 months
[libvirt] virsh console giving Error
by Amit Tewari
Hi all,
Following is my test environment
Host os= rhel6.1
Guest os=rhel6.1
Hypervisor - kvm
I have a created a guest machine using virt-install command. And it has
created guest successfully.
But now when I issue following command
#virsh console guest
Following error is displayed -
"Error: internal error character device (null) is not using a PTY"
Please let me no how can I avoid this error.
Regards
Amit Tewari
DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and
intended
for the named recipient(s) only.
It shall not attach any liability on the originator or NECHCL or its
affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect the
opinions of NECHCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of
this message without the prior written consent of the author of this e-mail is
strictly prohibited. If you have
received this email in error please delete it and notify the sender
immediately. .
-----------------------------------------------------------------------------------------------------------------------
13 years, 4 months
[libvirt] Virtio Balloon Dynamic behaviour ??
by Pankaj Rawat
Hi all,
I want to be clear in details regarding Virtio balloon Driver in RHEL
6.1 KVM hypervisor
In documentations it is written that Virtio balloon driver allow the
guest to expand its memory dynamically .
Now I want to know the meaning of dynamically ...
Whether it means
1) We can change the memory of guest using libvirt API only i.e by
using virsh setmem command at runtime (VERIFIED)
2) Or the guest itself can check that it is running out of memory
so it request host for some memory and when the host respond by giving
back memory it expands its memory size. Which is automation
The 1st option is working fine
Now can anyone tell me that memory expantion can be done
dynamically(point 2) also
DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and
intended
for the named recipient(s) only.
It shall not attach any liability on the originator or NECHCL or its
affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect the
opinions of NECHCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of
this message without the prior written consent of the author of this e-mail is
strictly prohibited. If you have
received this email in error please delete it and notify the sender
immediately. .
-----------------------------------------------------------------------------------------------------------------------
13 years, 4 months
[libvirt] [test-API][PATCH] Add test case get_cpu_shares.py for cpu scheduler info testing
by Nan Zhang
* repos/domain/get_cpu_shares.py: get the value of cpu_shares
property of the guest.
---
lib/domainAPI.py | 2 +-
repos/domain/get_cpu_shares.py | 109 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 110 insertions(+), 1 deletions(-)
create mode 100644 repos/domain/get_cpu_shares.py
diff --git a/lib/domainAPI.py b/lib/domainAPI.py
index a6efab7..0058254 100644
--- a/lib/domainAPI.py
+++ b/lib/domainAPI.py
@@ -546,7 +546,7 @@ class DomainAPI(object):
def set_sched_params_flags(self, domname, params, flags):
try:
dom_obj = self.get_domain_by_name(domname)
- retval = dom_obj.setSchedulerParameters(params, flags)
+ retval = dom_obj.setSchedulerParametersFlags(params, flags)
return retval
except libvirt.libvirtError, e:
message = e.get_error_message()
diff --git a/repos/domain/get_cpu_shares.py b/repos/domain/get_cpu_shares.py
new file mode 100644
index 0000000..be7e649
--- /dev/null
+++ b/repos/domain/get_cpu_shares.py
@@ -0,0 +1,109 @@
+#!/usr/bin/env python
+"""Get the value of cpu_shares property of the guest
+ domain:get_cpu_shares
+ guestname
+ xxx
+ flags
+ 0|1|2
+"""
+
+__author__ = 'Nan Zhang: nzhang(a)redhat.com'
+__date__ = 'Tue Sep 27, 2011'
+__version__ = '0.1.0'
+__credits__ = 'Copyright (C) 2011 Red Hat, Inc.'
+__all__ = ['check_params', 'check_cpu_shares', 'get_cpu_shares']
+
+import os
+import re
+import sys
+import time
+from xml.dom import minidom
+
+
+def append_path(path):
+ """Append root path of package"""
+ if path in sys.path:
+ pass
+ else:
+ sys.path.append(path)
+
+pwd = os.getcwd()
+result = re.search('(.*)libvirt-test-API', pwd)
+append_path(result.group(0))
+
+from lib import connectAPI
+from lib import domainAPI
+from utils.Python import utils
+from utils.Python import xmlbuilder
+from exception import LibvirtAPI
+
+def check_params(params):
+ """Verify inputing parameter dictionary"""
+ logger = params['logger']
+ keys = ['guestname', 'flags']
+ for key in keys:
+ if key not in params:
+ logger.error("%s is required" %key)
+ return 1
+ return 0
+
+def check_cpu_shares(params, util, guestname, cpu_shares):
+ """Check the value of cpu_shares"""
+ logger = params['logger']
+ cmd = "cat /cgroup/cpu/libvirt/qemu/%s/cpu.shares" % guestname
+ ret, out = util.exec_cmd(cmd, shell=True)
+ if ret:
+ logger.error("fail to get the value of cpu_shares: %s" % out[0])
+ return 0
+ else:
+ logger.info("the value of cpu_shares: %s (getting from cgroup)" % out[0])
+
+ if cmp(int(out[0]), cpu_shares):
+ return 1
+ else:
+ logger.info("the value of cpu_shares does match the original \
+cpu scheduler information.")
+ return 0
+
+def get_cpu_shares(params):
+ """Get the cpu scheduler information"""
+ # Initiate and check parameters
+ params_check_result = check_params(params)
+ if params_check_result:
+ return 1
+ logger = params['logger']
+ guestname = params['guestname']
+ flags = params['flags']
+
+ # Connect to local hypervisor connection URI
+ util = utils.Utils()
+ uri = util.get_uri('127.0.0.1')
+ conn = connectAPI.ConnectAPI()
+ virconn = conn.open(uri)
+
+ caps = conn.get_caps()
+ logger.debug(caps)
+
+ domobj = domainAPI.DomainAPI(virconn)
+ try:
+ sched_info = domobj.get_sched_params_flags(guestname, int(flags))
+ cpu_shares = sched_info['cpu_shares']
+ logger.debug("the value of cpu_shares is %s" % cpu_shares)
+ except LibvirtAPI, e:
+ logger.error("API error message: %s, error code is %s" %
+ (e.response()['message'], e.response()['code']))
+ return 1
+
+ check_result = check_cpu_shares(params, util, guestname, cpu_shares)
+ if check_result:
+ logger.error("cpu_shares does not match.")
+ conn.close()
+ return 1
+
+ logger.info("success to get scheduler parameters.")
+ conn.close()
+ return 0
+
+def get_cpu_shares_clean():
+ """Clean testing environment"""
+ pass
--
1.7.4.4
13 years, 4 months
[libvirt] [PATCH 1/6] Allow network model to contain "-"
by Michael Ellerman
From: Michael Ellerman <michael(a)ellerman.id.au>
In QEMU PPC64 we have a network device called "spapr-vlan". We can specify
this using the existing syntax for network devices, however libvirt
currently rejects "spapr-vlan" in virDomainNetDefParseXML() because of
the "-". Fix the code to accept "-".
Signed-off-by: Michael Ellerman <michael(a)ellerman.id.au>
---
src/conf/domain_conf.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 75e51a0..5de33b9 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -3703,8 +3703,7 @@ virDomainNetDefParseXML(virCapsPtr caps,
if (model != NULL) {
int i;
for (i = 0 ; i < strlen(model) ; i++) {
- int char_ok = c_isalnum(model[i]) || model[i] == '_';
- if (!char_ok) {
+ if (!c_isalnum(model[i]) && model[i] != '_' && model[i] != '-') {
virDomainReportError(VIR_ERR_INVALID_ARG, "%s",
_("Model name contains invalid characters"));
goto error;
--
1.7.7.3
13 years, 4 months
[libvirt] (no subject)
by Osier Yang
Hi, all
This is a basic implementation of libvirt Native Linux KVM
Tool driver. Note that this is just made with my own interest
and spare time, it's not an endorsement/effort by Red Hat,
and it isn't supported by Red Hat officially.
Basically, the driver is designed as *stateful*, as KVM tool
doesn't maintain any info about the guest except a socket which
for its own IPC. And it's implemented by using KVM tool binary,
which is name "kvm" currently, along with cgroup controllers
"cpuacct", and "memory" support. And as one of KVM tool's
pricinple is to allow both the non-root and root user to play with.
The driver is designed to support root and non-root too, just
like QEMU does. Example of the connection URI:
virsh -c kvmtool:///system
virsh -c kvmtool:///session
virsh -c kvmtool+unix:///system
virsh -c kvmtool+unix:///session
The implementation can support more or less than 15 virsh commands
currently, including basic domain cycle operations (define/undefine,
start/destroy, suspend/resume, console, setmem, schedinfo, dumpxml,
,autostart, dominfo, etc.)
About the domain configuration:
* "kernel": must be specified as KVM tool only support boots
from the kernel currently (no integration with BIOS app yet).
* "disk": only virtio bus is supported, and device type must be 'disk'.
* "serial/console": only one console is supported, of type serial or
virtio (can extend to support multiple console as long as kvm tool
supports, libvirt already supported mutiple console, see upstream
commit 0873b688c).
* "p9fs": only support specifying the source dir, and mount tag, only
type of 'mount' is supported.
* "memballoon": only virtio is supported, and there is no way
to config the addr.
* Multiple "disk" and "p9fs" is supported.
* Graphics and network are not supported, will explain below.
Please see "[PATCH 7/8]" for an example of the domain config. (which
contains all the XMLs supported by current implementation).
The problems of Native Linux KVM Tool from libvirt p.o.v:
* Some destros package "qemu-kvm" as "kvm", also "kvm" is a long
established name for "KVM" itself, so naming the project as
"kvm" might be not a good idea. I assume it will be named
as "kvmtool" in this implementation, never mind this if you
don't like that, it can be updated easily. :-)
* It still doesn't have an official package yet, even no "make install".
means we have no way to check the dependancy and do the checking
when 'configure'. I assume it will be installed as "/usr/bin/kvmtool"
in this implementation. This is the main reason which can prevents
upstream libvirt accepting the patches I guess.
* Lacks of options for user's configuration, such as "-vnc", there
is no option for user to configure the properties for the "vnc",
such as the port. It hides things, doesn't provide ways to query
the properties too, this causes problems for libvirt to add the
vnc support, as vnc clients such as virt-manager, virt-viewer,
have no way to connect the guest. Even vncviewer can't.
* KVM tool manages the network completely itself (with DHCP support?),
no way to configure, except specify the modes (user|tap|none). I
have not test it yet, but it should need explicit script to setup
the network rules(e.g. NAT) for the guest access outside world.
Anyway, there is no way for libvirt to control the guest network.
* There is a gap about the domain status between KVM tool and libvirt,
it's caused by KVM tool unlink()s the guest socket when user exits
from console (both text and graphic), but libvirt still think the
guest is running.
* KVM tool uses $HOME/.kvm_tool as the state dir, and no way to configure,
I made a small patch to allow KVM tool accept a ENV variable,
which is "KVM_STATE_DIR", it's used across the driver. I made a
simple patch against kvm tool to let the whole patches work. See
"[PATCH] kvm tools.....". As generally we want the state dir of
a driver can be "/var/run/libvirt/kvmtool/..." for root user or
"$HOME/.libvirt/kvmtool/run" for non-root user.
* kvmtoolGetVersion is just broken now, as what "./kvm version" returns
is something like "3.0.rc5.873.gb73216", however, libvirt wants things
like "2.6.40.6-0". This might be not a problem as long as KVM tool
has a official package.
* console connection is implemented by setup ptys in libvirt, stdout/stderr
of kvm tool process is redirected to the master pty, and libvirt connects
to the slave pty. This works fine now, but it might be better if kvm
tool could provide more advanced console mechanisms. Just like QEMU
does?
* Not much ways existed yet for external apps or user to query the guest
informations. But this might be changed soon per KVM tool grows up
quickly.
* It will be quite desireable if kvm tool could report the capabilities,
of which is lacked by QEMU forever (seems so), it causes much pain for
upper layer mgmt apps. See the RFC by Daniel Berrange in QEMU list
for more details:
http://lists.nongnu.org/archive/html/qemu-devel/2010-06/msg00921.html
As a conclusion, it seems to me that KVM tool dosesn't consider too much
about the interface for upper layer management tools, (generally, upper
layer apps will want good interface to set/get), which might be no good
for KVM tool future development.
Thoughts, and opinions? Thanks.
[PATCH 1/7] kvmtool: Add configure support
[PATCH] kvm tools: Introduce an ENV variable for the state dir
[PATCH 2/7] kvmtool: Add documents
[PATCH 3/7] kvmtool: Add new enums and error codes for the driver
[PATCH 4/7] kvmtool: Add hook support for kvmtool domain
[PATCH 5/7] kvmtool: Add new domain type
[PATCH 6/7] conf: Set source type of the stub console
[PATCH 7/7] kvmtool: Implementation for kvm tool driver
Regards,
Osier
13 years, 4 months
[libvirt] libvirt hyper-v
by Andy Li
Dear Sir or Madam:
I am engineer who want to connect hyper-v R2 via libvirt 0.9.3, but after
create ceritificate file, and set the hyper-v winRM status to
AllowUnencrypted="true"
Then I connect the hyper-v by the command: virsh -c
hyperv://192.168.58.26:5985 it always reply:
Error: unable to complete TLS handshake: A TLS packet with unexpected length
was received
Error: failed to connect to the hypervisor
Hope you can help me, thank you very much in advance.
Thanks,
Andy Li MFG Software Developer
Department of Storage Products R&D, SCS
Universal Scientific Industrial (Shanghai) Co., Ltd
421 Lishizhen Rd, Pudong New Area, Shanghai,P.R. China, 201203
Tel : +86 -21-5896 6996 ext. 81453
Fax : +86 -21-5080 4268
13 years, 4 months
[libvirt] [PATCH] test: fix potential lock corruption in test driver
by Laine Stump
From: Laine Stump <laine(a)redhat.com>
In some error situations, the function testDomainRestoreFlags() could
unlock the test driver mutex without first locking it. This patch
moves the lock operation earlier, so that it occurs before any
potential jump down to the unlock call.
I found this problem while auditing the test driver lock usage to
determine the cause of a hang while running the following test:
cd tests; while true; do printf x; ./undefine; done
This patch *does not* solve that problem, but we now understand its
actual source, and danpb is working on a patch.
---
src/test/test_driver.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/test/test_driver.c b/src/test/test_driver.c
index ce94a17..89f7df1 100644
--- a/src/test/test_driver.c
+++ b/src/test/test_driver.c
@@ -1861,6 +1861,8 @@ testDomainRestoreFlags(virConnectPtr conn,
return -1;
}
+ testDriverLock(privconn);
+
if ((fd = open(path, O_RDONLY)) < 0) {
virReportSystemError(errno,
_("cannot read domain image '%s'"),
@@ -1900,7 +1902,6 @@ testDomainRestoreFlags(virConnectPtr conn,
}
xml[len] = '\0';
- testDriverLock(privconn);
def = virDomainDefParseString(privconn->caps, xml,
1 << VIR_DOMAIN_VIRT_TEST,
VIR_DOMAIN_XML_INACTIVE);
--
1.7.7.3
13 years, 4 months
[libvirt] [PATCH] test: replace deprecated "fedora-13" machine with "pc-0.13"
by Laine Stump
One of the xml tests in the test suite was created using a
now-deprecated qemu machine type ("fedora-13", which was only ever
valid for Fedora builds of qemu). Although strictly speaking it's not
necessary to replace it with an actual supported qemu machine type
(since the xml in question is never actually sent to qemu), this patch
changes it to the actually-supported "pc-0.13" just for general
tidiness. (Also, on some Fedora builds which contain a special patch
to rid the world of "fedora-13", having it mentioned in the test suite
will cause make check to fail.)
---
.../qemuxml2argv-encrypted-disk.args | 2 +-
.../qemuxml2argv-encrypted-disk.xml | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-encrypted-disk.args b/tests/qemuxml2argvdata/qemuxml2argv-encrypted-disk.args
index 1da0073..c6634fd 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-encrypted-disk.args
+++ b/tests/qemuxml2argvdata/qemuxml2argv-encrypted-disk.args
@@ -1,5 +1,5 @@
LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin HOME=/root USER=root LOGNAME=root \
-/usr/bin/qemu -S -M fedora-13 -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name \
+/usr/bin/qemu -S -M pc-0.13 -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name \
encryptdisk -uuid 496898a6-e6ff-f7c8-5dc2-3cf410945ee9 -nographic -nodefconfig \
-nodefaults -chardev socket,id=monitor,\
path=//var/lib/libvirt/qemu/encryptdisk.monitor,server,nowait -mon \
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-encrypted-disk.xml b/tests/qemuxml2argvdata/qemuxml2argv-encrypted-disk.xml
index f5e5d74..fdcf624 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-encrypted-disk.xml
+++ b/tests/qemuxml2argvdata/qemuxml2argv-encrypted-disk.xml
@@ -5,7 +5,7 @@
<currentMemory>524288</currentMemory>
<vcpu>1</vcpu>
<os>
- <type arch='i686' machine='fedora-13'>hvm</type>
+ <type arch='i686' machine='pc-0.13'>hvm</type>
<boot dev='hd'/>
</os>
<clock offset='utc'/>
--
1.7.7.3
13 years, 4 months
[libvirt] [PATCH] network: don't add iptables rules for externally managed networks
by Laine Stump
From: Laine Stump <laine(a)redhat.com>
This patch addresses https://bugzilla.redhat.com/show_bug.cgi?id=760442
When a network has any forward type other than route, nat or none, the
network configuration should be done completely external to libvirt -
libvirt only uses these types to allow configuring guests in a manner
that isn't tied to a specific host (all the host-specific information,
in particular interface names, port profile data, and bandwidth
configuration is in the network definition, and the guest
configuration only references it).
Due to a bug in the bridge network driver, libvirt was adding iptables
rules for networks with forward type='bridge' etc. any time libvirtd
was restarted while one of these networks was active.
This patch eliminates that error by only "reloading" iptables rules if
forward type is route, nat, or none.
---
src/network/bridge_driver.c | 18 +++++++++++++-----
1 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c
index 63338a2..44c80e1 100644
--- a/src/network/bridge_driver.c
+++ b/src/network/bridge_driver.c
@@ -1470,14 +1470,22 @@ networkReloadIptablesRules(struct network_driver *driver)
VIR_INFO("Reloading iptables rules");
for (i = 0 ; i < driver->networks.count ; i++) {
- virNetworkObjLock(driver->networks.objs[i]);
- if (virNetworkObjIsActive(driver->networks.objs[i])) {
- networkRemoveIptablesRules(driver, driver->networks.objs[i]);
- if (networkAddIptablesRules(driver, driver->networks.objs[i]) < 0) {
+ virNetworkObjPtr network = driver->networks.objs[i];
+
+ virNetworkObjLock(network);
+ if (virNetworkObjIsActive(network) &&
+ ((network->def->forwardType == VIR_NETWORK_FORWARD_NONE) ||
+ (network->def->forwardType == VIR_NETWORK_FORWARD_NAT) ||
+ (network->def->forwardType == VIR_NETWORK_FORWARD_ROUTE))) {
+ /* Only the three L3 network types that are configured by libvirt
+ * need to have iptables rules reloaded.
+ */
+ networkRemoveIptablesRules(driver, network);
+ if (networkAddIptablesRules(driver, network) < 0) {
/* failed to add but already logged */
}
}
- virNetworkObjUnlock(driver->networks.objs[i]);
+ virNetworkObjUnlock(network);
}
}
--
1.7.7.3
13 years, 4 months
