Date: Wed, 8 Aug 2012 09:31:30 -0500 From: Mark Felder <feld@feld.me> To: freebsd-xen@freebsd.org Subject: Re: Citrix Xenserver and FreeBSD migration/suspend scripts Message-ID: <op.wip7yspm34t2sn@tech304> In-Reply-To: <op.wipf7zf634t2sn@tech304> References: <op.wipf7zf634t2sn@tech304>
next in thread | previous in thread | raw e-mail | index | archive | help
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 imposes. 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?op.wip7yspm34t2sn>