To clarify, this is a fairly serious bug, and it should probably be addressed, I'm just wanting clarification that the patch is good to go as a fix. On my way home I was thinking about how I'm not sure if it addresses upgrades, i.e. does it still allow existing definitions to be wiped, or will those be forever stuck. I haven't even looked yet.
Essentially, the bug is that if a KVM host is uncleanly shut down, and then brought back up without starting the agent, the VMs that were running on the system will be started by libvirt/startup scripts, which can be disastrous for shared-storage VMs. So if a host goes down without being put into maintenance mode, for whatever reason, and the agent is either slow to start, the agent fails to start for some reason, or auto-start is disabled for some reason, you're almost guaranteed to have two VMs running off of the same shared storage image. We don't want to make any VMs permanently known to a host, and libvirt provides a simple way to define a VM domain without making it permanent. On Tue, Mar 12, 2013 at 6:42 PM, Chip Childers <chip.child...@sungard.com> wrote: > On Tue, Mar 12, 2013 at 06:39:09PM -0600, Marcus Sorensen wrote: >> This addresses CLOUDSTACK-600. Please get buyoff from Wido if >> possible, since it's his patch. I've reviewed and tested it, but I >> want to make sure I'm not wrong in assuming that this should be in 4.1 >> >> commit 5dfcd309f10e5bd6a918f7fdff3f44a3dff2374a >> Author: Wido den Hollander <w...@widodh.nl> >> Date: Thu Feb 7 22:58:20 2013 +0100 >> >> agent: Do not define domains persistent in libvirt >> >> We used to define domains persistent in libvirt, which caused XML >> definitions >> to stay there after a reboot of the hypervisor. >> >> We however don't do anything with those already defined domains, >> actually, we wipe >> all defined domains when starting the agent. >> >> Some users however reported that libvirt started these domains >> after a reboot >> before the CloudStack agent was started. >> >> By starting domains from the XML description and not defining them >> we prevent >> them from ever being stored in libvirt. >> > > Wido - I'll let you comment before we apply this.
