On (Thu) Aug 06 2009 [18:37:40], Jamie Lokier wrote:
> Amit Shah wrote:
> > On (Thu) Aug 06 2009 [08:58:01], Anthony Liguori wrote:
> > > Amit Shah wrote:
> > >> On (Thu) Aug 06 2009 [08:29:40], Anthony Liguori wrote:
> > >>
> > >>> Amit Shah wrote:
> > >>>
> > Sure; but there's been n
On Wednesday, August 05, 2009 9:15 PM Avi Kivity wrote:
>> Two New Issues:
>>
>> 1. Guest will be no response after migration
>>
> https://sourceforge.net/tracker/?func=detail&atid=893831&aid=28
> 32401&group_id=180599
>>
>
> What kind of guest i
On Thu, Aug 06, 2009 at 10:29:08AM -0600, Gregory Haskins wrote:
> >>> On 8/6/2009 at 11:40 AM, in message <200908061740.04276.a...@arndb.de>,
> >>> Arnd
> Bergmann wrote:
> > On Thursday 06 August 2009, Gregory Haskins wrote:
[ big snip ]
> >
> > 3. The ioq method seems to be the real core o
This doesn't speak directly to your live migration issue -- but
copy-and-pasting a libvirt-generated command line (as you're doing here)
and using it by hand is perilous.
As I mentioned when you asked in the IRC channel, you shouldn't be using
fd= here when starting kvm by hand -- it expects t
Hi all
I need some support here please!
I deploy two Dell Server, with Ubuntu 9.04, with KVM and I can not get
migration between this two machines
I try with virsh, using
migrate --live domain qemu +ssh://destdomain/system
but this not work properly...
I try migrate via qemu console too,
In VM.get_address(), return an IP address from the MAC-IP cache if an IP
address base wasn't specified by the user, or if the user requested that IP
addresses be taken from the dynamic cache.
To force the system to obtain IP addresses from the dynamic cache even when
static base addresses are prov
The script adds a requested interface to an existing bridge. It is meant to be
used by qemu when running in TAP mode.
Note: the user is responsible for setting up the bridge before running any
tests. This can be done with brctl or in any manner that is appropriate for
the host OS. It can be don
Add function get_mac_ip_pair_from_dict() which gets a dict (specified in the
config file by the user) and fetches a MAC-IP address pair according to a
certain syntax. The syntax allows the user to specify a group of MAC-IP
address ranges. For example:
address_ranges = r1 r2 r3
address_range_bas
I found two mistakes (so far) in the TAP patchset:
- Two import lines in kvm_utils.py were commented out (for personal testing)
and I forgot to uncomment them before committing, and this breaks kvm_install
- qemu-ifup should be executable, but isn't
The following patches (1, 3, 11) replace the
Amit Shah wrote:
> On (Thu) Aug 06 2009 [08:58:01], Anthony Liguori wrote:
> > Amit Shah wrote:
> >> On (Thu) Aug 06 2009 [08:29:40], Anthony Liguori wrote:
> >>
> >>> Amit Shah wrote:
> >>>
> Sure; but there's been no resistance from anyone from including the
> virtio-serial devi
>>> On 8/6/2009 at 11:50 AM, in message <4a7afbe3.5080...@redhat.com>, Avi
>>> Kivity
wrote:
> On 08/06/2009 06:40 PM, Arnd Bergmann wrote:
>> 3. The ioq method seems to be the real core of your work that makes
>> venet perform better than virtio-net with its virtqueues. I don't see
>> any reaso
Michael suggested to me a while ago to try MSI with virtio-blk and I
played with this small patch:
Index: qemu-kvm/hw/virtio-blk.c
===
--- qemu-kvm.orig/hw/virtio-blk.c
+++ qemu-kvm/hw/virtio-blk.c
@@ -416,6 +416,7 @@ VirtIODevice *v
>>> On 8/6/2009 at 11:40 AM, in message <200908061740.04276.a...@arndb.de>, Arnd
Bergmann wrote:
> On Thursday 06 August 2009, Gregory Haskins wrote:
>> We can exchange out the "virtio-pci" module like this:
>>
>> (guest-side)
>> |--
>> | virtio-net
>> |
How hard would it be to implement virtio over vbus and perhaps the
virtio-net backend?
This would leave only one variable in the comparison, clear misconceptions and
make evaluation easier by judging each of vbus, venet etc separately on its own
merits.
The way things are now, it is unclear exact
On Thu, Aug 06, 2009 at 05:40:04PM +0200, Arnd Bergmann wrote:
> 3. The ioq method seems to be the real core of your work that makes
> venet perform better than virtio-net with its virtqueues. I don't see
> any reason to doubt that your claim is correct. My conclusion from
> this would be to add su
On 08/06/2009 06:40 PM, Arnd Bergmann wrote:
3. The ioq method seems to be the real core of your work that makes
venet perform better than virtio-net with its virtqueues. I don't see
any reason to doubt that your claim is correct. My conclusion from
this would be to add support for ioq to virtio
On Thursday 06 August 2009, Gregory Haskins wrote:
> We can exchange out the "virtio-pci" module like this:
>
> (guest-side)
> |--
> | virtio-net
> |--
> | virtio-ring
> |--
> | virtio-bus
> |--
> | v
>>> On 8/6/2009 at 9:59 AM, in message <20090806135903.ga11...@redhat.com>,
"Michael S. Tsirkin" wrote:
> On Thu, Aug 06, 2009 at 07:45:30AM -0600, Gregory Haskins wrote:
>> > (though still rooting for virtio).
>>
>> Heh...not to belabor the point to death, but virtio is orthogonal (you keep
>
>>> On 8/6/2009 at 9:57 AM, in message <4a7ae150.7040...@redhat.com>, Avi
>>> Kivity
wrote:
> On 08/06/2009 04:45 PM, Gregory Haskins wrote:
>>
>>> (though still rooting for virtio).
>>>
>>
>> Heh...not to belabor the point to death, but virtio is orthogonal (you keep
> forgetting that ;
On (Thu) Aug 06 2009 [08:58:01], Anthony Liguori wrote:
> Amit Shah wrote:
>> On (Thu) Aug 06 2009 [08:29:40], Anthony Liguori wrote:
>>
>>> Amit Shah wrote:
>>>
Sure; but there's been no resistance from anyone from including the
virtio-serial device driver so maybe we don't need
On Thu, Aug 06, 2009 at 07:45:30AM -0600, Gregory Haskins wrote:
> > (though still rooting for virtio).
>
> Heh...not to belabor the point to death, but virtio is orthogonal (you keep
> forgetting that ;).
venet and virtio aren't orthogonal, are they?
--
MST
--
To unsubscribe from this list: s
Amit Shah wrote:
On (Thu) Aug 06 2009 [08:29:40], Anthony Liguori wrote:
Amit Shah wrote:
Sure; but there's been no resistance from anyone from including the
virtio-serial device driver so maybe we don't need to discuss that.
There certainly is from me. The userspace interfac
On 08/06/2009 04:45 PM, Gregory Haskins wrote:
(though still rooting for virtio).
Heh...not to belabor the point to death, but virtio is orthogonal (you keep
forgetting that ;).
Its really the vbus device-model vs the qemu device-model (and possibly vs the
"in-kernel pci emulation" m
>>> On 8/6/2009 at 9:44 AM, in message <4a7ade23.5010...@redhat.com>, Avi
>>> Kivity
wrote:
> On 08/06/2009 04:03 PM, Gregory Haskins wrote:
>>> It's true that vbus is a separate project (in fact even virtio is
>>> completely separate from kvm). Still I think it would be of interest to
>>> man
On (Thu) Aug 06 2009 [08:29:40], Anthony Liguori wrote:
> Amit Shah wrote:
>> Sure; but there's been no resistance from anyone from including the
>> virtio-serial device driver so maybe we don't need to discuss that.
>>
>
> There certainly is from me. The userspace interface is not reasonable
On 08/06/2009 04:03 PM, Gregory Haskins wrote:
It's true that vbus is a separate project (in fact even virtio is
completely separate from kvm). Still I think it would be of interest to
many kvm@ readers.
Well, my goal was to not annoy KVM readers. ;) So if you feel as though there
is b
Amit Shah wrote:
Sure; but there's been no resistance from anyone from including the
virtio-serial device driver so maybe we don't need to discuss that.
There certainly is from me. The userspace interface is not reasonable
for guest applications to use.
Regards,
Anthony Liguori
>>> On 8/6/2009 at 8:54 AM, in message <4a7ad29e.50...@redhat.com>, Avi Kivity
wrote:
> On 08/06/2009 03:08 PM, Gregory Haskins wrote:
>>> Merging the guest first means relying on
>>> kernel interface from an out of tree driver, which well might change
>>> before it goes in.
>>>
>>
>> ABI
>>> On 8/6/2009 at 8:24 AM, in message <20090806122449.gc11...@redhat.com>,
"Michael S. Tsirkin" wrote:
> On Thu, Aug 06, 2009 at 06:08:27AM -0600, Gregory Haskins wrote:
>> Hi Michael,
>>
>> >>> On 8/6/2009 at 4:19 AM, in message <20090806081955.ga9...@redhat.com>,
>> "Michael S. Tsirkin" wr
On 08/06/2009 03:08 PM, Gregory Haskins wrote:
Merging the guest first means relying on
kernel interface from an out of tree driver, which well might change
before it goes in.
ABI compatibility is already addressed/handled, so even if that is true its not
a problem.
Really the cor
>>> On 8/6/2009 at 6:17 AM, in message <20090806101702.ga10...@redhat.com>,
"Michael S. Tsirkin" wrote:
> On Thu, Aug 06, 2009 at 11:19:56AM +0300, Michael S. Tsirkin wrote:
>> On Mon, Aug 03, 2009 at 01:17:30PM -0400, Gregory Haskins wrote:
>> > (Applies to v2.6.31-rc5, proposed for linux-next
Hi Michael,
>>> On 8/6/2009 at 4:19 AM, in message <20090806081955.ga9...@redhat.com>,
"Michael S. Tsirkin" wrote:
> On Mon, Aug 03, 2009 at 01:17:30PM -0400, Gregory Haskins wrote:
>> (Applies to v2.6.31-rc5, proposed for linux-next after review is complete)
>
> These are guest drivers, right
On Thu, Aug 06, 2009 at 06:08:27AM -0600, Gregory Haskins wrote:
> Hi Michael,
>
> >>> On 8/6/2009 at 4:19 AM, in message <20090806081955.ga9...@redhat.com>,
> "Michael S. Tsirkin" wrote:
> > On Mon, Aug 03, 2009 at 01:17:30PM -0400, Gregory Haskins wrote:
> >> (Applies to v2.6.31-rc5, proposed
On Thu, Aug 6, 2009 at 2:41 AM, sudhir kumar wrote:
> Lets not make it a python script. Since the purpose of providing this
> script is that the user can copy it to /etc also and not bother
> updating it to kvm_tests.cfg, so let us keep it bash only. Also as
> Michael pointed there is nothing much
On 08/06/2009 01:43 PM, Michael Goldish wrote:
I do exactly that, but with named pipes. Are unix domain sockets better?
(The pipes are not causing any trouble AFAIK.)
They're a little better since you can pass file descriptors (like the
monitor fd) over them.
--
error compiling committ
- "Avi Kivity" wrote:
> On 08/05/2009 09:47 PM, Michael Goldish wrote:
> >
> > I can find out if the parent process is alive by checking a lock
> file.
> > A little while ago I couldn't afford to do that in is_alive()
> because
> > it would cause a deadlock, but now this shouldn't be a probl
On (Wed) Aug 05 2009 [13:00:57], Anthony Liguori wrote:
> Jamie Lokier wrote:
>> Anthony Liguori wrote:
>>
>>> Richard W.M. Jones wrote:
>>> Have you considered using a usb serial device? Something attractive
>>> about it is that a productid/vendorid can be specified which means
>>> that you
On (Wed) Aug 05 2009 [18:57:13], Jamie Lokier wrote:
> Anthony Liguori wrote:
> > Richard W.M. Jones wrote:
> > Have you considered using a usb serial device? Something attractive
> > about it is that a productid/vendorid can be specified which means that
> > you can use that as a method of enum
On Thu, Aug 06, 2009 at 11:19:56AM +0300, Michael S. Tsirkin wrote:
> On Mon, Aug 03, 2009 at 01:17:30PM -0400, Gregory Haskins wrote:
> > (Applies to v2.6.31-rc5, proposed for linux-next after review is complete)
>
> These are guest drivers, right? Merging the guest first means relying on
> kerne
On 08/05/2009 09:47 PM, Michael Goldish wrote:
I can find out if the parent process is alive by checking a lock file.
A little while ago I couldn't afford to do that in is_alive() because
it would cause a deadlock, but now this shouldn't be a problem.
I'll test it and if it works it'll greatly s
On 08/06/2009 11:07 AM, Gleb Natapov wrote:
It was broken by commit 55b23c7377c9f9f0b4a4b90950f0e18b26ac45e8.
APIC_ID is handled by default clause anyway so remove the special
handling.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from
On Sun, 02 Aug 2009 19:32:02 +0300, Avi Kivity wrote:
> Paralleling the qemu upstream 0.11 release cycle, qemu-kvm-0.11.0-rc1 is
> now available. qemu-kvm-0.11.0-rc1 can be used with kvm kernel modules
> from your distribution kernel, or with the modules provided by the
> kvm-kmod package.
>
> P
On Mon, Aug 03, 2009 at 01:17:30PM -0400, Gregory Haskins wrote:
> (Applies to v2.6.31-rc5, proposed for linux-next after review is complete)
These are guest drivers, right? Merging the guest first means relying on
kernel interface from an out of tree driver, which well might change
before it goes
It was broken by commit 55b23c7377c9f9f0b4a4b90950f0e18b26ac45e8.
APIC_ID is handled by default clause anyway so remove the special
handling.
Signed-off-by: Gleb Natapov
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 6c3cd2c..fdddf48 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x
On 06/30/2009 01:54 PM, Amit Shah wrote:
We ignore writes to the perfctr msrs. Ignore reads as well.
Kaspersky antivirus crashes Windows guests if it can't read
these MSRs.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: s
45 matches
Mail list logo