Citrix Xenserver and FreeBSD migration/suspend scripts

[Gót András]

Hi,

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.

Regards,
Andras


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
> 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.
> _______________________________________________
> freebsd-xen at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-xen
> To unsubscribe, send any mail to "freebsd-xen-unsubscribe at freebsd.org"