Re: [Xen-users] xen client side package.

[jd <jdsw2002@xxxxxxxxx>]

Todd, 
   Thanks for detailed feedback... see inline...


--- On Sun, 8/10/08, Todd Deshane <deshantm@xxxxxxxxx> wrote:

> From: Todd Deshane <deshantm@xxxxxxxxx>
> Subject: Re: [Xen-users] xen client side package.
> To: jdsw2002@xxxxxxxxx
> Cc: "XenUsers" <xen-users@xxxxxxxxxxxxxxxxxxx>
> Date: Sunday, August 10, 2008, 8:37 PM
> Hi Jd,
> 
> I think that ConVirt looks like it has a lot of potential,
> but in my
> personal experience, I haven't had very good luck with
> it.
> 
> I have some included some suggestions and comments based on
> your
> questions below.
> 
> On Sun, Aug 10, 2008 at 11:04 PM, jd
> <jdsw2002@xxxxxxxxx> wrote:
> > Hi
> >   As you might have noticed that ConVirt
> http://www.convirt.net now supports  both Xen as well as KVM
> platforms. I am looking for a smallest footprint xen client
> package that can manage remote Xen Nodes via xml-rpc /
> xen-api. This would help,
> >
> 
> You should work with the Xen API team to make sure that you
> have
> included the proper xen-api
> see:
> http://wiki.xensource.com/xenwiki/XenApi

Yes, we would cut-over to use the XenAPI, but last time I looked it was not  
fully backed as well as resource constraints at our end is delaying this.

Still the API as separate rpm/installable entity is required.

> 
> >     -- Xen users interested in managing Xen on the
> remote box only
> 
> I frequently talk to many users (industry/academic/etc.)
> that would
> like to do this.
> 

We allow this, but need whole xen installed... as there does not seem to be a 
good factoring for client side. 

> >     -- KVM only users,
> 
> I don't think there would be a need to separate the
> functionality,
> unless there are
> users that need a special case small installation size.
> 
> >     -- and evaluating possibility of win32 ConVirt
> client
> 
> I think this could lead to more widespread use of ConVirt.
> 
> >  On Fedora the xen-libs pacakge does not seem to
> contain the python stuff while the xen package seems to
> contain dependency on xen kernel, virt-* etc.
> > Also, would like to know distribution specific package
> factoring for the same as well.
> 
> One of the biggest problems is that it, even with the
> latest version
> of ConVirt that I tried, requires a patched version of
> Paramiko
> and doesn't usually work well out of the box. It is
> unclear from the
> documentation alone why the patch is being applied.
> 

This has nothing to do with the packaging on fedora right ? The paramiko had 
couple of bugs that got fixed in 1.7.3, so people who have 1.7.3, they do not 
have to do this. The patch takes care of detecting the version and doing the 
right thing, as 1.7.3 becomes wide spread, it wouldnt be necessary. 
For improving the doc, in case you missed, we have the ConVirt wiki, where 
everyone can participate and improve. This is going to be a big knowledge 
repository. check out at http://www.convirt.net/wiki



> It should also be clearly stated in the docs what changes
> that are
> need to be made to the xend config file to get the remote
> access to
> work. Running the scripts should be done in the install (if
> it is not
> done that way already) and backups of the config files
> should be made,
> then just notify the user of the changes and give them a
> way to roll
> back the changes if needed to disable remote management.
>

Couple of observations, the changes to config file needs to be done on managed 
server which would be remote, and hence can not be done as a part of the 
install. For the local host management, this is not necessary. So out of the 
box, local management should work. On the other hand, people have been asking 
for scripts to do this, hence the scripts provided. The scripts also back up 
the original file.

 
> If the basic functionality worked well out of the box, it
> could
> compete with virt-manager. A windows version could give it
> an even
> larger user base.
> 
> Also, last I knew there was an open bug [1] missing the
> xenman/convirt
> package. Ubuntu is a popular general purpose desktop and
> having (minimally) remote support that works from that
> would help the
> user base too.
> 
> [1]
> https://bugs.launchpad.net/ubuntu/+source/xen-meta/+bug/215558
> 


Thanks for pointing this out... I will definitely follow up and see whats going 
on. I get emails on xenman/convirt issues... but not xen-desktop, this might be 
the reason why it got missed. 

Thanks again for feedback, and anything else that you can do to help the 
project or documentation would be greatly appreciated. 


/Jd
p.s. Just as note, this email does not address the actual problem of having a 
client side rpm that can be useful for doing remote xen management. So if 
anyone has ideas please let them out :)


> Cheers,
> Todd
> 
> -- 
> Todd Deshane
> http://todddeshane.net
> check out our book: http://runningxen.com


      

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users