[libvirt] [PATCH libvirt-glib 1/2] Add binding for virDomainOpenConsole
by Daniel P. Berrange
From: "Daniel P. Berrange" <berrange(a)redhat.com>
---
libvirt-gobject/libvirt-gobject-domain.c | 48 ++++++++++++++++++++++++++++++
libvirt-gobject/libvirt-gobject-domain.h | 6 ++++
libvirt-gobject/libvirt-gobject.sym | 1 +
3 files changed, 55 insertions(+), 0 deletions(-)
diff --git a/libvirt-gobject/libvirt-gobject-domain.c b/libvirt-gobject/libvirt-gobject-domain.c
index 7bfb0ae..331a533 100644
--- a/libvirt-gobject/libvirt-gobject-domain.c
+++ b/libvirt-gobject/libvirt-gobject-domain.c
@@ -589,3 +589,51 @@ end:
virStreamFree(st);
return mime;
}
+
+
+/**
+ * gvir_domain_open_console:
+ * @dom: (transfer none): the domain
+ * @devname: (transfer none)(allow-none): the device name
+ * @stream: (transfer none): stream to use as output
+ * @flags: extra flags, currently unused
+ *
+ * Open a text console for the domain @dom, connecting it to the
+ * stream @stream. If @devname is NULL, the default console will
+ * be opened, otherwise @devname can be used to specify a non-default
+ * console device.
+ *
+ * Returns: TRUE if the console was opened, FALSE otherwise.
+ */
+gboolean gvir_domain_open_console(GVirDomain *dom,
+ GVirStream *stream,
+ const gchar *devname,
+ guint flags,
+ GError **err)
+{
+ GVirDomainPrivate *priv;
+ virStreamPtr st = NULL;
+ gboolean ret = FALSE;
+
+ g_return_val_if_fail(GVIR_IS_DOMAIN(dom), FALSE);
+ g_return_val_if_fail(GVIR_IS_STREAM(stream), FALSE);
+
+ priv = dom->priv;
+ g_object_get(stream, "handle", &st, NULL);
+
+ if (virDomainOpenConsole(priv->handle,
+ devname,
+ st,
+ flags) < 0) {
+ gvir_set_error_literal(err, GVIR_DOMAIN_ERROR,
+ 0,
+ "Unable to open console");
+ goto cleanup;
+ }
+
+ ret = TRUE;
+cleanup:
+ if (st != NULL)
+ virStreamFree(st);
+ return ret;
+}
diff --git a/libvirt-gobject/libvirt-gobject-domain.h b/libvirt-gobject/libvirt-gobject-domain.h
index b9e39dd..3a4dd02 100644
--- a/libvirt-gobject/libvirt-gobject-domain.h
+++ b/libvirt-gobject/libvirt-gobject-domain.h
@@ -141,6 +141,12 @@ gchar *gvir_domain_screenshot(GVirDomain *dom,
guint flags,
GError **err);
+gboolean gvir_domain_open_console(GVirDomain *dom,
+ GVirStream *stream,
+ const gchar *devname,
+ guint flags,
+ GError **err);
+
G_END_DECLS
#endif /* __LIBVIRT_GOBJECT_DOMAIN_H__ */
diff --git a/libvirt-gobject/libvirt-gobject.sym b/libvirt-gobject/libvirt-gobject.sym
index d0444bd..caef28d 100644
--- a/libvirt-gobject/libvirt-gobject.sym
+++ b/libvirt-gobject/libvirt-gobject.sym
@@ -52,6 +52,7 @@ LIBVIRT_GOBJECT_0.0.1 {
gvir_domain_resume;
gvir_domain_stop;
gvir_domain_delete;
+ gvir_domain_open_console;
gvir_domain_shutdown;
gvir_domain_reboot;
gvir_domain_get_config;
--
1.7.7.3
12 years, 11 months
[libvirt] Storage pool/volume support in libvirt-gconfig
by Christophe Fergeau
Hi,
This patch series adds configuration of storage pools and volumes to
libvirt-gconfig. Nothing particularly exciting in there, just more gobjects
and setters using the existing helpers. Maybe it would be worth introducing
a gvir_config_object_set_content_with_attributes to factor some redundant
code.
Christophe
12 years, 11 months
[libvirt] Transitioning from HMP to QMP for QEMU
by Stefan Hajnoczi
What is the status of QEMU's transition from HMP to the QMP interface?
My current understanding is that QEMU provides new HMP commands for
humans, but HMP is being phased out as an API. Management tools
should rely only on QMP for new commands. That would mean new HMP
commands are not guaranteed to produce backwards-compatible output
because tools are not supposed to parse the output.
On the libvirt side, new QEMU features should only be supported via
the json monitor in the future (i.e. human monitor patches should not
be sent/merged)? Existing HMP commands will still need the human
monitor support in order to handle old QEMU versions gracefully, but
I'm thinking about new commands only.
Does everyone agree on this? I think this is an important discussion
if we want our management interface to get better and more consistent
in the future.
Stefan
12 years, 11 months
Re: [libvirt] FW: macvtap not working on rhel 6.1 x86 machine
by Amit Tewari
Hi,
Can you please tell me what step iam missing?
-----Original Message-----
From: Gerhard Stenzel [mailto:gstenzel@linux.vnet.ibm.com]
Sent: Thursday, December 15, 2011 5:03 PM
To: Amit Tewari
Cc: libvir-list(a)redhat.com
Subject: RE: [libvirt] FW: macvtap not working on rhel 6.1 x86 machine
On Thu, 2011-12-15 at 15:54 +0530, Amit Tewari wrote:
> hi,
>
> i want the kvm guest machine to connect to network using macvtap..
> I tried this vepa mode it is also not working.
where is your DHCP server? On the network or on your host?
> eth0 has same mac address as that of macvatap0 that is 52:54:00:55:AE:B5
this is correct. The mac address of eth0 in the guest is the same as
that of the macvtap device of the host.
> due to this guest is not able to get dhcp address nor static ip address is working.
it works for me. I am on 6.2 now, but this worked on 6.1 as well.
--
Best regards,
Gerhard Stenzel,
-----------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
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. .
-----------------------------------------------------------------------------------------------------------------------
12 years, 11 months
Re: [libvirt] FW: macvtap not working on rhel 6.1 x86 machine
by Amit Tewari
hi,
i want the kvm guest machine to connect to network using macvtap..
I tried this vepa mode it is also not working.
My test environment
Host os=rhel6.1
Guest os = rhel6.1
Libvirt=0.8.7
Kvm hypervisor
I have made this entry in guest xml file
<interface type='direct'>
<source dev='eth0' mode='bridge'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
Now when I start the guest
#virsh start guest
Following macvtap0 is created on host and is shown below
#ip link show macvtap0
51: macvtap0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UNKNOWN qlen 500
link/ether 52:54:00:55:AE:B5brd ff:ff:ff:ff:ff:ff
but when the guest is up and I try to perform
# ifup eth0
eth0 has same mac address as that of macvatap0 that is 52:54:00:55:AE:B5
due to this guest is not able to get dhcp address nor static ip address is working.
Please let me know how macvtap work on kvm.
-----Original Message-----
From: Gerhard Stenzel [mailto:gstenzel@linux.vnet.ibm.com]
Sent: Thursday, December 15, 2011 3:47 PM
To: Amit Tewari
Cc: libvir-list(a)redhat.com
Subject: Re: [libvirt] FW: macvtap not working on rhel 6.1 x86 machine
On Thu, 2011-12-15 at 15:20 +0530, Amit Tewari wrote:
>
>
> Hi all,
>
>
>
> My test environment
>
> Host os=rhel6.1 x86 machine
>
> Guest os = rhel6.1
>
> Libvirt=0.8.7
>
> Kvm hypervisor
>
Hi,
maybe it would help if you try to explain first, what you are trying to
achieve, what your setup looks like (including your DHCP setup and
switch infrastructure).
Here (http://libvirt.org/formatdomain.html) you will find the following
xml sample, which works:
...
<devices>
<interface type='direct'>
<source dev='eth0' mode='vepa'/>
</interface>
</devices>
...
This will connect your VM directly to the same network as eth0. Please
be aware that, depending on your switch configuration (supports hair pin
mode or not), your host might not be able to talk to your VM and vice
versa.
--
Best regards,
Gerhard Stenzel,
-----------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
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. .
-----------------------------------------------------------------------------------------------------------------------
12 years, 11 months
[libvirt] [PATCH] qemu: Fix race between async and query jobs
by Jiri Denemark
If an async job run on a domain will stop the domain at the end of the
job, a concurrently run query job can hang in qemu monitor nothing can
be done with that domain from this point on. An attempt to start such
domain results in "Timed out during operation: cannot acquire state
change lock" error.
However, quite a few things have to happen at the right time... There
must be an async job running, which stops a domain at the end. This race
was with dump --crash but other similar jobs, such as (managed)save and
migration, should be able to trigger this bug as well. While this async
job is processing its last monitor command, that is a query-migrate to
which qemu replies with status "completed", a new libvirt API that
results in a query job must arrive and stay waiting until the
query-migrate command finishes. Once query-migrate is done but before
the async job closes qemu monitor while stopping the domain, the other
thread needs to wake up and call qemuMonitorSend to send its command to
qemu. Before qemu gets a chance to respond to this command, the async
job needs to close the monitor. At this point, the query job thread is
waiting for a condition that no-one will ever signal so it never
finishes the job.
---
src/qemu/qemu_monitor.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c
index 4141fb7..35648ae 100644
--- a/src/qemu/qemu_monitor.c
+++ b/src/qemu/qemu_monitor.c
@@ -750,6 +750,20 @@ void qemuMonitorClose(qemuMonitorPtr mon)
VIR_FORCE_CLOSE(mon->fd);
}
+ /* In case another thread is waiting for its monitor command to be
+ * processed, we need to wake it up with appropriate error set.
+ */
+ if (mon->msg) {
+ if (mon->lastError.code == VIR_ERR_OK) {
+ qemuReportError(VIR_ERR_OPERATION_FAILED,
+ _("Qemu monitor was closed"));
+ virCopyLastError(&mon->lastError);
+ virResetLastError();
+ }
+ mon->msg->finished = 1;
+ virCondSignal(&mon->notify);
+ }
+
if (qemuMonitorUnref(mon) > 0)
qemuMonitorUnlock(mon);
}
--
1.7.8
12 years, 11 months
[libvirt] FW: macvtap not working on rhel 6.1 x86 machine
by Amit Tewari
Hi all,
My test environment
Host os=rhel6.1 x86 machine
Guest os = rhel6.1
Libvirt=0.8.7
Kvm hypervisor
I am creating macvtap interface on host machine
ip link add link eth1 name macvtap0 type macvtap
ip link set macvtap0 up
ip link show macvtap0
25: macvtap0@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast state UNKNOWN qlen 500
link/ether a2:70:4e:05:4a:4e brd ff:ff:ff:ff:ff:ff
Now when use arp -a to check macvtap0 hardware address entry it shows
? (10.0.7.1) at <incomplete> on macvtap0
If I assign ip address to macvtap and then ping on network , it says
"destination not reachable"
ping 10.0.7.1 -I macvtap0
PING 10.0.7.1 (10.0.7.1) from 10.0.1.61 macvtap0: 56(84) bytes of data.
>From 10.0.1.61 icmp_seq=2 Destination Host Unreachable
>From 10.0.1.61 icmp_seq=3 Destination Host Unreachable
If I use tcpdump -I eth1 it shows packets
14:42:39.967158 ARP, Request who-has 10.0.7.1 tell 10.0.7.4, length 28
14:42:39.967257 ARP, Reply 10.0.7.1 is-at 00:16:35:65:b5:1e (oui
Unknown), length 46
14:42:40.967167 ARP, Request who-has 10.0.7.1 tell 10.0.7.4, length 28
14:42:40.967229 ARP, Reply 10.0.7.1 is-at 00:16:35:65:b5:1e (oui
Unknown), length 46
So macvtap0 is unknown interface. Request does go to eth1 inteface.
Please let me know redhat 6.1 support macvtap or not?...
I have to use it for kvm virtual machine..
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. .
-----------------------------------------------------------------------------------------------------------------------
12 years, 11 months
[libvirt] [PATCH 0/4] Add new public API virDomainGetPcpusUsage and pcpuinfo command in virsh
by Lai Jiangshan
"virt-top -1" can call virDomainGetPcpusUsage() periodically and get
the CPU activities per CPU. (still require virt-top site patch).
virsh is also added a pcpuinfo command which calls virDomainGetPcpusUsage(),
it gets information about the physic CPUs, such as the usage of
CPUs, the current attached vCPUs.
# virsh pcpuinfo rhel6
CPU: 0
Curr VCPU: -
Usage: 47.3
CPU: 1
Curr VCPU: 1
Usage: 46.8
CPU: 2
Curr VCPU: 0
Usage: 52.7
CPU: 3
Curr VCPU: -
Usage: 44.1
Lai Jiangshan (4):
Add new public API virDomainGetPcpusUsage
remote: support new API virDomainGetPcpusUsage for remote driver
qemu: implemnt new API virDomainGetPcpusUsage for qemu driver
Enable the pcpuinfo command in virsh
daemon/remote.c | 68 ++++++++++++++++++++++++++++++
include/libvirt/libvirt.h.in | 5 ++
python/generator.py | 1 +
src/driver.h | 7 +++
src/libvirt.c | 51 +++++++++++++++++++++++
src/libvirt_public.syms | 5 ++
src/qemu/qemu.conf | 5 +-
src/qemu/qemu_conf.c | 3 +-
src/qemu/qemu_driver.c | 74 +++++++++++++++++++++++++++++++++
src/remote/remote_driver.c | 51 +++++++++++++++++++++++
src/remote/remote_protocol.x | 17 +++++++-
src/remote_protocol-structs | 13 ++++++
src/util/cgroup.c | 7 +++
src/util/cgroup.h | 1 +
tools/virsh.c | 93 ++++++++++++++++++++++++++++++++++++++++++
tools/virsh.pod | 5 ++
16 files changed, 402 insertions(+), 4 deletions(-)
--
1.7.4.4
12 years, 11 months
Re: [libvirt] macvtap nt working on kvm
by Amit Tewari
Hi Stefan,
May be you can try again this test of macvtap on your environment, but
please remove the bridge from eth0. because macvtap doesent work with
bridge setup.
-----Original Message-----
From: Amit Tewari
Sent: Thursday, December 15, 2011 9:05 AM
To: 'Laine Stump'; libvir-list(a)redhat.com
Subject: RE: [libvirt] macvtap nt working on kvm
Hi,
Actually macvatap doesn't work with bridge. So once the physical device
is attached to a bridge, a macvtap attached to that device no longer
works.
In my case there is no bridge on the interface. but still guest os is
not able to get ip address.
Is there no support for macvtap on red hat 6.1 x_86 platforms?
-----Original Message-----
From: libvir-list-bounces(a)redhat.com
[mailto:libvir-list-bounces@redhat.com] On Behalf Of Laine Stump
Sent: Thursday, December 15, 2011 2:31 AM
To: libvir-list(a)redhat.com
Subject: Re: [libvirt] macvtap nt working on kvm
On 12/14/2011 02:26 PM, Stefan Berger wrote:
> On 12/14/2011 07:40 AM, Amit Tewari wrote:
>>
>> Hi all,
>>
>> My test environment
>>
>> Host os=rhel6.1
>>
>> Guest os = rhel6.1
>>
>> Libvirt=0.8.7
>>
>> Kvm hypervisor
>>
>> I have made this entry in guest xml file
>>
>> <interface type='direct'>
>>
>> <source dev='eth0' mode='bridge'/>
>>
>> <model type='virtio'/>
>>
>> <address type='pci' domain='0x0000' bus='0x00' slot='0x03'
>> function='0x0'/>
>>
>> </interface>
>>
>> Now when I start the guest
>>
>> *#virsh start guest*
>>
>> Following macvtap0 is created on host and is shown below
>>
>> #*ip link show macvtap0*
>>
>> 51: macvtap0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
>> mq state UNKNOWN qlen 500
>>
>> link/ether 52:54:00:55:AE:B5brd ff:ff:ff:ff:ff:ff
>>
>> but when the guest is up and I try to perform
>>
>> **
>>
>> *# ifup eth0*
>>
>> *eth0 has same mac address as that of macvatap0 that is
>> 52:54:00:55:AE:B5*
>>
>> **
>>
>> *due to this guest is not able to get dhcp address nor static ip
>> address is working*.
>>
>> Please let me know how macvtap work on kvm.
>>
>
> I have tried your setup on my machine with the following host
> configuration:
>
> # brctl show
> bridge name bridge id STP enabled interfaces
> br0 8000.001a64d00016 no eth0
> virbr0 8000.000000000000 yes
>
> If I use the configuration as you have shown it doesn't work for me,
> either. However, if I use
>
> <source dev='br0' mode='bridge'/>
>
> then it works as expected. Do you happen to have a similar
> configuration on the host with the interface the macvtap device wants
> to use as 'source' being bridged?
Interesting. So you're saying that once the physical device is attached
to a bridge, a macvtap attached to that device no longer works? That's
useful to know :-)
--
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. .
-----------------------------------------------------------------------------------------------------------------------
12 years, 11 months
Re: [libvirt] macvtap nt working on kvm
by Amit Tewari
Hi,
Actually macvatap doesn't work with bridge. So once the physical device
is attached to a bridge, a macvtap attached to that device no longer
works.
In my case there is no bridge on the interface. but still guest os is
not able to get ip address.
Is there no support for macvtap on red hat 6.1 x_86 platforms?
-----Original Message-----
From: libvir-list-bounces(a)redhat.com
[mailto:libvir-list-bounces@redhat.com] On Behalf Of Laine Stump
Sent: Thursday, December 15, 2011 2:31 AM
To: libvir-list(a)redhat.com
Subject: Re: [libvirt] macvtap nt working on kvm
On 12/14/2011 02:26 PM, Stefan Berger wrote:
> On 12/14/2011 07:40 AM, Amit Tewari wrote:
>>
>> Hi all,
>>
>> My test environment
>>
>> Host os=rhel6.1
>>
>> Guest os = rhel6.1
>>
>> Libvirt=0.8.7
>>
>> Kvm hypervisor
>>
>> I have made this entry in guest xml file
>>
>> <interface type='direct'>
>>
>> <source dev='eth0' mode='bridge'/>
>>
>> <model type='virtio'/>
>>
>> <address type='pci' domain='0x0000' bus='0x00' slot='0x03'
>> function='0x0'/>
>>
>> </interface>
>>
>> Now when I start the guest
>>
>> *#virsh start guest*
>>
>> Following macvtap0 is created on host and is shown below
>>
>> #*ip link show macvtap0*
>>
>> 51: macvtap0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
>> mq state UNKNOWN qlen 500
>>
>> link/ether 52:54:00:55:AE:B5brd ff:ff:ff:ff:ff:ff
>>
>> but when the guest is up and I try to perform
>>
>> **
>>
>> *# ifup eth0*
>>
>> *eth0 has same mac address as that of macvatap0 that is
>> 52:54:00:55:AE:B5*
>>
>> **
>>
>> *due to this guest is not able to get dhcp address nor static ip
>> address is working*.
>>
>> Please let me know how macvtap work on kvm.
>>
>
> I have tried your setup on my machine with the following host
> configuration:
>
> # brctl show
> bridge name bridge id STP enabled interfaces
> br0 8000.001a64d00016 no eth0
> virbr0 8000.000000000000 yes
>
> If I use the configuration as you have shown it doesn't work for me,
> either. However, if I use
>
> <source dev='br0' mode='bridge'/>
>
> then it works as expected. Do you happen to have a similar
> configuration on the host with the interface the macvtap device wants
> to use as 'source' being bridged?
Interesting. So you're saying that once the physical device is attached
to a bridge, a macvtap attached to that device no longer works? That's
useful to know :-)
--
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. .
-----------------------------------------------------------------------------------------------------------------------
12 years, 11 months
