FYI, as of libvirt 0.2.0 and virt-manager 0.3.1 there is now (experimental!)
support for managing virtual machines running under QEMU or KVM virtualization
platforms, as well as the existing Xen support.
Project sites:
http://libvirt.org/
http://virt-manager.org/
Release announcements here:
Hi all,
I just have open a sourceforge project named GKVM.
It's a rather simple gnome interface, that greatly simplify KVM virtual
machines creation, maintenance and running.
Hope could help.
Thanks.
--
Jef <[EMAIL PROTECTED]>
---
Ofer Oshri wrote:
> hi,
Hello again Ofer. Small world :)
> is there a true need for qemu to run kvm on amd machine with
> pasifica? i have not dig into the kvm code but i presumed the qemu is
> needed for the real mode phase during boot. on pasifica there is the
> paged-realmode, namely it
Avi Kivity wrote:
> Anthony Liguori wrote:
>> Avi Kivity wrote:
>>> Laurent Vivier wrote:
There are remaining issues : libposix-aio uses kernel AIO, so files
must be
opened using O_DIRECT and buffers must be aligned. libposix-aio is
able to
manage other cases but this has
hi,
is there a true need for qemu to run kvm on amd machine with pasifica? i have
not dig into the kvm code but i presumed the qemu is needed for the real mode
phase during boot. on pasifica there is the paged-realmode, namely it is
possible to turn on paging without having to switch to protec
Hi!
> In general the setup is exactly like qemu, so any howto for qemu is
> applicable.
>
> Here's what I do:
>
> - copy scripts/kvm from the kvm tarball to /etc/init.d, chkconfig and
> start the kvm service. that sets up a bridge
> - copy scripts/qemu-ifup into a new directory /etc/kvm. make
Anthony Liguori wrote:
> Avi Kivity wrote:
>> Laurent Vivier wrote:
>>> There are remaining issues : libposix-aio uses kernel AIO, so files
>>> must be
>>> opened using O_DIRECT and buffers must be aligned. libposix-aio is
>>> able to
>>> manage other cases but this has a performance cost.
>>>
>>
Avi Kivity wrote:
> Laurent Vivier wrote:
>> There are remaining issues : libposix-aio uses kernel AIO, so files
>> must be
>> opened using O_DIRECT and buffers must be aligned. libposix-aio is
>> able to
>> manage other cases but this has a performance cost.
>>
>>
>
> Because the guest is als
Andreas Hasenack wrote:
> On Tuesday 20 February 2007 13:54:53 Avi Kivity wrote:
>
>> Andreas Hasenack wrote:
>>
>>> kernel 2.6.20 vanilla
>>> kvm 14 kernel modules and userspace + "qemu kvm target" patch
>>> everything built with gcc 4
>>>
>>> Is this supposed to work? The vdisk.img was cr
On Tuesday 20 February 2007 13:54:53 Avi Kivity wrote:
> Andreas Hasenack wrote:
> > kernel 2.6.20 vanilla
> > kvm 14 kernel modules and userspace + "qemu kvm target" patch
> > everything built with gcc 4
> >
> > Is this supposed to work? The vdisk.img was created with qemu-img
> > following the ho
Laurent Vivier wrote:
> There are remaining issues : libposix-aio uses kernel AIO, so files must be
> opened using O_DIRECT and buffers must be aligned. libposix-aio is able to
> manage other cases but this has a performance cost.
>
>
Because the guest is also doing dma, the buffers are expecte
Anthony Liguori wrote:
> Laurent Vivier wrote:
>> Avi Kivity wrote:
>>
>>> Aurelien Jarno wrote:
>>>
> What is your disk image file format, or are you using a partition?
>
>
I am using a raw image file on an ext3 partition.
>>>
Bugs item #1666308, was opened at 2007-02-22 16:09
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1666308&group_id=180599
Please note that this message will contain a full copy
Arjan van de Ven wrote:
>> Can't it be done by a helper function using a timer and a signal (or
>> whatever mechanism we use to wake up vcpus)?
>>
>
> one could do that but it's not optimal; if the process DOES get waken up
> earlier, it should take the interrupt then immediately, so that it
> Can't it be done by a helper function using a timer and a signal (or
> whatever mechanism we use to wake up vcpus)?
one could do that but it's not optimal; if the process DOES get waken up
earlier, it should take the interrupt then immediately, so that it
doesn't have to wake up again when the
>
>
>> Somthing else that came up in a conversation with Dor: the need for a
>> clean way to raise a guest interrupt. The guest may be sleeping in
>> userspace, scheduled out, or running on another cpu (and requiring an
>> ipi to get it out of guest mode).
>
>yeah it'd be nice if I could just call
Arjan van de Ven wrote:
>> Somthing else that came up in a conversation with Dor: the need for a
>> clean way to raise a guest interrupt. The guest may be sleeping in
>> userspace, scheduled out, or running on another cpu (and requiring an
>> ipi to get it out of guest mode).
>>
>
> yeah i
> Somthing else that came up in a conversation with Dor: the need for a
> clean way to raise a guest interrupt. The guest may be sleeping in
> userspace, scheduled out, or running on another cpu (and requiring an
> ipi to get it out of guest mode).
yeah it'd be nice if I could just call a fun
Arjan van de Ven wrote:
> - execution of hypercall handlers outside vcpu_load() (so they are
> > preemptible and sleepable)
>
>
> I don't need this; most of my hypercalls are non-blocking. The ones that
> are can already undo the load themselves, no big deal.
>
I don't really like exposing
On Thu, 2007-02-22 at 12:40 +0200, Avi Kivity wrote:
> Arjan van de Ven wrote:
> >> I have Ingo's network PV hypercalls to commit in my piplien.
> >>
> >
> > I have 5 or so pending as well :)
> > can't wait for the infrastructure to be there so that it's relatively
> > easy to add my paravirt
Arjan van de Ven wrote:
>> I have Ingo's network PV hypercalls to commit in my piplien.
>>
>
> I have 5 or so pending as well :)
> can't wait for the infrastructure to be there so that it's relatively
> easy to add my paravirt block driver
>
I can't wait for your pv block driver :)
What d
Joerg Roedel wrote:
> On Thu, Feb 22, 2007 at 02:17:54AM -0800, Dor Laor wrote:
>
>> I have Ingo's network PV hypercalls to commit in my piplien.
>> Till then we can just add the test hypercall:
>> case __NR_hypercall_test:
>> printk(KERN_DEBUG "%s __NR_hypercall_test\n",
>> __
> >
>
> I have Ingo's network PV hypercalls to commit in my piplien.
I have 5 or so pending as well :)
can't wait for the infrastructure to be there so that it's relatively
easy to add my paravirt block driver
-
Take Surve
On Thu, Feb 22, 2007 at 02:17:54AM -0800, Dor Laor wrote:
> I have Ingo's network PV hypercalls to commit in my piplien.
> Till then we can just add the test hypercall:
> case __NR_hypercall_test:
> printk(KERN_DEBUG "%s __NR_hypercall_test\n",
> __FUNCTION__);
> r
>
>Pavel Machek wrote:
>> On Mon 2007-02-19 10:30:52, Avi Kivity wrote:
>>
>>> Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
>>>
>>
>> changelog?
>>
>>
>
>Well, I can't think of anything to add beyond $subject. The patch adds
>calls from the arch-dependent hypercall handlers to a new arch
>indepen
Pavel Machek wrote:
> On Mon 2007-02-19 10:30:52, Avi Kivity wrote:
>
>> Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
>>
>
> changelog?
>
>
Well, I can't think of anything to add beyond $subject. The patch adds
calls from the arch-dependent hypercall handlers to a new arch
independe
On Mon 2007-02-19 10:30:52, Avi Kivity wrote:
> Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
changelog?
> + switch (nr) {
> + default:
> + ;
> + }
Eh?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture
Daniel Qarras wrote:
> Hi all,
>
> I've played with Xen on my Fedora and it's been working fine. Now I'm
> testing KVM with 2.6.20 kernel and it's working nicely, too, but I'm
> unable to setup a full-blown networking, i.e., a mode where also
> icmp/udp work. User-mode networking works well, e.g.,
28 matches
Mail list logo