Shuveb Hussain wrote:
[...]
OK, but still let us know if there are particular things which are a
problem to parse.
Also if you can just follow-up sometime with example output from OpenVZ
commands. I'd like to see that, since I tried to get OpenVZ working on
my machine, but it broke down (un
Shuveb Hussain wrote:
Hi Daniel,
Oh at the C level, definitely ! The python layer is really only a
language
binding wrapper and should remain that way ! Even if we fork as a new
process
the python side of libvirt is packaged separately, and really the core
should
be written in C, this would
On Thu, Jul 05, 2007 at 02:32:27PM +0530, Shuveb Hussain wrote:
> > I would really prefer C so we can merge daemon code if needed.
> >I know a bit about textual parsing, I'm not afraid by this, in my
> >experience doing proper pipe protocol is way harder and we have that
> >working which you can r
I would really prefer C so we can merge daemon code if needed.
I know a bit about textual parsing, I'm not afraid by this, in my
experience doing proper pipe protocol is way harder and we have that
working which you can reuse nearly as is.
OK Daniel. I'm taking in your suggestions and starting
On Thu, Jul 05, 2007 at 02:06:08PM +0530, Shuveb Hussain wrote:
> Hi Daniel,
>
> > Oh at the C level, definitely ! The python layer is really only a
> > language
> >binding wrapper and should remain that way ! Even if we fork as a new
> >process
> >the python side of libvirt is packaged separa
Hi Daniel,
Oh at the C level, definitely ! The python layer is really only a language
binding wrapper and should remain that way ! Even if we fork as a new process
the python side of libvirt is packaged separately, and really the core should
be written in C, this would also allow to merge back
On Thu, Jul 05, 2007 at 12:28:40PM +0530, Shuveb Hussain wrote:
> >>> Daemon though? Can't the libvirt code just invoke the OpenVZ commands
> >>> directly?
> >>
> >> Yeah, that is very much possible. But if it were a daemon, it could be
> >> a Python daemon, since text processing is much simpler a
Hello,
>> Daemon though? Can't the libvirt code just invoke the OpenVZ commands
>> directly?
>
> Yeah, that is very much possible. But if it were a daemon, it could be
> a Python daemon, since text processing is much simpler and I don't
> have to use the str*( ) funcs in C. What is your comment
Shuveb Hussain wrote:
Daemon though? Can't the libvirt code just invoke the OpenVZ commands
directly?
Yeah, that is very much possible. But if it were a daemon, it could be
a Python daemon, since text processing is much simpler and I don't
have to use the str*( ) funcs in C. What is your comm
Shuveb Hussain wrote:
There is the same problem with the Xen libraries. Dan had to rewrite a
lot of code concerning access to the hypervisor.
No matter how different I think, the end result looks just like the
OpenVZ library code :-P
So, I'm trying to write code that looks different, but does
Hi,
Did you have any code to support OpenVZ that I can look at? I was
looking at how OpenVZ concepts map to libvirt concepts, and don't want
to duplicate your efforts.
Work has slowed down recently, but I have the very basic stuff up.
Listing of VMs works and VM creation support is partially
Shuveb Hussain wrote:
Hi,
I am adding OpenVZ support to Libvirt and work is progressing well.
I'm able to list VM instances and I'm slowly trying to cover the basic
API functions one by one. That brings us to the creation of OpenVZ
based VMs. Just wanted to discuss the basic XML definition forma
Hi Rich,
I think again we're entering into territory where virt-manager and other
clients need to "just know" about the XML format and other quirks of the
particular libvirt driver. That's not a high-level virtualisation API.
I have been thinking about that. OpenVZ is definitely very differen
On Wed, Mar 14, 2007 at 08:38:51AM +0530, Shuveb Hussain wrote:
> Hi,
>
> >> >- os: that's probably one place where OpenVZ may be quite different
> >> >from
> >> > Xen and QEmu, still what does the string
> >> > 'slackware-10.2-i386-minimal'
> >> > mean ? Is that a pointer t
I think again we're entering into territory where virt-manager and other
clients need to "just know" about the XML format and other quirks of the
particular libvirt driver. That's not a high-level virtualisation API.
Long email in preparation on this subject ... I won't spoil your
anticipati
Hi Dan,
Looking at the kind of information you need to represent for a guest
filesystem I think we might be better off inventing a new tag here
instead of using . The tag is really about exposing
some file / device as a virtual disk to the guest OS. OpenVZ doesn't
have any formal concept of vi
On Wed, Mar 14, 2007 at 12:32:36AM +0530, Shuveb Hussain wrote:
> Hi,
>
> >- os: that's probably one place where OpenVZ may be quite different
> >from
> > Xen and QEmu, still what does the string
> > 'slackware-10.2-i386-minimal'
> > mean ? Is that a pointer to a file ? If
Hi,
> >- os: that's probably one place where OpenVZ may be quite different
> >from
> > Xen and QEmu, still what does the string
> > 'slackware-10.2-i386-minimal'
> > mean ? Is that a pointer to a file ? If yes shouldn't the associated
> > content be in the XML instead
On Wed, Mar 14, 2007 at 12:20:06AM +0530, Shuveb Hussain wrote:
> Hi,
>
> [snip]
> >
> > There are things a bit surprising:
> >- vpsid: I assume it's an identifier for that domain, not as permanent
> > as the UUID but which should be sufficient to designate a running
> > domain, rig
Hi,
- os: that's probably one place where OpenVZ may be quite different from
Xen and QEmu, still what does the string 'slackware-10.2-i386-minimal'
mean ? Is that a pointer to a file ? If yes shouldn't the associated
content be in the XML instead
Under OpenVZ, there is no
Hi,
[snip]
There are things a bit surprising:
- vpsid: I assume it's an identifier for that domain, not as permanent
as the UUID but which should be sufficient to designate a running
domain, right ? If yes make it an id attribute in the top element
domain as in the examp
Hi,
In the Xen / QEMU drivers we just stick this as an 'id' attribute on the top
level - it looks reasonable to follow the same scheme for OpenVZ
Sure, 'id' is good enough.
> true
Is this attribute refering to whether the guest auto-starts at boot
time ? If so we recently introduced an
On Tue, Mar 13, 2007 at 10:57:23PM +0530, Shuveb Hussain wrote:
> Hi,
Hi,
> I am adding OpenVZ support to Libvirt and work is progressing well.
Excellent news !
> I'm able to list VM instances and I'm slowly trying to cover the basic
> API functions one by one. That brings us to the creatio
On Tue, Mar 13, 2007 at 10:57:23PM +0530, Shuveb Hussain wrote:
> Hi,
> I am adding OpenVZ support to Libvirt and work is progressing well.
> I'm able to list VM instances and I'm slowly trying to cover the basic
> API functions one by one. That brings us to the creation of OpenVZ
> based VMs. Jus
Hi,
I am adding OpenVZ support to Libvirt and work is progressing well.
I'm able to list VM instances and I'm slowly trying to cover the basic
API functions one by one. That brings us to the creation of OpenVZ
based VMs. Just wanted to discuss the basic XML definition format so
that I can get com
25 matches
Mail list logo
