On 03/25/2012 02:55 PM, Anthony Liguori wrote:
>> If cpu models are not part of configuration they should not be affected
>> by configuration mechanism. You are just avoiding addressing the real
>> question that if asked above.
>
>
> I think you're just refusing to listen.
>
> The stated direction
On 03/25/2012 03:12 PM, Anthony Liguori wrote:
>>> qemu -M pc
>>>
>>> Would effectively be short hand for -readconfig
>>> /usr/share/qemu/machines/pc.cfg
>>
>> In that case
>>
>> qemu -cpu westmere
>>
>> is shorthand for -readconfig /usr/share/qemu/cpus/westmere.cfg.
>
>
> This is not a bad sugge
On 03/11/2012 04:12 PM, Anthony Liguori wrote:
>> Let me elaborate about the later. Suppose host CPU has kill_guest
>> feature and at the time a guest was installed it was not implemented by
>> kvm. Since it was not implemented by kvm it was not present in vcpu
>> during installation and the guest
On 03/25/2012 03:22 PM, Anthony Liguori wrote:
In that case
qemu -cpu westmere
is shorthand for -readconfig /usr/share/qemu/cpus/westmere.cfg.
>>>
>>>
>>> This is not a bad suggestion, although it would make -cpu ? a bit
>>> awkward. Do you see an advantage to this over
On 03/25/2012 04:36 PM, Anthony Liguori wrote:
>> Apart from the command line length, it confuses configuration with
>> definition.
>
>
> There is no distinction with what we have today. Our configuration
> file basically corresponds to command line options and as there is no
> distinction in comm
On 03/25/2012 04:59 PM, Anthony Liguori wrote:
> On 03/25/2012 09:46 AM, Avi Kivity wrote:
>> On 03/25/2012 04:36 PM, Anthony Liguori wrote:
>>>> Apart from the command line length, it confuses configuration with
>>>> definition.
>>>
>>>
>&g
On 03/25/2012 05:07 PM, Anthony Liguori wrote:
>> As log as qemu -nodefconfig -cpu westmere -M pc1.1
>
>
> -nodefconfig is going to eventually mean that -cpu westmere and -M
> pc-1.1 will not work.
>
> This is where QEMU is going. There is no reason that a normal user
> should ever use -nodefconfi
On 03/25/2012 05:26 PM, Anthony Liguori wrote:
>> Put the emphasis around *configuration*.
>
>
> So how about:
>
> 1) Load ['@SYSCONFDIR@/qemu/qemu.cfg',
> '@SYSCONFDIR@/qemu/target-@ARCH@.cfg',
> '@DATADIR@/system.cfg', '@DATADIR@/system-@ARCH@.cfg']
>
> 2) system-@ARCH@.cfg will contain:
On 03/25/2012 05:30 PM, Anthony Liguori wrote:
> On 03/25/2012 10:18 AM, Avi Kivity wrote:
>> On 03/25/2012 05:07 PM, Anthony Liguori wrote:
>>>> As log as qemu -nodefconfig -cpu westmere -M pc1.1
>>>
>>>
>>> -nodefconfig is going to eventually me
On 03/25/2012 03:26 PM, Anthony Liguori wrote:
>>> We would continue to have Westmere/etc in QEMU exposed as part of the
>>> user configuration. But I don't think it makes a lot of sense to have
>>> to modify QEMU any time a new CPU comes out.
>>
>> We have to. New features often come with new MS
On 03/25/2012 08:01 PM, Anthony Liguori wrote:
>> I don't think this came out of happiness, but despair. Seriously,
>> keeping compatibility is one of the things we work hardest to achieve,
>> and we can't manage it for our command line?
>
>
> I hate to burst your bubble, but we struggle and rarel
On 03/25/2012 08:11 PM, Anthony Liguori wrote:
>
>> I don't think -nodefconfig (as defined) is usable, since there is no way
>> for the user to tell what it means short of reading those files.
>
> *if the user doesn't know specifics about this QEMU version.
>
> You make the assumption that all user
On 03/26/2012 01:24 PM, Jiri Denemark wrote:
> ...
> > > The command line becomes unstable if you use -nodefconfig.
> >
> > -no-user-config solves this but I fully expect libvirt would continue to
> > use
> > -nodefconfig.
>
> Libvirt uses -nodefaults -nodefconfig because it wants to fully contr
On 03/26/2012 09:03 PM, Anthony Liguori wrote:
>
> I think what we want to move toward is a -no-machine option which
> allows a user to explicitly build a machine from scratch. That is:
>
> qemu -no-machine -device i440fx,id=host -device isa-serial,chr=chr0 ...
>
I'd call it -M bare-1.1, so that
On 03/26/2012 09:00 PM, Anthony Liguori wrote:
>>> Yes, that's one reason. But maybe a user wants to have a whole
>>> different set of machine types and doesn't care to have the ones we
>>> provide. Why prevent a user from doing this?
>>
>> How are we preventing a user from doing it? In what way
On 03/28/2012 02:41 PM, Avi Kivity wrote:
> On 03/27/2012 05:48 PM, Jaap Winius wrote:
> > Hi folks,
> >
> > Recently I learned how to configure KVM with USB pass-though
> > functionality. In my case I configured my guest domain
On 03/22/2010 09:25 PM, Anthony Liguori wrote:
Hi,
I've mentioned this to a few folks already but I wanted to start a
proper thread.
We're struggling in qemu with usability and one area that concerns me
is the disparity in features that are supported by qemu vs what's
implemented in libvirt
On 03/23/2010 06:06 PM, Anthony Liguori wrote:
I thought the monitor protocol *was* our API. If not, why not?
It is. But our API is missing key components like guest enumeration.
So the fundamental topic here is, do we introduce these missing
components to allow people to build directly to
On 03/23/2010 08:23 PM, Daniel P. Berrange wrote:
On Tue, Mar 23, 2010 at 08:00:21PM +0200, Avi Kivity wrote:
On 03/23/2010 06:06 PM, Anthony Liguori wrote:
I thought the monitor protocol *was* our API. If not, why not?
It is. But our API is missing key components like
On 03/23/2010 09:31 PM, Anthony Liguori wrote:
One problem is that this is libvirt version specific. For example,
libvirt x doesn't support spice so we control that thorough qmp. But
libvirt x+1 does support spice and now it gets confused about all the
spice messages.
That's only a prob
On 03/23/2010 08:00 PM, Avi Kivity wrote:
On 03/23/2010 06:06 PM, Anthony Liguori wrote:
I thought the monitor protocol *was* our API. If not, why not?
It is. But our API is missing key components like guest
enumeration. So the fundamental topic here is, do we introduce these
missing
On 03/23/2010 09:24 PM, Anthony Liguori wrote:
We also provide an API for guest creation (the qemu command line).
As an aside, I'd like to see all command line options have qmp
equivalents (most of them can be implemented with a 'set' command that
writes qdev values). This allows a uniform
On 03/24/2010 12:36 PM, Daniel P. Berrange wrote:
On Wed, Mar 24, 2010 at 07:17:26AM +0200, Avi Kivity wrote:
On 03/23/2010 08:00 PM, Avi Kivity wrote:
On 03/23/2010 06:06 PM, Anthony Liguori wrote:
I thought the monitor protocol *was* our API. If not, why not
On 03/24/2010 02:19 PM, Anthony Liguori wrote:
qemud
- daemonaizes itself
- listens on /var/lib/qemud/guests for incoming guest connections
- listens on /var/lib/qemud/clients for incoming client connections
- filters access according to uid (SCM_CREDENTIALS)
- can pass a new monitor to
On 03/24/2010 02:23 PM, Anthony Liguori wrote:
On 03/24/2010 05:42 AM, Avi Kivity wrote:
The filtering access part of this daemon is also not mapping well onto
libvirt's access model, because we don't soley filter based on UID in
libvirtd. We have it configurable based on UID, polic
On 03/24/2010 02:30 PM, Anthony Liguori wrote:
On 03/24/2010 07:27 AM, Avi Kivity wrote:
On 03/24/2010 02:19 PM, Anthony Liguori wrote:
qemud
- daemonaizes itself
- listens on /var/lib/qemud/guests for incoming guest connections
- listens on /var/lib/qemud/clients for incoming client
On 03/24/2010 02:30 PM, Paul Brook wrote:
On 03/23/2010 09:24 PM, Anthony Liguori wrote:
We also provide an API for guest creation (the qemu command line).
As an aside, I'd like to see all command line options have qmp
equivalents (most of them can be implemented with a 'set' comm
On 03/24/2010 02:32 PM, Anthony Liguori wrote:
You don't get a directory filled with a zillion socket files pointing
at dead guests. Agree that's a poor return on investment.
Deleting it on atexit combined with flushing the whole directory at
startup is a pretty reasonable solution to this (
On 03/24/2010 06:42 PM, Luiz Capitulino wrote:
On Wed, 24 Mar 2010 12:42:16 +0200
Avi Kivity wrote:
So, at best qemud is a toy for people who are annoyed by libvirt.
Is the reason for doing this in qemu because libvirt is annoying?
Mostly.
I don't see
how adding yet an
On 03/24/2010 10:32 PM, Anthony Liguori wrote:
So far, a libqemu.so with a flexible transport that could be used
directly by a libvirt user (ala cairo/gdk type interactions) seems
like the best solution to me.
libqemu.so would be a C API. C is not the first choice for writing GUIs
or mana
On 03/25/2010 10:26 AM, Vincent Hanquez wrote:
On 24/03/10 21:40, Anthony Liguori wrote:
If so, what C clients you expected beyond libvirt?
Users want a C API. I don't agree that libvirt is the only C
interface consumer out there.
(I've seen this written too many times ...)
How do you know
On 03/25/2010 02:33 PM, Anthony Liguori wrote:
From my point of view, i wouldn't want to write a high level
management toolstack in C, specially
since the API is well defined JSON which is easily available in all
high level language out there.
There's a whole world of C based management tools
On 03/25/2010 03:44 PM, Anthony Liguori wrote:
On 03/25/2010 07:37 AM, Avi Kivity wrote:
On 03/25/2010 02:33 PM, Anthony Liguori wrote:
From my point of view, i wouldn't want to write a high level
management toolstack in C, specially
since the API is well defined JSON which is easily avai
On 03/25/2010 03:57 PM, Anthony Liguori wrote:
On 03/25/2010 08:48 AM, Avi Kivity wrote:
But an awful lot of the providers for pegasus are written in C.
But we're concerned with only one, the virt provider. None of the
others will use libqemu?
The point is, C is a lowest c
On 03/26/2010 10:37 AM, Markus Armbruster wrote:
The importances of libqemu is:
1) Providing a common QMP transport implementation that is extensible
by third parties
2) Providing a set of common transports that support automatic
discovery of command line launched guests
3) Providing a generic
On 03/25/2010 10:18 AM, Alexander Graf wrote:
libqemu.so would be a C API. C is not the first choice for writing GUIs or
management applications. So it would need to be further wrapped.
We also need to allow qemu to control the display directly, without going
through vnc.
For the cu
On 04/22/2010 09:49 PM, Anthony Liguori wrote:
real API. Say, adding a device libvirt doesn't know about or stopping
the VM
while libvirt thinks it's still running or anything like that.
Another problem is issuing Monitor commands that could confuse
libvirt's
We need to make libvirt and qem
On 04/23/2010 04:48 PM, Anthony Liguori wrote:
On 04/23/2010 07:48 AM, Avi Kivity wrote:
On 04/22/2010 09:49 PM, Anthony Liguori wrote:
real API. Say, adding a device libvirt doesn't know about or
stopping the VM
while libvirt thinks it's still running or anything like that.
Anoth
On 04/23/2010 09:29 PM, Anthony Liguori wrote:
Maybe. We'll still have issues. For example, sVirt: if a QMP
command names a labeled resource, the non-libvirt user will have no
way of knowing how to label it.
This is orthogonal to QMP and has to do strictly with how libvirt
prepares a resou
On 04/25/2010 06:39 AM, Anthony Liguori wrote:
On 04/24/2010 04:46 AM, Avi Kivity wrote:
On 04/23/2010 09:29 PM, Anthony Liguori wrote:
Maybe. We'll still have issues. For example, sVirt: if a QMP
command names a labeled resource, the non-libvirt user will have no
way of knowing h
On 04/23/2010 09:33 PM, Anthony Liguori wrote:
This is a different ambiguity, about the semantic results of the
commands,
where as I'm refering to the execution order. If I look at a libvirt log
file and see a set of JSON commands logged, I want to know that this
ordering
from the logs, was ind
On 04/26/2010 04:53 AM, Anthony Liguori wrote:
On 04/25/2010 06:51 AM, Avi Kivity wrote:
It depends on what things you think are important. A lot of
libvirt's complexity is based on the fact that it uses a daemon and
needs to deal with the security implications of that. You don&#x
On 04/26/2010 04:14 PM, Anthony Liguori wrote:
IOW, libvirt does not run guests as separate users which is why it
needs to deal with security in the first place.
What if one user has multiple guests? isolation is still needed.
Don't confuse a management application's concept of users with
On 04/26/2010 04:46 PM, Anthony Liguori wrote:
(3) The system management application can certainly create whatever
context it wants to launch a vm from. It's comes down to who's
responsible for creating the context the guest runs under. I think
doing that at the libvirt level takes away a ton
On 04/26/2010 04:43 PM, Anthony Liguori wrote:
The reason I lean toward the direct launch model is that it gives the
user a lot of flexibility in terms of using things like namespaces,
DAC, cgroups, capabilities, etc. A lot of potential features are lost
when you do indirect launch because you
On 04/26/2010 05:19 PM, Anthony Liguori wrote:
On 04/26/2010 09:01 AM, Avi Kivity wrote:
On 04/26/2010 04:43 PM, Anthony Liguori wrote:
The reason I lean toward the direct launch model is that it gives
the user a lot of flexibility in terms of using things like
namespaces, DAC, cgroups
On 04/26/2010 05:25 PM, Chris Lalancette wrote:
Right, and you are probably one of the users this work targets. But in
general, for those not very familiar with virtualization/qemu, we want
to steer them far clear of this API. That goes doubly true for application
developers; we want them to be
On 04/26/2010 05:28 PM, Anthony Liguori wrote:
Or a library that the user-written launcher calls. Or a plugin that
qemud calls.
A plugin would lose the security context. It could attempt to
recreate it that seems like a lot of unnecessary complexity.
A plugin would create the security c
On 04/26/2010 05:48 PM, Anthony Liguori wrote:
We could easily reuse that. Any other security context code would
be custom written; so it can be written as a qemud plugin instead of
a bit of code that goes before a qemu launch.
I think we're mostly in agreement with respect to the need to
On 07/27/2010 07:38 PM, Anthony Liguori wrote:
I'm going to revert the -help changes for 0.13 so that old versions of
libvirt work but not for master.
What is the goal here? Make qemu.git explicitly be unusable via libvirt?
--
I have a truly marvellous patch that fixes the bug which this
si
On 08/25/2010 12:21 PM, Nils Cant wrote:
On 08/25/2010 10:38 AM, Gleb Natapov wrote:
qemu sends gratuitous ARP after migration. Check forward delay
setting on your
bridge interface. It should be set to zero.
Aha! That fixed it. Turns out that debian bridge-utils sets the
default to 15 for
On 08/25/2010 01:52 PM, Daniel P. Berrange wrote:
I think libvirt is doing something about this, copying list for further
info.
libvirt doesn't set a policy for this. It provides an API for
configuring host networking, but we don't override the kernel's
forward delay policy, since we don't pr
On 08/25/2010 02:15 PM, Daniel P. Berrange wrote:
So it looks like the default config uses the kernel default? If libvirt
uses an existing bridge I agree it shouldn't hack it, but if it creates
its own can't it use a sensible default?
That is the NAT virtual network. That one *does* default
On 08/25/2010 02:36 PM, Daniel P. Berrange wrote:
Can't libvirt also create a non-NAT bridge? Looks like it would prevent
a lot of manual work and opportunity for misconfiguration.
Yes, it can on latest Fedora/RHEL6, using the netcf library. This is the
new 'virsh iface-XXX' command set (and
On 08/25/2010 02:42 PM, Daniel P. Berrange wrote:
Is virt-manager able to drive this? it would be great if you could
drive everything from there.
Yes, it does now, under the menu Edit -> Host Details -> Network Interfaces
NetworkManager has also finally learnt to ignore ifcfg-XXX files whi
On 09/07/2010 04:41 PM, Anthony Liguori wrote:
Hi,
We've got copy-on-read and image streaming working in QED and before
going much further, I wanted to bounce some interfaces off of the
libvirt folks to make sure our final interface makes sense.
Here's the basic idea:
Today, you can create
On 09/07/2010 05:57 PM, Anthony Liguori wrote:
I agree that streaming should be generic, like block migration. The
trivial generic implementation is:
void bdrv_stream(BlockDriverState* bs)
{
for (sector = 0; sector< bdrv_getlength(bs); sector += n) {
if (!bdrv_is_allocated(bs, s
On 09/12/2010 03:25 PM, Anthony Liguori wrote:
On 09/12/2010 07:41 AM, Avi Kivity wrote:
On 09/07/2010 05:57 PM, Anthony Liguori wrote:
I agree that streaming should be generic, like block migration. The
trivial generic implementation is:
void bdrv_stream(BlockDriverState* bs)
{
for
On 09/12/2010 05:23 PM, Anthony Liguori wrote:
On 09/12/2010 08:40 AM, Avi Kivity wrote:
Why would it serialize all I/O operations? It's just like another
vcpu issuing reads.
Because the block layer isn't re-entrant.
A threaded block layer is reentrant. Of course pushing the th
On 09/12/2010 07:19 PM, Anthony Liguori wrote:
On 09/12/2010 11:45 AM, Avi Kivity wrote:
Streaming relies on copy-on-read to do the writing.
Ah. You can avoid the copy-on-read implementation in the block
format driver and do it completely in generic code.
Copy on read takes advantage of
On 08/11/2011 12:16 PM, Daniel P. Berrange wrote:
On Thu, Aug 11, 2011 at 11:17:09AM +0300, Avi Kivity wrote:
> On 08/10/2011 10:27 PM, Anthony Liguori wrote:
> >>This may be acceptable, wait until the entire migration cluster is
> >>xzbrle capable before enabling it.
Anthony Liguori wrote:
Right now only one monitor device can be enabled at a time. In order to support
asynchronous notification of events, I would like to introduce a 'wait' command
that waits for an event to occur. This implies that we need an additional
monitor session to allow commands to s
Paul Brook wrote:
No you don't. If you use event flags rather than discrete events then you
don't need to buffer at all. You just need to be able to store the state of
each type of event you're going to raise, which should be a bounded set.
This has its own set of issues - typically race condi
Anthony Liguori wrote:
The wait command will pause the monitor the command was issued in until a new
event becomes available. Events are queued if there isn't a waiter present.
The wait command completes after a single event is available.
How do you stop a wait if there are no pending event
Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
Right now only one monitor device can be enabled at a time. In
order to support
asynchronous notification of events, I would like to introduce a
'wait' command
that waits for an event to occur. This implies that
Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
The wait command will pause the monitor the command was issued in
until a new
event becomes available. Events are queued if there isn't a waiter
present.
The wait command completes after a single event is available.
H
Anthony Liguori wrote:
Avi Kivity wrote:
hotplug disk
-ENOSPC on disk
It's true that events don't correlate directly to commands, but they
do correlate to the state of the system and that is affected by
commands.
events are time stamped. In non-human mode, I think command
Gerd Hoffmann wrote:
On 04/09/09 16:03, Avi Kivity wrote:
I don't want multiplexed monitor sessions, at all.
I'm very happy to finally see them. Finally one can run vms with
libvirt and *still* access the monitor for debugging and development
purposes.
Right, I like the
Anthony Liguori wrote:
Timestamping doesn't help since the command could have been delayed
in the monitor socket.
Further, we're now so deep down the complexity spiral that it has now
become the most complicated piece of code in the entire system.
You certainly cannot believe that, can you
Anthony Liguori wrote:
Avi Kivity wrote:
(qemu) notify enospace on
(qemu) notify vnc-connect on
(qemu)
notification: vnc connection ...
(qemu) notify migration-completion on
(qemu) migrate -d ...
notification: enospc on ide0-0
(qemu) migrate_cancel
notification: migration cancelled
(qemu
Anthony Liguori wrote:
Avi Kivity wrote:
I'd make everything line-oriented. Anything from the user up to \n
is buffered and ignored until the \n arrives.
Once the \n arrives, the command is acted upon atomically, either
completing fully or launching an async notification.
So the
Jan Kiszka wrote:
Avi Kivity wrote:
Gerd Hoffmann wrote:
On 04/09/09 16:03, Avi Kivity wrote:
I don't want multiplexed monitor sessions, at all.
I'm very happy to finally see them. Finally one can run vms with
libvirt and *still* access the monitor for deb
Anthony Liguori wrote:
Avi Kivity wrote:
I'm sorry, I don't see why. It's just like a shell session.
Compare with:
Monitor 1:
(qemu) notify enospace on
(qemu) notify vnc-connect on
(qemu) notify migration-completion on
(qemu) migrate -d ...
(qemu) migrate_cancel
(q
Jan Kiszka wrote:
I'm not sure I understand your questions. Multiple monitor sessions are
like multiple shell sessions. I don't think a control program should
use more than one session, but it should allow a developer to connect to
issue 'info registers' and 'x/20i' commands. Of course if a de
Anthony Liguori wrote:
Avi Kivity wrote:
Suppose you have a command which changes the meaning of a
notification. If a notification arrives before the command
completion, then it happened before the command was executed.
If you want to make that reliable, you cannot have multiple monitors
Anthony Liguori wrote:
Avi Kivity wrote:
Fine, let's say we did that, it's *still* racy because at time 3,
the guest may hot remove cpu 2 on it's own since the guests VCPUs
get to run in parallel to the monitor.
A guest can't hotremove a vcpu. It may offline a vcpu, but
Anthony Liguori wrote:
Avi Kivity wrote:
(qemu) notify vnc on
... time passes, we want to allow members of group x to log in
(qemu) vnc_set_acl group:x
OK
(qemu)
notification: vnc connect aliguori
(qemu)
with a single monitor, we can be sure that the connect happened the
vnc_set_acl. If
Anthony Liguori wrote:
What's the established practice? Do you know of any protocol that is
line based that does notifications like this?
Actually there is one line oriented protocol that does asynchronous
notifications.
http://faqs.org/rfcs/rfc1459.html
--
Do not meddle in the intern
Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
IMHO, multiple monitors is a critical feature to support in the long
term.
Multiple monitors are nice to have (for developers), but I don't see
them as critical.
If you live in a world where there is a single manag
Jan Kiszka wrote:
That is true, but we'd still be considering direct monitor access to
be a 'expert' user mode of use. If they wish to shoot themselves in
the foot by triggering a migration at same time they are hotplugging
I'm fine if their whole leg gets blown away.
...while there is a
Daniel P. Berrange wrote:
Yes indeed its a little crazy :-) As anthony mentioned if libvirt were
able to be notified of changes a user makes in the monitor, there's no
reason we could not allow end users to access the monitor of a VM
libvirt is managing. We just need to make sure libvirt doesn
Daniel P. Berrange wrote:
On Tue, Apr 14, 2009 at 12:15:23PM +0300, Avi Kivity wrote:
Daniel P. Berrange wrote:
Yes indeed its a little crazy :-) As anthony mentioned if libvirt were
able to be notified of changes a user makes in the monitor, there's no
reason we could not allo
Jamie Lokier wrote:
Avi Kivity wrote:
Daniel P. Berrange wrote:
Yes indeed its a little crazy :-) As anthony mentioned if libvirt were
able to be notified of changes a user makes in the monitor, there's no
reason we could not allow end users to access the monitor of a VM
libvi
Anthony Liguori wrote:
Hollis Blanchard wrote:
On Wed, 2009-04-08 at 13:34 -0500, Anthony Liguori wrote:
Right now only one monitor device can be enabled at a time. In
order to support
asynchronous notification of events, I would like to introduce a
'wait' command
that waits for an event to
On 04/03/2011 02:57 PM, Stefan Hajnoczi wrote:
In order for media change to work with Linux host CD-ROM it is
necessary to reopen the file (otherwise the inode size will not
refresh, this is an issue with existing kernels).
Maybe we should fix the bug in Linux (and backport as necessary)?
I t
On 04/04/2011 04:38 PM, Anthony Liguori wrote:
On 04/04/2011 08:22 AM, Avi Kivity wrote:
On 04/03/2011 02:57 PM, Stefan Hajnoczi wrote:
In order for media change to work with Linux host CD-ROM it is
necessary to reopen the file (otherwise the inode size will not
refresh, this is an issue with
On 04/04/2011 06:09 PM, Stefan Hajnoczi wrote:
On Mon, Apr 4, 2011 at 2:49 PM, Avi Kivity wrote:
> On 04/04/2011 04:38 PM, Anthony Liguori wrote:
>>
>> On 04/04/2011 08:22 AM, Avi Kivity wrote:
>>>
>>> On 04/03/2011 02:57 PM, Stefan Hajnoczi wrote:
>&g
On 04/05/2011 09:41 AM, Amit Shah wrote:
See http://www.spinics.net/lists/linux-scsi/msg51504.html
I see this is quite fresh. What are the plans here?
--
error compiling committee.c: too many arguments to function
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mai
On 04/05/2011 11:09 AM, Amit Shah wrote:
On (Tue) 05 Apr 2011 [10:48:16], Avi Kivity wrote:
> On 04/05/2011 09:41 AM, Amit Shah wrote:
> >See http://www.spinics.net/lists/linux-scsi/msg51504.html
>
> I see this is quite fresh. What are the plans here?
We're still disc
On 04/05/2011 12:12 PM, Amit Shah wrote:
On (Tue) 05 Apr 2011 [12:00:38], Avi Kivity wrote:
> On 04/05/2011 11:09 AM, Amit Shah wrote:
> >On (Tue) 05 Apr 2011 [10:48:16], Avi Kivity wrote:
> >> On 04/05/2011 09:41 AM, Amit Shah wrote:
> >> >See http://ww
On 06/14/2011 04:31 PM, Corey Bryant wrote:
- Starting Qemu with a backing file
For this we could tell qemu that a file named "xyz" is available via fd
n, via an extension of the getfd command.
For example
(qemu) getfd path="/images/my-image.img"
(qemu) getfd path="/images/template.
On 06/20/2011 04:50 PM, Anthony Liguori wrote:
On 06/20/2011 08:40 AM, Avi Kivity wrote:
On 06/14/2011 04:31 PM, Corey Bryant wrote:
- Starting Qemu with a backing file
For this we could tell qemu that a file named "xyz" is available via fd
n, via an extension of the getfd com
On 06/20/2011 10:11 PM, Anthony Liguori wrote:
It would need careful explanation in the management tool author's guide,
yes.
The main advantage is generality. It doesn't assume that a file format
has just one backing file, and doesn't require new syntax wherever a
file is referred to indirectly.
On 07/20/2011 04:51 PM, Kevin Wolf wrote:
>
> The problem is that QEMU will find backing file file names inside the
> images which it will be unable to open. How do you suggest we get around
> that?
This is the part with allowing libvirt to override the backing file. Of
course, this is not so
On 08/08/2011 04:29 PM, Anthony Liguori wrote:
One thing that strikes me about this algorithm is that it's very good
for a particular type of workload--shockingly good really.
Poking bytes at random places in memory is fairly generic. If you have
a lot of small objects, and modify a subset
On 08/08/2011 04:41 PM, Alexander Graf wrote:
In general, I believe it's a good idea to keep looking at libvirt as a vm
management layer and only a vm management layer.
Very much yes.
--
error compiling committee.c: too many arguments to function
--
libvir-list mailing list
libvir-list@redha
On 08/08/2011 05:15 PM, Anthony Liguori wrote:
I think workload aware migration compression is possible for a lot of
different types of workloads. That makes me a bit wary of QEMU growing
quite a lot of compression mechanisms.
It makes me think that this logic may really belong at a higher le
On 08/08/2011 05:33 PM, Anthony Liguori wrote:
If we have a shared object helper, the thread should be maintained by
qemu proper, not the plugin.
I wouldn't call it "migration transport", but instead a
compression/decompression plugin.
I don't think it merits a plugin at all though. There's lim
On 08/08/2011 05:04 PM, Daniel P. Berrange wrote:
My main concern with all these scenarios where libvirt touches the
actual data stream though is that we're introducing extra data copies
into the migration path which potentially waste CPU cycles.
If QEMU can directly XBZRLE encode data into the F
On 08/10/2011 10:27 PM, Anthony Liguori wrote:
This may be acceptable, wait until the entire migration cluster is
xzbrle capable before enabling it. If not, add a monitor command.
1) xzbrle needs to be disabled by default. That way management tools
don't unknowingly enable it by not passing
1 - 100 of 110 matches
Mail list logo
