[Users] rebooting physical network that ovirt is attached to
Lior Vernia
lvernia at redhat.com
Sun Mar 24 14:21:07 UTC 2013
Hello Jonathan,
Having taken a look at the other thread, your original assumption was
correct - aside from NFS, your nodes and VMs should generally be fine
during a reboot (again, excluding cases as I mentioned for thin
provisioning).
As for the NFS services your server is providing, I'm no expert when it
comes to storage, so my best advice would be to wait for someone on the
other thread to give you a definite answer (also it sounds like there's
a bigger issue weighing on your server, causing it to be sluggish).
However, if you're pressed for time - I think you should be fine as long
as you detach the NFS domains in an orderly fashion before you take the
server down for a reboot, and then reattach them when it's back up. As
far as I know (and again I'm no expert), both of these domains aren't
critical most of the time; ISO domains are critical when you have VMs
accessing them (during installation and such), and export domains when
you're moving VMs around.
Also, you might want to try IRC to see if someone more knowledgeable
than me might answer you in real time: irc://irc.oftc.net/ovirt.
Yours, Lior.
On 24/03/13 15:42, Jonathan Horne wrote:
> Ah, thank you much lior and alex.
>
>
>
> I believe this also answers my other thread, that is is ok to reboot the
> management server at any time? (I have another thread about how sluggish
> mine is running lately, and id like to get it rebooted soon before I go
> on vacation).
>
>
>
> Thanks again!
>
> jonathan
>
>
>
> *From:*Alex Leonhardt [mailto:alex.tuxx at gmail.com]
> *Sent:* Sunday, March 24, 2013 7:40 AM
> *To:* Lior Vernia
> *Cc:* Jonathan Horne; users at ovirt.org
> *Subject:* Re: [Users] rebooting physical network that ovirt is attached to
>
>
>
> From experience, I would shutdown the ovirt engine before you do any
> work related to networking. The VMs will keep running w/o the engine
> available, you're simply unable to add/remove/failover VMs, etc. The
> VDSM running on the host will be unable to get instructions to "kill"
> any VMs as the engine is already "down" :) ...
>
> hope it helps!
> alex
>
>
>
>
> On 03/24/2013 10:04 AM, Lior Vernia wrote:
>
> Hello Jonathan,
>
>
>
> First of all let me apologize for not being more responsive, seems like
>
> you got the worse end of time difference.
>
>
>
> Now, in case the question is still relevant:
>
>
>
> 1. Rebooting the first switch won't cause any damage. The VMs will lose
>
> connectivity on the VLANs, but they should still be manageable through
>
> oVirt and run normally on their hosts.
>
>
>
> 2. Rebooting the second one could prove more troublesome. Firstly, as a
>
> preemptive measure I would advise that you not have any VMs running on
>
> your host marked as SPM at the moment of reboot, if possible - there's
>
> risk that VMs running on your SPM will be shut down violently when it
>
> loses connectivity (or the moment it regains connectivity). Also, if any
>
> of your VMs have thin provisioning defined and they exhaust their
>
> storage during downtime, they'll run into trouble; but as far as I know
>
> they should be okay if they're not running processes that can suddenly
>
> demand a lot more storage. That's as far as possible damage goes.
>
> Besides that, when the switch comes back up, some components (host, data
>
> domain) might appear as non-operational or down, and you might have to
>
> reactivate them manually from the webadmin console.
>
>
>
> Hope this helps.
>
>
>
> Yours, Lior Vernia.
>
>
>
> On 21/03/13 20:42, Jonathan Horne wrote:
>
> greetings,
>
>
>
> we are talking about possibly upgrading our cisco gear tonight, and this
>
> will affect our ovirt environment.
>
>
>
> what can i expect if i were to reboot first the switch that all VMguest
>
> VLANs are going thru, ad then afterwards rebooting the switch that all
>
> ovirtmgmt connections are in? how will the ovirt environment behave
>
> with loss of network connectivity for a couple minutes?
>
>
>
> the iscsi network is not going to be affected. any information or
>
> stories of similar experiences would be appreciated.
>
>
>
> thanks,
>
> jonathan
>
>
>
>
>
> ------------------------------------------------------------------------
>
> This is a PRIVATE message. If you are not the intended recipient, please
>
> delete without copying and kindly advise us by e-mail of the mistake in
>
> delivery. NOTE: Regardless of content, this e-mail shall not operate to
>
> bind SKOPOS to any order or other contract unless pursuant to explicit
>
> written agreement or government initiative expressly permitting the use
>
> of e-mail for such purpose.
>
>
>
>
>
> _______________________________________________
>
> Users mailing list
>
> Users at ovirt.org <mailto:Users at ovirt.org>
>
> http://lists.ovirt.org/mailman/listinfo/users
>
>
>
> _______________________________________________
>
> Users mailing list
>
> Users at ovirt.org <mailto:Users at ovirt.org>
>
> http://lists.ovirt.org/mailman/listinfo/users
>
>
> ------------------------------------------------------------------------
> This is a PRIVATE message. If you are not the intended recipient, please
> delete without copying and kindly advise us by e-mail of the mistake in
> delivery. NOTE: Regardless of content, this e-mail shall not operate to
> bind SKOPOS to any order or other contract unless pursuant to explicit
> written agreement or government initiative expressly permitting the use
> of e-mail for such purpose.
More information about the Users
mailing list