ASF GitHub Bot commented on CLOUDSTACK-10232:

rafaelweingartner commented on a change in pull request #2465: 
CLOUDSTACK-10232: SystemVMs and VR to run as HVM on XenServer
URL: https://github.com/apache/cloudstack/pull/2465#discussion_r170083404

 File path: 
 @@ -1368,12 +1368,23 @@ public VM createVmFromTemplate(final Connection conn, 
final VirtualMachineTO vmS
         final String bootArgs = vmSpec.getBootArgs();
         if (bootArgs != null && bootArgs.length() > 0) {
+            // send boot args for PV instances
             String pvargs = vm.getPVArgs(conn);
             pvargs = pvargs + vmSpec.getBootArgs().replaceAll(" ", "%");
             if (s_logger.isDebugEnabled()) {
                 s_logger.debug("PV args are " + pvargs);
             vm.setPVArgs(conn, pvargs);
+            // send boot args into xenstore-data for HVM instances
+            Map<String, String> xenstoreData = new HashMap<>();
+            xenstoreData.put("vm-data/cloudstack/init", bootArgs);
+            vm.setXenstoreData(conn, xenstoreData);
+            if (s_logger.isDebugEnabled()) {
+                s_logger.debug("HVM args are " + bootArgs);
 Review comment:
   What I meant is that, in a Web API drive system such as ACS, everything is 
synchronous (or almost everything). Therefore, the 1 nanoseconds of improvement 
that the use of this IF conditional can bring is negligible. This means that 
the code (the code used to create this optimization) is not worth it (in my 
   I normally see people using this approach of checking log level before 
logging when creating log messages using String.format, which uses quite some 
processing. However, even in those cases, I do not see much need to check the 
log level before logging (in most cases).
   I just commented to give some context on the use of this is<LogLevel>Enabled 
method. The only time I used this approach of checking log level was when I 
developed some standalone optimization algorithms that had a time constraint to 
be executed. Therefore, there was no space to waste clock cycles creating a log 
message that is not going to be used.
   In summary; if I were coding, I would not use it. However, we have these 
things spread all over our code base. I normally remove them, but if you want 
to use, the choice is yours.

This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:

> SystemVMs and VR to run as HVM on XenServer
> -------------------------------------------
>                 Key: CLOUDSTACK-10232
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10232
>             Project: CloudStack
>          Issue Type: New Feature
>      Security Level: Public(Anyone can view this level - this is the 
> default.) 
>          Components: SystemVM, Virtual Router, XenServer
>    Affects Versions:,
>            Reporter: Pierre-Luc Dion
>            Priority: Major
> Following the recent Meltdown-Spectre security risk,one of the mitigation,as 
> of Jan 2018, for XenServer Hypervisor is to run Virtual-Machine in HVM mode.
> Currently SystemVMs and Virtual-Routers run as PV on XenServer and the eth0 
> is configured using {{/etc/init.d/cloud-early-config}} using grub params from 
> {{/proc/cmdline}}. When VM run as HVM, it is not possible to push initial 
> boot instruction via pygrub.
> Quick tests has been done using xenstore and it look like it would be 
> possible to send same initial boot instruction has pygrub but using xenstore 
> for HVM instances.

This message was sent by Atlassian JIRA

Reply via email to