On Tue, Nov 3, 2015 at 10:01 AM, Paolo Bonzini wrote:
> Yes, this is correct. Thanks!
The mistake seems to be still present in changelog.
--
William
Hello,
I think there might be a mistake in the 2.4 changelog:
http://wiki.qemu.org/ChangeLog/2.4
"Support for system management mode (requires Linux 4.1)."
But I believe it's included in Linux v4.2 see
https://lwn.net/Articles/648995/ for the merge window.
Sorry for the noise if it is not the ri
Hello,
On Jan09 23:42, Paolo Bonzini wrote:
> That's commit 364c3e6b8dd7912e01d19122d791b8c8f6df4f6c on branch
> uq/master of git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git.
maybe the one for:
fix regression when reading memory size from config file
is also a patch to think about.
Thanks,
-
ave also tested it; it does work.
Thanks,
> Fixed that by querying the machine options after the configuration
> file is loaded.
>
> Cc: qemu-sta...@nongnu.org
> Reported-by: William Dauchy
> Signed-off-by: Marcel Apfelbaum
> ---
> v2 -> v3:
> - Addressed Paolo Bo
On Dec31 03:45, kevinnma(马文霜) wrote:
> diff --git a/kvm-all.c b/kvm-all.c
> index 18cc6b4..f47e1b1 100644
> --- a/kvm-all.c
> +++ b/kvm-all.c
> @@ -1123,6 +1123,17 @@ static int kvm_irqchip_get_virq(KVMState *s)
> int i, bit;
> bool retry = true;
>
> +/*
> + * PIC and IOAPIC sha
On Dec16 13:09, Markus Armbruster wrote:
> Broken since main()'s case QEMU_OPTION_machine doesn't just parse its
> option argument with qemu_opts_parse(), it also implements parameter
> "type". Copying Marcel because "he touched it, he owns it".
yes indeed, the type option is also not working, an
Hello,
I'm trying to specify machine type using the config file; for example:
[machine]
type = "pc-i440fx-2.1"
It seems to be ignored:
qom-get path=/machine property=type
{ u'return': u'pc-i440fx-2.2-machine'}
It does work with the command line:
-M "pc-i440fx-2.1"
qom-get path=/machin
No news about it in qemu2.2?
Thanks,
--
William
On Dec11 14:34, Dr. David Alan Gilbert wrote:
> > I dont get your last statement;
> > my common use case is to live migrate an old userland to a new one
> > (so 2.1 to 2.2 here); so if I guarantee same HW, it should work, right?
>
> I wouldn't trust -host cpu to be the same on the same HW between
On Dec11 14:05, Dr. David Alan Gilbert wrote:
> Hmm, it might even do it on the same hardware between different qemus;
I dont get your last statement;
my common use case is to live migrate an old userland to a new one
(so 2.1 to 2.2 here); so if I guarantee same HW, it should work, right?
--
Will
On Dec10 18:21, Dr. David Alan Gilbert wrote:
> Can you try stripping your config down to the bare minimum and see if
> it goes away? e.g. balloon, rng-pci, network I guess you can probably
> test without easily enough. If you can also try with a normal boot off
> disk rather than kernel that wo
On Dec10 17:31, Dr. David Alan Gilbert wrote:
> OK, and just checking, 2.2->2.2 and 2.1->2.1 works for you?
> It's just 2.1->2.2 that's breaking?
yes
--
William
signature.asc
Description: Digital signature
+ maybe the last patch from Paulo "kvm/apic: fix 2.2->2.1 migration" is
related?
--
William
signature.asc
Description: Digital signature
On Dec10 17:10, Dr. David Alan Gilbert wrote:
> As previously requested, please show your full command line.
qemu-system-x86_64 -m 2048 -cpu host -nodefconfig -nodefaults -nographic
-readconfig /var/lib/qemu/X/config -pidfile /var/lib/qemu/X/pid -M
pc-i440fx-2.1 -serial pty -d unimp,guest_errors
On Dec10 08:58, Dr. David Alan Gilbert wrote:
> Yes, you've got to keep the same machine type to do a live migration;
> think of it like keeping the same motherboard/cpu combination in a real
> machine - we can't squash the state from one shape machine into
> a different shape machine without the g
Hi David,
Thank you for the quick answer.
On Dec09 18:55, Dr. David Alan Gilbert wrote:
> You don't tell us what that command line is!
> If you're using -M pc or -M q35 that's expected; if you're not
> it's probably a bug - please show us the command line.
sorry it's indeed with `-M pc`. So I m
(sorry bad subject, I meant qemu2.2)
--
William
signature.asc
Description: Digital signature
Hello,
I have been testing live migration from qemu2.1.2 to qemu2.2.0 under
kvm - with same config and same command line.
the process crashes with:
Unknown combination of migration flags: 0
qemu: warning: error while loading state section id 2
Don't know if it's supposed to be supported or not.
On Nov18 18:15, Markus Armbruster wrote:
> Looks like you're using an old version of QEMU. drive_del has been
> fixed to refuse touching a backend created with blockdev-add:
I am using the last v2.1.x version but there was indeed some commits
since
> You can't destroy a backend created with bloc
On Nov18 15:22, Markus Armbruster wrote:
> This is block backend "disk1".
yes indeed.
> I presume you're deleting the device using backend "disk1".
yes
> What kind of device is this? PCI, perhaps?
> Please show us a complete QMP conversation.
Here it is:
live vm with one disk:
(QEMU) query-
Hello,
When hotremoving a disk I'm using the QMP API with device_del command;
Previous query-block command result:
{ u'device': u'disk1',
u'inserted': { u'backing_file_depth': 0,
u'bps': 0,
u'bps_rd': 0,
u'bps_wr': 0,
Hi,
On Wed, Feb 12, 2014 at 6:36 PM, Ian Main wrote:
> This is the sister command to blockdev-add. In Fam's example he uses
> the drive_del HMP command to clean up but it would be much nicer to
> have a way to do this via QMP.
Is there any news on this subject? It seems like we still need to
cl
Hi,
I'm looking for a way to limit the number of PPS using vhost-net
interface in kvm.
I saw http://www.linux-kvm.org/page/NetworkingTodo
network traffic throttling
block implemented "continuous leaky bucket" for throttling
we can use continuous leaky bucket to network
IOPS/BPS * RX/TX/TOTAL
Dev
dex when setting guest notifiers.
>
> Cc: qemu-sta...@nongnu.org
> Reported-by: "Zhangjie (HZ)"
> Tested-by: William Dauchy
please use:
Tested-by: William Dauchy
> Signed-off-by: Michael S. Tsirkin
> Signed-off-by: Jason Wang
> Reviewed-by: Michael S. Tsirkin
>
Hi Stefan,
Thanks for you answer.
On Aug22 14:22, Stefan Hajnoczi wrote:
> I don't see any obvious reason from the small diff you have posted. Are
> you sure this is the only change you've made and the environment is
> unchanged?
absolutely. I suspect a bug related to options coming from the co
Hi,
I'm trying to understand how to add a parameter in tap option.
I currently have a working config for a vm; i.e several interfaces using
multiqueues.
I had a try with:
--- a/qapi-schema.json
+++ b/qapi-schema.json
-2006,6 +2008,7 @@
##
{ 'type': 'NetdevTapOptions',
'data': {
+ '*foo'
On Aug19 15:02, William Dauchy wrote:
> I'm using readconfig option to read the three vif interfaces.
> thanks for testing I will re-triple test to see what's wrong
so indeed sorry for the noise, I was wrong in my tests.
--
William
signature.asc
Description: Digital signature
the guest notifiers before vhost starts and stop the guest
> notifiers after vhost is stopped.
> - introduce the vhost_net_set_vq_index() and call it before setting
> guest notifiers. This is used to guarantee vhost_net has the correct
> virtqueue index when setting guest notifiers.
>
On Aug19 11:40, Jason Wang wrote:
> What's the qemu command line for your testing? I try simple command line
> with 3 mq cards in qemu 2.1. Everything works fine.
I'm using readconfig option to read the three vif interfaces.
thanks for testing I will re-triple test to see what's wrong
> Is this a
On Mon, Aug 18, 2014 at 11:51 AM, Jason Wang wrote:
> err:
> @@ -254,16 +254,16 @@ void vhost_net_stop(VirtIODevice *dev, NetClientState
> *ncs,
> VirtioBusClass *k = VIRTIO_BUS_GET_CLASS(vbus);
> int i, r;
>
> +for (i = 0; i < total_queues; i++) {
> +vhost_net_stop_one(tap
Hello,
Using qemu2.1.0, a linux v3.14.X x86_64 as host and a linux v3.12.X x86_64 as
guest
I'm starting a VM with these network interfaces:
[netdev "vifA.0"]
type = "tap"
vhost = "on"
ifname = "vifA.0"
downscript = "no"
script = "no"
queues = "2"
[device "vifA.0"]
driver = "virtio
On Wed, Aug 13, 2014 at 8:03 PM, William Dauchy wrote:
> during qemu startup I see several queues in
> /sys/devices/virtual/net/vifA.0/queues and it quickly disappears; at
> the end I see only one rx and one tx.
> Am I wrong on something? What can I do to help debug this situation?
f
On Wed, Aug 13, 2014 at 8:03 PM, William Dauchy wrote:
> Using qemu2.1 I'm starting a vm with this network interface:
>
> [netdev "vifA.0"]
> type = "tap"
> vhost = "on"
> ifname = "vifA.0"
> downscript = "no"
&
Hello,
Using qemu2.1 I'm starting a vm with this network interface:
[netdev "vifA.0"]
type = "tap"
vhost = "on"
ifname = "vifA.0"
downscript = "no"
script = "no"
queues = "2"
[device "vifA.0"]
driver = "virtio-net-pci"
netdev = "vifA.0"
mac = "00:16:3e:1a:4e:11"
mq = "on"
v
On Wed, Aug 6, 2014 at 12:43 PM, William Dauchy wrote:
> this make it incompatible with -daemonize option.
> there should be a possibility to detach the process and also redirect
> stderr somewhere.
I have done a quick and dirty patch for my own qemu binary so I can
use daemonize
On Wed, Aug 6, 2014 at 12:40 AM, Peter Crosthwaite
wrote:
> Well -D will log to file only loggable (i.e. qemu_log()) information
> (which has all sorts of options and switches). Stderr, is a little
> more static and should in theory be limited to genuine errors. But if
> you want a combined log of
On Wed, Aug 6, 2014 at 11:17 AM, Dr. David Alan Gilbert
wrote:
> The trick is to pick a -M value and stick with it; then you should be
> able to keep migrating to newer QEMU versions easily (just don't
> go with dev versions because things are often broken in them).
ok
for dev versions, I'm just
On Wed, Aug 6, 2014 at 9:49 AM, Paolo Bonzini wrote:
> This is a development version between 2.0.0 and 2.0.0-rc1; it may have
> bugs such as the one that was fixed in 2.0.0-rc5.
you mean 2.1.0-rc5
> Migration from development versions is not supported. You must either
> upgrade to 2.1.0, or dow
On Wed, Aug 6, 2014 at 9:47 AM, Paolo Bonzini wrote:
> I suspect he's using "-M pc" on both.
Is it the default value? because it's not the case in my command line.
> You must use "-M pc-i440fx-2.0"
> on both if you're migrating from 2.0 to a different version.
wow. I wasn't expecting such behav
On Tue, Jul 29, 2014 at 9:51 PM, Eric Blake wrote:
> The output is on qemu's stderr. You are in control of what that stderr is.
I don't get why we can configure
-D /path/to/unique/file/name.log
but we also have to redirect stderr (I didn't checked if the daemonize
option was closing it). What's
On Tue, Aug 5, 2014 at 8:57 PM, Dr. David Alan Gilbert
wrote:
> Can you confirm this is on the final 2.1 release (there was a fix that
> went in just around rc5).
for the receiver, I'm using 2.1
# qemu-system-x86_64 --version
QEMU emulator version 2.1.0, Copyright (c) 2003-2008 Fabrice Bellar
f
Hello,
For a qemu live migration from 2.0 to 2.1 I'm getting:
qemu-system-x86_64: Length mismatch: /rom@etc/acpi/tables: 3000 in != 2
qemu-system-x86_64: Unknown ramblock "/table-loader", cannot accept migration
qemu-system-x86_64: Ack, bad migration stream!
qemu-system-x86_64: Illegal RAM of
On Thu, May 15, 2014 at 10:15 AM, Markus Armbruster wrote:
> User interface bug: not all options are coded in a way that makes them
> work with -readconfig. This includes -pidfile. Sorry!
Thanks for the answer. Maybe I can try to send a patch one day or another.
I wanted to make sure there was
Hello,
I'm using the `-pidfile` option in my qemu command line. Since I'm
also using the `-readconfig` option I thought it was a good thing to
include the pidfile option in my config file. Unfortunately I did not
found any possibility to add such option in my config file.
Is it something I could e
Dr. David Alan Gilbert
> Reported-by: William Dauchy
Please use:
Reported-by: William Dauchy
I have also successfully tested the patch
Tested-by: William Dauchy
Thanks,
--
William
Hello Dave,
Thanks for your quick reply.
On Wed, Apr 2, 2014 at 7:05 PM, Dr. David Alan Gilbert
wrote:
> You can add a launchpad entry if you like; however sicne I suspect
> it's my rework of --name to use QemuOpts that broke it, I'll add it
> to my list.
If it's already on your todo list, that
Hello,
I was using the qemu command line option:
-name foo,process=foo
in order to get a nice process naming on my linux box.
and so I could do
$ ps axco pid,command | grep 'foo'
4242 foo
I switched to a config file with:
[name]
guest = "foo"
process = "foo"
but now the previous `ps` comman
On Feb24 16:34, Stefan Hajnoczi wrote:
> Also, it should probably be 'removable':true?
oh true, did not mention this was a boolean
> You forgot to give the device an ID. Could that be the problem here?
yup I spotted that some days after and forgot to write an answer here.
that's solved the issu
Hello,
I'm starting qemu with the following config in order to test drive
hotremove and hotadd:
[drive "disk1"]
if = "none"
id = "disk1"
cache = "none"
aio = "native"
format = "raw"
file = "/dev/sda"
[device "disk1"]
driver = "scsi-hd"
drive = "disk1"
scsi-id = "1"
removable
On Mon, Jan 20, 2014 at 10:23 PM, Alexandre Kandalintsev
wrote:
> I was worried that the amount of changes would
> turn the maintainers away from the patch.
>
> Another problem is that I think there is little demand
> for this patch.
>
> But let's try to push it once again. Give me a week or
> two
Hi Alexandre,
On Mon, Mar 25, 2013 at 10:28 PM, Alexandre Kandalintsev
wrote:
> Ok, lets go this way. We will define patterns in bridge.conf like
> ~~~
> allowifname vm*
> ~~~
Do you have any news about this patch?
Regards,
--
William
On Jan14 19:24, Paolo Bonzini wrote:
> See http://lists.gnu.org/archive/html/qemu-devel/2013-03/msg04279.html
> and http://lists.gnu.org/archive/html/qemu-devel/2012-10/msg02149.html
> for previous discussions on this topic.
Thanks for pointing me this out, it's now clear.
--
William
signature.
Hello Paolo,
Thanks for your quick reply.
On Jan14 18:31, Paolo Bonzini wrote:
> I think this was nacked already in the past. You would need to
> implement some kind of ACL system like the one that is in place for
> bridges. Without it, for example, you could hijack existing iptables rules.
I
this will permit to specify an interface prefix to the tap instead of the
default one ("tap")
this functionnality is useful when you need an easy way to find the
interfaces attached to a given virtual machine
example:
-net bridge,prefix=tapvmA. -net bridge,prefix=tapvmA.
will create `tapvmA.0` a
On Mon, Jan 6, 2014 at 2:13 PM, Peter Maydell wrote:
> Ping -- who's going to take this patch? Maybe it should
> go via -trivial?
+1 still waiting for this merge
--
William
ix my issue on my qemu-system-x86_64 test platform
Tested-by: William Dauchy
Thanks,
--
William
On Wed, Mar 16, 2011 at 11:17 AM, William Dauchy wrote:
> I wanted to test vcpu hotplug. When adding a cpu I'm getting
> "qdev_create_from_info: Assertion `bus->allow_hotplug' failed."
> I went through a discussion about the subject here
> http://lists.nongnu.
Hi,
I wanted to test vcpu hotplug. When adding a cpu I'm getting
"qdev_create_from_info: Assertion `bus->allow_hotplug' failed."
I went through a discussion about the subject here
http://lists.nongnu.org/archive/html/qemu-devel/2010-08/msg00999.html
To make sure whether it was working, I hard-code
On Sun, Mar 6, 2011 at 9:38 PM, Gerhard Wiesinger wrote:
> AMD fix is now upstream. Please merge it.
oh sorry. did not see; will do.
--
William
The initialization should not be only on reset but also when initializing
the device.
It resolves a bug when hot plugging a pci network device: the mac address
was always null.
Signed-off-by: William Dauchy
Signed-off-by: Wen Congyang
---
hw/pcnet.c | 27 ++-
hw
The initialization should not be only on reset but also when initializing
the device.
It resolves a bug when hot plugging a pci network device: the mac address
was always null.
Signed-off-by: William Dauchy
Signed-off-by: Wen Congyang
---
hw/pcnet.c | 59
On Wed, Mar 2, 2011 at 7:28 PM, Gerhard Wiesinger wrote:
> Your patch should be based on fixes for correct EEPROM initialization, see
> for details: http://www.mail-archive.com/qemu-devel@nongnu.org/msg56414.html
This patch is not yet integrated upstream. I will correct it if needed.
--
William
On Wed, Mar 2, 2011 at 2:36 PM, William Dauchy wrote:
> The initialization should not be only on reset but also when initializing
> the device.
> It resolves a bug when hot plugging a pci network device: the mac address
> was always null.
> ---
> h
The initialization should not be only on reset but also when initializing
the device.
It resolves a bug when hot plugging a pci network device: the mac address
was always null.
---
hw/pcnet.c | 27 ++-
hw/rtl8139.c | 24
2 files changed, 26 in
Hi,
I got some troubles hot plugging network pci devices. An attach works
as expected but the mac address is still set to "00:00:00:00:00:00" on
the guest machine. I have to reboot the guest to get the correct mac
address.
I first tried through libvirt with:
# virsh attach-interface dom0 network d
Hi Minoru,
On Tue, Feb 15, 2011 at 3:32 AM, Minoru Usui wrote:
> I can reproduce, too.
> But strangely, it don't occur in case of loading acpiphp driver
> to the guest VM on below environment.
>
> Host : RHEL6.0
> Guest: RHEL5.5
>
> Unfortunately, I'm not familiar with qemu-kvm.
> I investigate
Hi Markus,
On Wed, Feb 23, 2011 at 9:30 AM, Markus Armbruster wrote:
> I don't think this patch is correct. Let me explain.
>
> Device hot unplug is *not* guaranteed to succeed.
>
> For some buses, such as USB, it always succeeds immediately, i.e. when
> the device_del monitor command finishes,
`qdev_free` when unplug a pci device
It resolves a bug when detaching/attaching a network device
# virsh detach-interface dom0 network --mac 52:54:00:f6:84:ba
Interface detached successfully
# virsh attach-interface dom0 network default --mac 52:54:00:f6:84:ba
error: Failed to attach interf
Hi,
On Mon, Feb 7, 2011 at 3:40 PM, William Dauchy wrote:
> On Thu, 2011-01-27 at 18:00 +0900, Ken'ichi Ohmichi wrote:
>> Hi,
>>
>> When I tried to attach the interface after detaching the same interface,
>> the virsh command output the following and it failed:
On Thu, 2011-01-27 at 18:00 +0900, Ken'ichi Ohmichi wrote:
> Hi,
>
> When I tried to attach the interface after detaching the same interface,
> the virsh command output the following and it failed:
>
> # virsh detach-interface Domain01 network --mac 52:54:00:0d:78:92
> Interface detached succ
70 matches
Mail list logo
