I am using this template for system VMs: http://download.cloudstack.org/systemvm/4.11/systemvmtemplate-4.11.0-xen.vhd.bz2 And, right now, the ACS version I am using was built using the branch of this PR: https://github.com/apache/cloudstack/pull/2524. Everything seems to be just fine here.
Could you get some details regarding the VR status that ACS is seeing? On Thu, Apr 5, 2018 at 1:56 PM, Tutkowski, Mike <mike.tutkow...@netapp.com> wrote: > Thanks for your feedback, Rafael. > > I re-created my 4.12 cloud today (after fetching the latest code and using > the master branch) and still seem to be having trouble with the VR. The > hypervisor type I’m using here is XenServer 6.5. > > When I examine the VR in the CloudStack GUI, the “Requires Upgrade” column > says, “Yes”. However, when I try to initiate the upgrade, I get an error > message stating that the VR is not in the proper state (because it’s stuck > in the Starting state). > > The system VM template I am working with is the following: > http://cloudstack.apt-get.eu/systemvm/4.11/ > > In case anyone sees something, I’ve included the contents of my VR’s > cloud.log file below. > > Thanks! > > Thu Apr 5 16:45:01 UTC 2018 Executing cloud-early-config > Thu Apr 5 16:45:01 UTC 2018 Detected that we are running inside xen-domU > Thu Apr 5 16:45:02 UTC 2018 Scripts checksum detected: oldmd5= > 60703a62ef9d1666975ec0a8ce421270 newmd5=7f8c303cd3303ff902e7ad9f3f1f092b > Thu Apr 5 16:45:02 UTC 2018 Patched scripts using > /media/cdrom/cloud-scripts.tgz > Thu Apr 5 16:45:02 UTC 2018 Patching cloud service > Thu Apr 5 16:45:02 UTC 2018 Configuring systemvm type=dhcpsrvr > Thu Apr 5 16:45:02 UTC 2018 Setting up dhcp server system vm > Thu Apr 5 16:45:04 UTC 2018 Setting up dnsmasq > Thu Apr 5 16:45:05 UTC 2018 Setting up apache web server > Thu Apr 5 16:45:05 UTC 2018 Processors = 1 Enable service = 0 > Thu Apr 5 16:45:05 UTC 2018 cloud: enable_fwding = 0 > Thu Apr 5 16:45:05 UTC 2018 enable_fwding = 0 > Thu Apr 5 16:45:05 UTC 2018 Finished setting up systemvm > 2018-04-05 16:45:05,924 merge.py load:296 Continuing with the processing > of file '/var/cache/cloud/cmd_line.json' > 2018-04-05 16:45:05,927 merge.py process:101 Command of type cmdline > received > 2018-04-05 16:45:05,928 merge.py process:101 Command of type ips received > 2018-04-05 16:45:05,929 merge.py process:101 Command of type ips received > 2018-04-05 16:45:05,930 CsHelper.py execute:188 Executing: ip addr show > dev eth1 > 2018-04-05 16:45:05,941 CsHelper.py execute:188 Executing: ip addr show > dev eth0 > 2018-04-05 16:45:05,950 CsHelper.py execute:188 Executing: ip addr show > dev eth1 > 2018-04-05 16:45:05,958 CsAddress.py process:108 Address found in DataBag > ==> {u'public_ip': u'169.254.3.171', u'one_to_one_nat': False, > u'nic_dev_id': u'1', u'network': u'169.254.0.0/16', u'netmask': > u'255.255.0.0', u'source_nat': False, u'broadcast': u'169.254.255.255', > u'add': True, u'nw_type': u'control', u'device': u'eth1', u'cidr': u' > 169.254.3.171/16', u'gateway': u'None', u'size': u'16'} > 2018-04-05 16:45:05,959 CsAddress.py process:116 Address 169.254.3.171/16 > on device eth1 already configured > 2018-04-05 16:45:05,959 CsRoute.py defaultroute_exists:103 Checking if > default ipv4 route is present > 2018-04-05 16:45:05,959 CsHelper.py execute:188 Executing: ip -4 route > list 0/0 > 2018-04-05 16:45:05,967 CsRoute.py defaultroute_exists:107 Default route > found: default via 10.117.40.126 dev eth0 > 2018-04-05 16:45:05,967 CsHelper.py execute:188 Executing: ip addr show > dev eth0 > 2018-04-05 16:45:05,976 CsAddress.py process:108 Address found in DataBag > ==> {u'public_ip': u'10.117.40.33', u'one_to_one_nat': False, > u'nic_dev_id': u'0', u'network': u'10.117.40.0/25', u'netmask': > u'255.255.255.128', u'source_nat': False, u'broadcast': u'10.117.40.127', > u'add': True, u'nw_type': u'guest', u'device': u'eth0', u'cidr': u' > 10.117.40.33/25', u'gateway': u'None', u'size': u'25'} > 2018-04-05 16:45:05,976 CsAddress.py process:116 Address 10.117.40.33/25 > on device eth0 already configured > 2018-04-05 16:45:05,976 CsRoute.py add_table:37 Adding route table: 0 > Table_eth0 to /etc/iproute2/rt_tables if not present > 2018-04-05 16:45:05,978 CsHelper.py execute:188 Executing: sudo echo 0 > Table_eth0 >> /etc/iproute2/rt_tables > 2018-04-05 16:45:06,015 CsHelper.py execute:188 Executing: ip rule show > 2018-04-05 16:45:06,026 CsHelper.py execute:188 Executing: ip rule show > 2018-04-05 16:45:06,034 CsHelper.py execute:188 Executing: ip rule add > fwmark 0 table Table_eth0 > 2018-04-05 16:45:06,042 CsRule.py addMark:49 Added fwmark rule for > Table_eth0 > 2018-04-05 16:45:06,043 CsHelper.py execute:188 Executing: ip link show > eth0 | grep 'state DOWN' > 2018-04-05 16:45:06,053 CsHelper.py execute:193 Command 'ip link show > eth0 | grep 'state DOWN'' returned non-zero exit status 1 > 2018-04-05 16:45:06,053 CsHelper.py execute:188 Executing: arping -c 1 -I > eth0 -A -U -s 10.117.40.33 None > 2018-04-05 16:45:06,066 CsHelper.py execute:193 Command 'arping -c 1 -I > eth0 -A -U -s 10.117.40.33 None' returned non-zero exit status 2 > 2018-04-05 16:45:06,067 CsRoute.py add_network_route:64 Adding route: dev > eth0 table: Table_eth0 network: 10.117.40.0/25 if not present > 2018-04-05 16:45:06,067 CsHelper.py execute:188 Executing: ip route show > dev eth0 table Table_eth0 throw 10.117.40.0/25 proto static > 2018-04-05 16:45:06,075 CsHelper.py execute:193 Command 'ip route show > dev eth0 table Table_eth0 throw 10.117.40.0/25 proto static' returned > non-zero exit status 1 > 2018-04-05 16:45:06,076 CsRoute.py set_route:74 Add dev eth0 table > Table_eth0 throw 10.117.40.0/25 proto static > 2018-04-05 16:45:06,076 CsHelper.py execute:188 Executing: ip route add > dev eth0 table Table_eth0 throw 10.117.40.0/25 proto static > 2018-04-05 16:45:06,085 CsHelper.py execute:193 Command 'ip route add dev > eth0 table Table_eth0 throw 10.117.40.0/25 proto static' returned > non-zero exit status 2 > 2018-04-05 16:45:06,086 CsHelper.py execute:188 Executing: sudo ip route > flush cache > 2018-04-05 16:45:06,103 CsHelper.py copy:263 Copied > /etc/apache2/vhost.template to /etc/apache2/sites-enabled/ > vhost-10.117.40.33.conf > 2018-04-05 16:45:06,107 CsFile.py commit:66 Wrote edited file > /etc/apache2/sites-enabled/vhost-10.117.40.33.conf > 2018-04-05 16:45:06,107 CsFile.py commit:68 Updated file in-cache > configuration > 2018-04-05 16:45:06,107 CsHelper.py execute:188 Executing: systemctl > restart apache2 > > On 4/4/18, 7:04 AM, "Rafael Weingärtner" <rafaelweingart...@gmail.com> > wrote: > > Hey Mike, > > This week I have been using ACS 4.12 to do some testing. VRs and > system VMs > are deploying just fine with the system VM template of 4.11. Of > course, by > using this template (the 4.11) I am not receiving the changes already > made > to it in both 4.11 and current master branch. > > During my testes, I allocated a public IP, created some NAT rules, > allocated directly attach IPs. Everything was working as expected. > > > The hypervisor I am using is XenServer both 6.5 and 7.2. > > On Tue, Apr 3, 2018 at 1:56 AM, Tutkowski, Mike < > mike.tutkow...@netapp.com> > wrote: > > > Hi, > > > > I may have missed an e-mail about this recently. > > > > Can someone provide me with the current URL I can use to download > system > > VM templates for 4.12? > > > > I’ve tried 4.11 from here: > > > > http://cloudstack.apt-get.eu/systemvm/4.11/ > > > > and master from here: > > > > https://builds.cloudstack.org/job/build-master-systemvm/ > > > > However, in neither case can I get the VR up and running on 4.12. > > > > Thanks! > > Mike > > > > > > -- > Rafael Weingärtner > > > -- Rafael Weingärtner
