at it's doing
(either by default or with your config) to prevent that and then go
from there.
--
Dan Smith
IBM Linux Technology Center
email: da...@us.ibm.com
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
This patch adds the getHostname method to the lxc driver structure
(using the qemu driver's generic code). Apparently virsh started
using that method during console attachment recently. Without this
implementation, the virsh refused to attach to lxc consoles.
Signed-off-by: Dan Smith
--
DV> sorry for the delay, please push !
Done. Thanks!
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
type. The LXC driver is made to allow major type 136
DS> as a result.
Were there any comments on this set? I think it would be nice to get
it into the tree sooner than later so we at least have resource
controls on containers :)
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor
DB> You didn't read the previous mail in this sequence :-P
Indeed. The temperamental mail servers have only graced me with 1, 4,
and 5 so far. I should have checked the archives.
Aside from the other issue, I'm fine with the patch :)
Thanks!
--
Dan Smith
IBM Linux Technolog
active = 1;
DB> +virDomainUnlock(lxc_driver->domains.objs[i]);
DB> +}
DB> -/* Otherwise we're happy to deal with a shutdown */
DB> -return 0;
DB> +return active;
DB> }
It looks to me like you're taking the driver lock and not releas
hat doesn't fit very well into the libvirt API semantics, IMHO :)
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
ll policy, I can
still add arbitrary items to devices.allow and gain access from a
subgroup. So, I think we're going to need to restrict CAP_SYS_ADMIN
if we really want isolation, but I'm not sure what else that is likely
to break.
--
Dan Smith
IBM Linux Technology Center
Open Hypervi
Without this, our container child doesn't actually end up in the cgroup,
and thus runs unrestricted. Note that this does not address the container's
ability to mount cgroup and move itself into the parent namespace.
While making this change, it became clear that we need to allow access to
the ent
This interface provides a way to allow an entire major device type
diff -r 388beff59a32 -r 48a9209668ab src/cgroup.c
--- a/src/cgroup.c Wed Oct 15 10:33:01 2008 +
+++ b/src/cgroup.c Thu Oct 16 14:01:13 2008 -0700
@@ -761,6 +761,36 @@
return rc;
}
+/**
+ * virCgroupAllowDevice
This set moves the cgroup creation before that of the container process,
thus ensuring that it is put in the cgroup as well. As a result, I noticed
that we need to allow device access to /dev/pts/*, and thus added a cgroup
mechanism to allow a whole major device type. The LXC driver is made to
al
ooks like we need to explicitly set the capabilities of
DB> containers to either mask out CAP_SYS_ADMIN from libvirtd's set,
DB> or construct an explicit capability whitelist
Yeah, I guess so. I'll start looking into this :)
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
This patch maintains the two Xen-specific --weight and --cap options,
but adds support for setting arbitrary parameters by specifying them in
param=value syntax.
Changes to the virsh manual are included.
Changes:
- Replace use of 'a' conversion modifier with pre-alloc
diff -r 51fd150edd42 -r e4
DV> a is not part of C89, that's an extension to the standard if i believe
DV> the linux man page. I would rather avoid a portability problem here
Oh, right, I always forget about that. I'll send a replacement.
Thanks!
--
Dan Smith
IBM Linux Technology Center
Open Hyper
This patch maintains the two Xen-specific --weight and --cap options,
but adds support for setting arbitrary parameters by specifying them in
param=value syntax.
Changes to the virsh manual are included.
diff -r 51fd150edd42 -r aae58f42bd4a docs/virsh.pod
--- a/docs/virsh.podTue Oct 07 11:45:
ce of SCHED_FIFO,
DB> SCHED_RR, SCHED_OTHER, etc be a tunable parameter.
Okay, sounds good. I'll change it.
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
pgpzbvUbw2YkC.pgp
Description: PGP signature
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
name is correct by calling 'virDomainGetSchedularParams' to
DB> see what are available.
I can do that, but since the CIM providers don't depend on virsh for
this, can we move forward with the first two patches before we get
this fixed up?
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
This set adds {Get,Set}SchedulerParameters support to the LXC driver. A
single parameter of "cpu_shares" is added, which gets/sets the cpu.shares
key in the domain's cgroup.
I also added bits to "virsh schedinfo" to support this.
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.red
diff -r ebecbe5caa03 -r b07cd92a30e9 src/virsh.c
--- a/src/virsh.c Tue Oct 07 08:21:50 2008 -0700
+++ b/src/virsh.c Tue Oct 07 08:21:50 2008 -0700
@@ -1114,6 +1114,7 @@
{"domain", VSH_OT_DATA, VSH_OFLAG_REQ, gettext_noop("domain name, id or
uuid")},
{"weight", VSH_OT_INT, VSH
This brings get/set of U64 out of the #if 0, which looks messier than it is.
diff -r 64f19f607bc6 -r 6fb284fa200a src/cgroup.c
--- a/src/cgroup.c Fri Oct 03 17:58:02 2008 +
+++ b/src/cgroup.c Tue Oct 07 08:21:49 2008 -0700
@@ -224,26 +224,6 @@
return rc;
}
-#if 0
-/* This is
diff -r 6fb284fa200a -r ebecbe5caa03 src/lxc_driver.c
--- a/src/lxc_driver.c Tue Oct 07 08:21:49 2008 -0700
+++ b/src/lxc_driver.c Tue Oct 07 08:21:50 2008 -0700
@@ -35,6 +35,7 @@
#include
#include
+#include "internal.h"
#include "lxc_conf.h"
#include "lxc_container.h"
#include "lxc_driv
DV> IMHO, no need, pushing to CVS and fixing things from there will be
DV> simpler,
Done, thanks!
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
pgpjua9W2BsOk.pgp
Description: PGP signature
--
Libvir-list mailing list
Libvir-list@redhat.com
spam the list with another set? :)
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
pgpPAu8CDLjmP.pgp
Description: PGP signature
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Why not use meaningful names see sys/stat.h
I don't think that the meaningful names in sys/stat.h lead to better
readability, personally. Octal permissions are used elsewhere int the
code pretty extensively, so I'm comfortable with this as it is.
--
Dan Smith
IBM Linux Technology C
ey should be somewhere other than cgroup.h?
If not, I think it might be appropriate to make that change in a
separate patch, since populating /dev isn't really cgroup-related.
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
pgpck5elXVqx7.pgp
Descripti
This patch adds code to the controller to set up a cgroup named after the
domain name, set the memory limit, and restrict devices. It also
adds bits to lxc_driver to properly clean up the cgroup on domain death.
If virCgroupHaveSupport() says that no support is available, then we just
allow the d
c/cgroup.c Fri Oct 03 08:06:52 2008 -0700
@@ -0,0 +1,762 @@
+/*
+ * cgroup.c: Tools for managing cgroups
+ *
+ * Copyright IBM Corp. 2008
+ *
+ * See COPYING.LIB for the License of this software
+ *
+ * Authors:
+ * Dan Smith <[EMAIL PROTECTED]>
+ */
+#include
+
+#include
+#include
+#in
Revision 3 of the cgroups patch, with the round 2 comments addressed.
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
g to improve or debug that code in the future ;-)
Okay, I suppose that if the QEMU driver ends up doing something
similar, the constants would be reused.
Should they go in cgroup.h since they're expected to be used with that
interface?
--
Dan Smith
IBM Linux Technology Center
Open Hyperviso
s to get to the function implementation you see the
DV> comment immediately but it's cosmetic).
Okay, that's a good point. I will just move the comment block to the
.c file.
Thanks!
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
pgpnGd
DB> Both, Xen and QEMU drivers support a virt type of 'hvm'.
Ah, gotcha. I didn't realize that just looking at the enum. I've
changed it locally.
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
pgpewM4wFGN22.pgp
Description:
OMAIN_NAME
Hmm, I'm not sure I follow. It seems like the virt type offers more
uniqueness than driver name.
Either way, I have no problem making this change :)
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
pgp7icmruQasl.pgp
Description: PGP signatu
the error path to cleanup
DB> a partially constructed cgroup ?
Yep, I'll fix that too.
Thanks!
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
pgpCrdzpJFR1t.pgp
Description: PGP signature
--
Libvir-list mailing list
Libvir-list@redhat.com
https:/
This patch adds code to the controller to set up a cgroup named after the
domain name, set the memory limit, and restrict devices. It also
adds bits to lxc_driver to properly clean up the cgroup on domain death.
If virCgroupHaveSupport() says that no support is available, then we just
allow the d
c/cgroup.c Wed Oct 01 13:16:03 2008 -0700
@@ -0,0 +1,705 @@
+/*
+ * cgroup.c: Tools for managing cgroups
+ *
+ * Copyright IBM Corp. 2008
+ *
+ * See COPYING.LIB for the License of this software
+ *
+ * Authors:
+ * Dan Smith <[EMAIL PROTECTED]>
+ */
+#include
+
+#include
+#include
+#in
This is my updated set for cgroup manipulation. I think I have addressed
all of the concerns and comments so far. There are no major caveats I'm
aware of with this round.
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
ns
DB> virCGroupDenyAllDevices(cg);
DB> # Allow access to /dev/null device
DB> virCGroupAllowDevice(cg, 3, 1)
DB> Some of the existing APIs could be made static since they'd be
DB> needed anyway, but some could be re-design to be tailored to
DB> the semantics we want.
Okay, I'll res
it
Perhaps we can:
- Have a list of controllers we use (memory and devices so far)
- Create each group in all mounts required to satisfy our necessary
controllers
- Select the appropriate mount when setting a cont.key value
It will muck things up a bit, but I think it might be doable.
--
them out :)
I'm thinking that mounting the controllers we care about at daemon
startup (as mentioned above) would solve both of these issues as well.
Does anyone have an opinion on taking that approach?
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
p
This patch adds code to the controller to set up a cgroup called
libvirt/lxc/$name, set the memory limit, and restrict devices. It also
adds bits to lxc_driver to properly clean up the cgroup on domain death.
If virCgroupHaveSupport() says that no support is available, then we just
allow the doma
: Tools for managing cgroups
+ *
+ * Copyright IBM Corp. 2008
+ *
+ * See COPYING.LIB for the License of this software
+ *
+ * Authors:
+ * Dan Smith <[EMAIL PROTECTED]>
+ */
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#inc
This patch set adds basic cgroup support to the LXC driver. It consists of
a small internal cgroup manipulation API, as well as changes to the driver
itself to utilize the support. Currently, we just set a memory limit
and the allowed devices list. The cgroup.{c,h} interface can be easily
redire
h an internal
mini-implementation is a sane thing to do at this point to get working
cgroup support in a timely fashion. When the libcgroup API and
functionality settles a bit, it should be easy to start using it.
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROT
lly going to provide such a layer, and thus would
(as you put it) become nothing but a problematic dependency.
Perhaps it makes the most sense to implement a bit of cgroup support
directly into libvirt to satisfy our current needs while we wait to see
if libcgroup matures?
--
Dan Smith
IBM L
7;t know exactly can you tell me who to contact to assure this?
The list for libvirt-cim is here:
https://www.redhat.com/mailman/listinfo/libvirt-cim
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
pgpaTfe6dD1nA.pgp
Description: PGP signature
--
Libv
s own check. Since you mentioned the need for the
user to specify a list of allowable checks, perhaps "ask the hypervisor
too" could be one of those.
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
pgpSwMH7W9SYM.pgp
Description: PGP signatur
This patch adds an implementation of the version function to the LXC driver.
The providers use the hypervisor version in a field of one of the instances,
so we need to have something meaningful here. AFAICT, the only real option
we have (considering the limitations of the libvirt version informati
w
DB> echo "c 1:9 rwm" > /dev/cgroups/libvirt/lxc/{NAME}/devices.allow
Adding this functionality to what I have should be rather trivial, I
think.
I'm still working with the libcgroup folks to get some kinks ironed out,
but I will post the patches when we get something tha
DB> I found a couple of other places with missing lxcError() calls. So
DB> here's an updated patch
Looks good to me. Thanks!
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
pgpCX4VhfZj4e.pgp
Description: PGP signature
--
Libvir-list mailing
t rolls completely up the stack with
no error information getting logged. Since you have the excellent
per-container logging functionality, can we increase the verbosity a
little so that there is some way to diagnose where things are failing?
Thus far, I've just started sprinkling fprintf()
DB> All my patches for LXC with exception of the pivot_root stuff are
DB> now commited, so this is good to commit.
Done.
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
pgpg7jtngAkLp.pgp
Description: PGP signature
--
Libvir-list mailing list
Libvi
This makes sure to delete veth devices after we've killed the container.
In the case of a destroy or crash, this ensures the system is cleaned
up properly.
To be applied atop Daniel Berrange's current LXC patch stack.
diff -r b18ae864eb98 -r cd0bd9a6288a src/lxc_driver.c
--- a/src/lxc_driver.c W
ng the libvirtd LXC driver do cleanup of
DB> veths too, as a safety net.
Agreed.
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
pgpDNufOLvBy1.pgp
Description: PGP signature
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
+continue;
DB> +rc = mount(tmp->src,
DB> + tmp->dst,
DB> + NULL,
DB> + MS_BIND,
DB> + NULL);
DB> +if (0 != rc) {
DB> +lxcErro
l about a reference count on
the fake 'lo' interface for the container. However, I get that some of
the time in the original code as well, so I don't see any reason holding
this stuff up any further, and I will see about tracking that down.
Thanks!
--
Dan Smith
IBM Linux Technology
only current devices, but not device names already planned for the other
half of a container's device pair. Thus, the search can result in attempting
to create a pair of devices such as veth1 and veth1, which obviously does
not work.
This patch augments the logic to be a little smarter in this re
ical in root cause to what I was seeing with the
previous set of patches, and was unable to figure out why file
descriptor 6 was getting prematurely closed. I'll get started on
debugging it again tomorrow, but it might be good if you can reproduce
it as well :)
--
Dan Smith
IBM Linux Technol
egative" here, which makes the start process not notice some
of the failure paths in that function, and thus will erroneously
return success.
In general, I think this is an excellent approach, but I don't really
like how many (dozens of) failure points there are in the controll
re-factoring of the way the TTYs and control socket are handled to
DB> prepare for the switchover.
I haven't tested it yet (I can do that tomorrow), but this looks fine
to me :)
Thanks!
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
pgpUqh
AS> May I commit this patch for MinGW compilation? veth.c is not
AS> necessary for MinGW.
Yep, looks okay to me :)
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
pgpzuL9xSI6Jh.pgp
Description: PGP signature
--
Libvir-list mailing list
Libvi
Also remove a stale comment in the area. This makes libvirt compile when
passed --with-lxc and --enable-compiler-warnings=error
diff -r bd08a3f22fb2 -r fa048279476d src/veth.c
--- a/src/veth.cThu Jun 26 16:09:48 2008 +
+++ b/src/veth.cFri Jun 27 06:48:10 2008 -0700
@@ -192,14
DV> in that case the = NULL; are superfluous as they are local
DV> variables, but i assume the compiler optimizes this easilly :-)
Removed.
DV> Looks fine +1 once the two leaks are plugged :-)
Fixed. I'll go ahead and push these into CVS.
Thanks!
--
Dan Smith
IBM Linux Tec
DL> So the container is supposed to stay alive until we explicitly
DL> shutdown it, right ?
It is supposed to, yes. If it dies early, we catch it with the signal
handler and do the cleanup. If it's terminated by the user, we do the
cleanup as part of the termination process.
--
Da
plementation, which may or may not be present in a subsequent
revision.
DL> But again, you can ignore that, if you prefer to use the 'ip'
DL> command.
When it really comes down to it, it doesn't matter if the kernel
support is present if the user doesn't have an updated
DL> Is it called when the last process of the container dies ?
Yes, it (lxcVMCleanup()) is called from lxcSigHandler() which gets run
if the container dies unexpectedly. It's also called from
lxcDomainDestroy() which covers the 'shutdown' and 'destroy' cases as
we
y the return code of the
DL> command.
You're still scraping the output, just pushing the burden for doing so
onto grep. But, fair enough :)
DL> Anyway, catching a specific return code for an unknown subcommand
DL> makes sense for this check.
Okay, cool.
--
Dan Smith
IBM Linux
ically at the driver
probe stage. I'll let him comment on his preferred way of doing that.
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
pgpmeZLY1dUi4.pgp
Description: PGP signature
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
hat.com/archives/libvir-list/2008-June/msg00232.html
Thanks!
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
pgpbFnsnVjeVY.pgp
Description: PGP signature
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Changes:
- Remove extraneous "i" variables from various functions
- Only bring up lo if we have other interfaces (and thus NETNS)
- Fail setup of interfaces if NETNS support is not present
- Only add CLONE_NEWNET to start flags if domain has interfaces defined
- Make lxc_vm_t parameters const
Changes:
- Throw an error after parsing if nets were specified and NETNS support
is not present
diff -r 203dce381784 -r bb48967cf19e src/lxc_conf.c
--- a/src/lxc_conf.cMon Jun 23 11:53:42 2008 -0700
+++ b/src/lxc_conf.cMon Jun 23 11:53:45 2008 -0700
@@ -69,6 +69,190 @@
__virRaiseE
This gives us the ability to create a veth pair so that we can move one
into the network namespace of an LXC container.
Changes from last time:
- Fixed use of sprintf()
- Fixed up 'ip link...' argument synthesis
- Fixed license headers
- Fixed while() {...} to do {...} while()
- Fixed copying
Allow check for containers support to be done without CLONE_NEWNET, and then
determine support on the fly by checking for iproute2 support and a
successful clone(CLONE_NEWNET). This lets us set a flag for later, as well
as not completely disable LXC support on a system without NETNS support.
diff
I think I have addressed all of the comments. Changes detailed per patch.
I converted to using a dynamic detection routine for determining NETNS
support, which I think is much better. That is pulled out into a separate
patch for easier distinction.
Thanks!
--
Libvir-list mailing list
Libvir-li
ng.
A *very* quick look in src/*.c doesn't reveal any other examples of
all-literal argv[] lists like this. I'm inclined to leave the const
and the cast, but if you have a better suggestion, I'll be glad to
make the change.
Thanks!
--
Dan Smith
IBM Linux Technology Center
Open Hy
ck with him
to see if there's something we're missing. It's probably worth a
comment if so.
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
pgpP69YKohLy3.pgp
Description: PGP signature
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
x27;s the point of saving return value in "rc" if the very
JM> next statement is going to overwrite that value? Either test it,
JM> or add a comment saying why it's ok to ignore failure, in which
JM> case don't clobber the previous value.
I think the comment above
s for the HG headers. I forgot the --plain when I sent it
out...
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
pgpQ4fsElwxWG.pgp
Description: PGP signature
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Authors:
DV> * David L. Leskovec
DV> */
DV> as the header template for the two new files to match the other files.
DV> COPYING.LIB is of course LGPL 2.1
Okay, I'll change it.
Thanks!
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
# HG changeset patch
# User Dan Smith <[EMAIL PROTECTED]>
# Date 1213891185 25200
# Node ID cb780a7b3ad591f1a9392d6528218b3aa2c3483d
# Parent acf369a2543ad52b235ae8541c8ad05670e255bd
[LXC] Add setup/cleanup of container network interfaces
diff -r acf369a2543a -r cb780a7b3ad5 src/lxc_conf.h
# HG changeset patch
# User Dave Leskovec <[EMAIL PROTECTED]>
# Date 1213891177 25200
# Node ID acf369a2543ad52b235ae8541c8ad05670e255bd
# Parent 386c067de8995028dd11f70602081c31682dd293
[LXC] Add XML parsing of container network interfaces.
diff -r 386c067de899 -r acf369a2543a src/lxc_conf.c
---
# HG changeset patch
# User Dave Leskovec <[EMAIL PROTECTED]>
# Date 1213891164 25200
# Node ID 386c067de8995028dd11f70602081c31682dd293
# Parent 8d2afc533c91c4796512e1e71c8283e86eafd18a
[LXC] Add functions to manage veth device pairs
This gives us the ability to create a veth pair so that we can
This set is actually authored by Dave Leskovec. He is moving on to some other
work and I will be working this into the tree. I have made a few changes
to this, mostly to allow this code to compile out if the proper kernel
and userspace support is not present.
I am submitting it as an RFC because
ders, we can ignore (or handle) "not supported" properly,
but "XML not well-formed" is a more fatal error, indicating a problem
with the providers. The fewer this-is-kvm-so-only-cdroms-are-dynamic
special cases we have, the better :)
--
Dan Smith
IBM Linux Technology Ce
on of not specifying the IP address in the XML.
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
pgpaYc3gTt3XL.pgp
Description: PGP signature
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
being in the daemon would allow the console
forwarding to happen there instead of being duplicated in every
container. I don't really like the idea of having a forwarding
process in every container as the parent of the container init.
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor T
setup can be performed as part of the immediate child and
then do the second fork to achieve the isolation (if desired)?
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
pgpuRqBXTGoTI.pgp
Description: PGP signature
--
Libvir-list mailing list
Libvir-list@red
tml
Looking at the 0.4.1 release notes and the thread, I'm not sure if it
actually got applied.
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
pgpY9meMAvMef.pgp
Description: PGP signature
--
Libvir-list mailing list
Libvir-list@redhat.com
https:
sk
snapshots of QEMU machines.
This is something that we definitely would like to be able to support
in the CIM providers when it's available in libvirt. There is already
a DMTF model around providing this sort of functionality.
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor T
DV> this patches fixes it by checking the newer sysctl versions when
DV> initializing the driver.
This fixes my problem on Xen 3.2.
Thanks!
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
pgpwgkvoaW3dr.pgp
Description: PGP signature
--
Libvi
seems less suited there.
But from libvirt's perspective, it's still a virtual machine(-like)
entity, regardless of what is really running inside.
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
pgpTx2iQ1VEmI.pgp
Description: PGP signature
--
Lib
DL> That makes sense to me. I guess I'd lean towards leaving
DL> in the container block since a container isn't really starting a
DL> new os image. Perhaps Dan Smith has some comments on this...
Oh I *always* have some comments... :)
From the above example, would be
r
of a change.
Is there any reason not to also allow setting the default URI in an
environment variable to solve the dual-hypervisor problem?
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
pgpjVT7Wc4yqR.pgp
Description: PGP signature
--
Libvir-list
ld say "create me a new var,
based on this other existing var over here".
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
pgpqnd0jVy5m7.pgp
Description: PGP signature
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
t it will
give us a way to associate the path provided for a mount to a storage
pool.
[*] provisioning in the containers case would be a recursive directory
copy of a template overlay directory, which is what Dan was saying
he didn't want to do
--
Dan Smith
IBM Linux Technology Cen
I.
Agreed.
DB> Perhaps simply the ability to 'clone' an existing directory
DB> (populated from source external soure, or off NFS) would be
DB> sufficient for populating containers ?
Sounds reasonable to me. :)
Maybe Dave L. can chime in here with any thoughts he may have?
e that
anything in the infrastructure you're adding would prevent such an
implementation down the road, but I just thought I'd bring it up.
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
pgpZ1cdsdDSyQ.pgp
Description: PGP signature
--
Libvir-list mai
* Provides the connection pointer associated with a storage poolk. The
^
Typo.
Don't you just hate completely superficial responses such as this
one? :)
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTE
f network config, and specifically this IP address, is a
characteristic property of the container itself. That seems strange
to me. Should this be under so we can represent more than
one interface?
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
pgpuBByP8cQQC
irt perspective, most people would be interested in having an
init-like process structure within their containers. Thus, I would
vote for using over or .
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
pgpydcMD77cAA.pgp
Description: PGP signature
--
Lib
DEVICE_RW_FORCE imply knowledge of Xen-specific behavior?
How would you handle someone wanting to use tcp:// or ssh:// with
qemu?
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
pgpsRaQZEZG6G.pgp
Description: PGP signature
--
Libvir-list mailing list
Libvir-
1 - 100 of 110 matches
Mail list logo
