Avi Kivity wrote:
> On 11/09/2009 09:35 PM, Jamie Lokier wrote:
> >
> >What I'd like to know is, if all of QEMU's state is appropriately
> >recreated in the child instance, and KVM's device is reopened with a
> >copy of the kvm state (by using the recently introduced ioctls to get
> >and set it), w
On 11/09/2009 09:35 PM, Jamie Lokier wrote:
What I'd like to know is, if all of QEMU's state is appropriately
recreated in the child instance, and KVM's device is reopened with a
copy of the kvm state (by using the recently introduced ioctls to get
and set it), will it fork the _guest RAM_ mappe
Avi Kivity wrote:
> On 11/07/2009 12:44 PM, Jamie Lokier wrote:
> >Aiee - what's the plan? Can a running KVM be forked, as in into two
> >separate processes to run the forked guests in parallel, or not?
>
> kvm fds do not support fork(). Nothing prevents you from stopping the
> guest, reading g
On Fri, Nov 06, 2009 at 08:26:29PM +, Jamie Lokier wrote:
> But imho it'd be far nicer not to have "specialness" like that unless
> you want it for some positive reason like security.
OTOH, if you do want this for security, there's currently no
way to do this besides using raw sockets + macvla
On 11/08/2009 12:12 AM, Anthony Liguori wrote:
Arnd Bergmann wrote:
Well, the difference matters from a security perspective. The sudo
script that Avi suggested just means that you can guarantee you don't
introduce any security holes through a suid executable. Fortunately,
it does not impact the
Arnd Bergmann wrote:
Well, the difference matters from a security perspective. The sudo
script that Avi suggested just means that you can guarantee you don't
introduce any security holes through a suid executable. Fortunately,
it does not impact the contents of your helper either, only the
instal
On Saturday 07 November 2009, Anthony Liguori wrote:
> Avi Kivity wrote:
> > On 11/07/2009 11:14 AM, Avi Kivity wrote:
> >> I'd welcome -net bridge as one of them. But we shouldn't try to
> >> invent access control systems or install suid helpers.
> >
> > We can make the helper a script that does
Avi Kivity wrote:
On 11/07/2009 11:14 AM, Avi Kivity wrote:
I'd welcome -net bridge as one of them. But we shouldn't try to
invent access control systems or install suid helpers.
We can make the helper a script that does
exec sudo /the/real/helper "$@"
so a user can add it to /etc/sudoers
Avi Kivity wrote:
Running qemu directly from the command line is absolutely an
important use case.
Where does this requirement come from?
For most of qemu's lifetime, this was the only option. The current
graphical front ends only support a subset of qemu's features and qemu's
target arch
Avi Kivity wrote:
So it's equivalent to enabling dirty tracking during live migration.
In my mind, if the cost associated with hot plug is a fraction of the
cost of live migration, we're in good shape.
I don't see why. Live migration is pretty expensive, but that doesn't
mean NIC hotplug sh
On 11/07/2009 12:44 PM, Jamie Lokier wrote:
Aiee - what's the plan? Can a running KVM be forked, as in into two
separate processes to run the forked guests in parallel, or not?
kvm fds do not support fork(). Nothing prevents you from stopping the
guest, reading guest state, fork()ing, an
Avi Kivity wrote:
> So vfork() is required, or in light of its man page and glowing
> recommendations from the security people,
vfork() on Linux is fine to use, as long as you respect it's unwritten
requirements :-)
In a multithreaded program: you can start by spawning a thread for the
sole purp
On 11/07/2009 11:14 AM, Avi Kivity wrote:
I'd welcome -net bridge as one of them. But we shouldn't try to
invent access control systems or install suid helpers.
We can make the helper a script that does
exec sudo /the/real/helper "$@"
so a user can add it to /etc/sudoers and get pre-authen
On 11/06/2009 06:09 PM, Anthony Liguori wrote:
No, it's an argument against fork() of large programs.
After putting together a work around, I'm starting to have my doubts
about how real of a problem this is.
You're only write protecting memory, correct?
The kernel write protects qemu me
On 11/06/2009 04:19 PM, Anthony Liguori wrote:
Avi Kivity wrote:
Instead of doing silly things into qemu, if there is concern about
this, then it should be fixed in Linux properly.
Of course there is concern about it, and you don't have to do
anything silly to qemu to avoid it. Just not call
On 11/06/2009 02:29 AM, Anthony Liguori wrote:
Helpers are really bad. On launch, I find the fragile and hard to do
proper error handling with (but that's probably just me). But the
real problem is at runtime, if you have a 16GB guest then you have to
write-protect 4M ptes and then kvm has to
On 11/05/2009 09:58 PM, Anthony Liguori wrote:
Avi Kivity wrote:
Helpers are really bad. On launch, I find the fragile and hard to do
proper error handling with (but that's probably just me). But the
real problem is at runtime, if you have a 16GB guest then you have to
write-protect 4M ptes
Avi Kivity wrote:
> I don't see why you consider placing functionality in the
> management stack vs qemu user hostile, considering who our users are.
Do you mean that virtually all users use a management stack?
-- Jamie
Avi Kivity wrote:
> On 11/05/2009 06:50 PM, Anthony Liguori wrote:
> >>I'm worrying that we're transforming one problem into two different
> >>ones. Expanding the scope of qemu, and making it more difficult to
> >>use advanced networking functionality.
> >
> >
> >Do you object to the idea of hav
Avi Kivity wrote:
> On 11/05/2009 07:16 PM, Scott Tsai wrote:
> >On Fri, Nov 6, 2009 at 12:50 AM, Anthony Liguori
> >wrote:
> >
> >>It's just a bit annoying to create an entire new
> >>project for a few hundred line helper.
> >>
> >This new project would also be a better place for 'tunctl
Avi Kivity wrote:
> On 11/05/2009 05:59 PM, Anthony Liguori wrote:
> >Avi Kivity wrote:
> >>On 11/05/2009 05:11 PM, Daniel P. Berrange wrote:
> >>>The main problem is that we've never really used the 'session'
> >>>instances,
> >>>since networking configs are rather limited to pretty much just SLI
Daniel P. Berrange wrote:
> On Thu, Nov 05, 2009 at 11:03:48AM -0600, Anthony Liguori wrote:
> > Daniel P. Berrange wrote:
> > >Indeed the hotplug scenario is a bit of a problem in this model,
> > >since libvirt needs to be able to setup iptables & ebtables rules
> > >between creating the device &
Michael S. Tsirkin wrote:
> On Thu, Nov 05, 2009 at 04:12:36AM +, Jamie Lokier wrote:
> > I notice that if we eventually teach the kernel to have unnamed
> > bridges (just attach interfaces to each other), only the helper
> > commands will need changing to use it :-)
>
> What do you mean by "a
Daniel P. Berrange wrote:
> On Thu, Nov 05, 2009 at 04:41:45PM +, Jamie Lokier wrote:
> > Anthony Liguori wrote:
> > > Absolutely. I wanted to not have a hard dependency on PolicyKit to
> > > start out with but that's always been the plan. I'd like to eventually
> > > add an optional Policy
Anthony Liguori wrote:
> Avi Kivity wrote:
> >Helpers are really bad. On launch, I find the fragile and hard to do
> >proper error handling with (but that's probably just me). But the
> >real problem is at runtime, if you have a 16GB guest then you have to
> >write-protect 4M ptes and then kvm
Avi Kivity wrote:
On 11/05/2009 07:20 PM, Arnd Bergmann wrote:
On Thursday 05 November 2009, Anthony Liguori wrote:
It'd still install the default helper you've provided and use it by
default, of course.
That's already how it behaves. You can say -net
bridge,helper=/usr/local/bin/
Avi Kivity wrote:
Helpers are really bad. On launch, I find the fragile and hard to do
proper error handling with (but that's probably just me). But the
real problem is at runtime, if you have a 16GB guest then you have to
write-protect 4M ptes and then kvm has to tear down or write protect
Arnd Bergmann wrote:
On Thursday 05 November 2009, Anthony Liguori wrote:
How about abstracting it further and not making the helper depend on
bridge code. If we put the helper into netcf, we could make that
a more generic '-net netcf,helper=/usr/bin/netcf-helper' target,
...
Whether
Alexander Graf wrote:
Well I'm not that familiar with the bridging stuff as I'm rather scared
by it myself, but last time I tried if I
# brctl addif br0 eth0
# ifconfig br0 up
eth0 stopped working, so I had to stop network manager, assign an IP to
br0 manually and hope network manager doesn't k
Anthony Liguori wrote:
> Alexander Graf wrote:
>> Yeah. Worse than the "run as root" part is the "it's hard" part
>> though. I hate how I feel when I try to explain someone how to use
>> non-slirp networking :-(.
>>
>> The response to that is then usually "oh whatever, it's too
>> complicated anywa
Alexander Graf wrote:
Yeah. Worse than the "run as root" part is the "it's hard" part
though. I hate how I feel when I try to explain someone how to use
non-slirp networking :-(.
The response to that is then usually "oh whatever, it's too
complicated anyways".
I agree and it's a problem I w
On 04.11.2009, at 01:28, Anthony Liguori wrote:
This series solves a problem that I've been struggling with for a
few years now.
One of the best things about qemu is that it's possible to run
guests as an
unprivileged user to improve security. However, if you want to have
your guests
comm
This series solves a problem that I've been struggling with for a few years now.
One of the best things about qemu is that it's possible to run guests as an
unprivileged user to improve security. However, if you want to have your guests
communicate with the outside world, you're pretty much forced
33 matches
Mail list logo
