Of course this should make into ports and some little news would also be good on the freebsd-stable list and the freebsd website also. This is a very big thing to have FreeBSD working fine under XenServer fine.

What would you need to host the tarballs?

I'm in a XenServer deployment project, kind of public cloud but small scale of course as we're not amazon, and we'd be also happy to evaluate and test it. It'd be very good to offer FreeBSD based VM-s also.


On 08/08/2012 04:31 PM, Mark Felder wrote:
I've had a few positive responses off-list about this and the desire to
get this into the ports tree somehow. Someone also had the original
author's email address (he subscribes to this list), so I'm going to CC
him on this email as well.

We could probably get this into the ports tree relatively quickly. I've
been working closely with the ports@ team recently, so it wouldn't take
much effort in that respect. Some questions were brought up about what
it should be named or if it should be a separate port and I don't know
what the right answer here is, really. Perhaps emulators/xe-tools or
emulators/xenserver-tools would be sufficient.

I guess the first step would be to find some place to officially host
the tarball and/or tag a release on github. As it stands things are
fully functional, so getting this into the ports tree shouldn't be too
big of a problem. Long term I'd like to see this cleaned up a bit
more... it's quite the mess. Honestly, everything could (and should) be
rolled into one shell script because there's really no need to have
xe-daemon, xe-ip-if.sh, and xe-update-guest-attrs. For the record,
xe-update-guest-attrs is the file with the Citrix/GPL header. It has the
examples of how we should be calling the other xen-tools to report data
to XenServer. Whether we concentrate on this script or a rewrite happens
doesn't really matter to me; it's not a lot of code I'd just like to see
all of these really awful hacks removed :-)

Someone was asking about whether or not this was production-worthy. I
really don't see why not. I suppose if this fails you'll just end up
with a VM running without recognized tools again. I don't believe it's
possible for the OS to crash from things these scripts run, and the
ability to migrate/suspend Xen VMs is not reliant on these tools in a
fully open source Xen environment; this is just a requirement Citrix

Feel free to speak up if you have any thoughts or suggestions :-)

Egoitz, can you confirm what license you originally released everything
under? I'd like to properly honor that license if you had one in mind.
freebsd-xen@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
freebsd-xen@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Reply via email to