Hi, all,
Before I start hacking up my own poor solution, I'd like to run this by the list and see if there's a good way to handle this.
I have a host (5.3 Xen Dom0) that has three guests:
Fedora 10 Fedora 11 Nexenta 2
The Nexenta (opensolaris) guest's job is to provide storage services to the Fedora DomU's, via iSCSI and NFS (ZFS storage).
My goal is to automate system startup.
My dependency tree looks like:
Dom0 -> nexenta-DomU -> 'service iscsi'@Dom0 -> fedora-DomU's
Currently I have xendomains and iscsi set to 'chkconfig off' and the fedora DomU's set for 'auto', and do:
xm create nexenta [watch xentop to see when it's running] service iscsi start service xendomains start
Which works find and requires me to do it. I can write some scripts to do the same thing, but if there was a more general-purpose way to express these kinds of boot-time dependencies, I'd rather do it right.
I was thinking perhaps upstart could be co-opted for this purpose, if I can make it not cobbler init (it would have to run alongside on 5.3). Are there any libvirt event hooks into upstart?
Thanks, -Bill
On Thu, Jun 11, 2009 at 03:38:30PM -0400, Bill McGonigle wrote:
xm create nexenta [watch xentop to see when it's running] service iscsi start service xendomains start
Which works find and requires me to do it. I can write some scripts to do the same thing, but if there was a more general-purpose way to express these kinds of boot-time dependencies, I'd rather do it right.
I was thinking perhaps upstart could be co-opted for this purpose, if I can make it not cobbler init (it would have to run alongside on 5.3). Are there any libvirt event hooks into upstart?
Common problem, no good solutions.
The best advice I think is to change your architecture so that virtual machines can cope with other services being unavailable. Not just at boot time, but _any_ time, because you never know when you might need to restart your iscsi service.
NFS can do this with background mounts and so on. I'm not sure about iscsi though ...
Rich.
On 06/11/2009 04:53 PM, Richard W.M. Jones wrote:
Common problem, no good solutions.
OK, that's helpful to know I haven't missed the obvious.
The best advice I think is to change your architecture so that virtual machines can cope with other services being unavailable. Not just at boot time, but_any_ time, because you never know when you might need to restart your iscsi service.
NFS can do this with background mounts and so on. I'm not sure about iscsi though ...
NFS root is the next thing on my list to figure out. :) I'd like to get it to the point of only needing /boot on iSCSI, at least until btrfs lands. I should probably mount it sync too, just in case.
Does Xen deal with a device going away and coming back with the same name? Either automatic or via hotplugging would be effective. I'm using /dev/disk/by-path/ names so they should line up correctly at least.
Thanks, -Bill
Bill McGonigle wrote:
Does Xen deal with a device going away and coming back with the same name? Either automatic or via hotplugging would be effective. I'm using /dev/disk/by-path/ names so they should line up correctly at least.
Yes, this should be fine. You can do "xm block-detach" followed by an "xm block-attach" without issues, and the blkfront driver in the guest handles it.
Bill McGonigle wrote:
Hi, all,
Before I start hacking up my own poor solution, I'd like to run this by the list and see if there's a good way to handle this.
I have a host (5.3 Xen Dom0) that has three guests:
Fedora 10 Fedora 11 Nexenta 2
The Nexenta (opensolaris) guest's job is to provide storage services to the Fedora DomU's, via iSCSI and NFS (ZFS storage).
My goal is to automate system startup.
My dependency tree looks like:
Dom0 -> nexenta-DomU -> 'service iscsi'@Dom0 -> fedora-DomU's
Currently I have xendomains and iscsi set to 'chkconfig off' and the fedora DomU's set for 'auto', and do:
xm create nexenta [watch xentop to see when it's running] service iscsi start service xendomains start
If I were going to do this, I'd write a very small daemon to run in the dom0 that just listens to a couple of ports. On dom0 boot, I would start this daemon, which would first exec "xm create nexenta", then wait around for a little while listening from a connection on port, say, 4567. Inside the nexenta guest, you just have a simple "nc" command that connects to the dom0 once it is booted, and acts like a "I'm ready" command. Once your dom0 daemon receives this, it can go onto the next step (service iscsi start), and then finally onto your last step.
It's a bit hacky, but it centralizes control all in one place, and it is pretty easy to write.
On 06/12/2009 02:41 AM, Chris Lalancette wrote:
If I were going to do this, I'd write a very small daemon to run in the dom0 that just listens to a couple of ports. ... Inside the nexenta guest, you just have a simple "nc" command that connects to the dom0 once it is booted, and acts like a "I'm ready" command.
This is a great idea. I'll put it in my queue, maybe with some trivially-signed messages, so I can keep it on one port.
Thanks, -Bill
-
Bill McGonigle -
Chris Lalancette -
Richard W.M. Jones