Just to clarify a step further, this should have been the case with 3.x to
4.0 as well. We had all of these new vpc scripts that added brand new
functionality that needed to go on the virtual routers. The system VM
template stayed the same, even though new scripts were added via
systemvm.iso.
On Mar 27, 2013 9:04 PM, "Marcus Sorensen" <shadow...@gmail.com> wrote:

> There are two things, upgrade of system VM, and upgrade of software on
> system VM. Any time you start a system VM the latest scripts get copied to
> it. This isn't the same as using the new ipv6 template. I can understand
> needing to reboot the system VMS if the scripts change, but its not the
> same as upgrading the OS in the system VM.
> On Mar 27, 2013 8:59 PM, "David Nalley" <da...@gnsa.us> wrote:
>
>> >> Deploying Vms in existing networks succeed. But Vms are not given any
>> ip address.
>> >> In router, I see that the mac address of the Vm is not populated
>> correctly.
>> >> root@r-4-VM:~# cat /etc/dhcphosts.txt
>> >> 02:00:42:47:00:01,set:10_1_1_17,10.1.1.17,test123,infinite
>> >> -4,set:10_1_1_195,10.1.1.195,-m,infinite
>> >> root@r-4-VM:~#
>> >>
>> >> After stopping and starting of the existing routers , Vm deployment
>> succeeds.
>> >>
>> >> Seems like all the routers need to be stopped and started after
>> upgrade.
>> >
>> > Forgive the question, but I actually haven't upgraded a production
>> > environment yet!  Is this normal to have to restart the VR's after a
>> > major update?  I *think* I remember that this is, but I just want to
>> > confirm.
>> >
>>
>> So it's expected if we change the sysvms materially - but I would have
>> expected them to have continued working.
>> That said, I thought update of sysvms was optional and only necessary
>> if you wanted IPv6-enabled system VMs.
>> Can someone canonically answer this? Things like this will affect
>> install documentation.
>>
>

Reply via email to